Stack OverflowWhat's your 'no framework' PHP framework?
[+106] [18] GeekJock
[2009-03-29 16:45:33]
[ php mvc design oop frameworks ]

Even with a ton of PHP frameworks out there to choose from, I know many people prefer a minimal, personal set of libraries. What is your method when it comes to 'rolling your own' framework for PHP applications, and how does it vary depending on the type/scope of a project?

What does your script look like for a typical page? What is your file structure? What 3rd party libraries/components do you commonly use, and how do you keep your libraries, functions, classes organized?

Do you address/implement:

and if so, how?

At what point do you consider using a more popular, existing framework (eg. Codeigniter) instead?

Things that got me thinking:
The no-framework PHP MVC framework [1]
What PHP application design/design patterns do you use? [2]
Whats A Good Standard Code Layout for a PHP Application? [3]
Scalable and Flexible Directory Structure for Web Applications [4]

i had a "no framework" PHP framework, but converted it to an open source framework - mauris
I think it's a great question ,especially for PHP:) - code4j
[+46] [2009-03-29 17:22:58] Click Upvote

Most of the time I use CodeIgniter [1], but there are times when I just need to make a quick change/addition to something which is already up and running.

In an ideal world, this is the no-framework framework I'd like to use one day:

  • app
    • controllers
    • models
    • views
    • config (db config, etc)
    • emails (templates for emails sent out by the system)
    • lib (common class files for pagination, db stuff, etc)
  • index.php (Front controller)
  • .htaccess

In the real world, with deadline constraints, this is how i actually end up doing thngs (however someday I'm going to build the framework I mentioned above):

  • app
    • script.php
    • another-script.php
    • yet-another-script.php
    • admin
      • login.php
      • users.php
      • something-else.php
    • inc
      • db-config.php
      • Db.php (Database class)
      • Auth.php (user auth. class)
      • functions.php (functions common throughout the system)
      • ........

(1) In the deadline world, we just have to do, no matter how! very very nice separation. - Sepehr Lajevardi
(9) Nicely laid out! It's probably worth mentioning that for security sakes, you might want to move the /inc folder out of the Apache tree (i.e. move it above or next to the /app folder). PHP won't care but it just gives you that much more protection from prying eyes. - Eric
(8) An email template is still a view. It's just the delivery mechanism that's different. - stillstanding
[+17] [2010-02-19 19:08:17] stillstanding

Take a look at PHP Fat-Free Framework [1]. You don't even need to use it as an MVC framework if you want, but surely you'd want to get into some good programming practice right from the start. It's got a gentle learning curve, compact syntax, fast and powerful template engine, forms processor, CAPTCHA image generator, built-in Javascript/CSS compressor, URL-based caching, easy-to-use SQL handler, and most of all, in a single 55KB file!


[+15] [2009-09-13 21:41:56] Sandeep Shetty

My take on this has evolved over 9 years into a set of libraries (not a framework) that I am in the process of publishing:

I'm old school and know that good design is possible in any paradigm. I prefer using multiple paradigms and hate being locked into any one (I'm looking at all you OO-for-OO-sake frameworks).

Not much of a MVC fan since it doesn't feel like the right approach to web programming. However, I do believe in separating code from presentation and my approach is heavily influenced by REST and what I like to call Resource Oriented Programming. For me, the web site IS the API.

A note on file structure: I prefer modularity and try to keep my resource handlers self-contained so that they can easily be reused in other projects by coping them. This means that you won't find top level folders like views, controllers or models. Instead, I have top level folders like libraries and handlers (which further contain sub-folders per handler with all the code and templates that it needs).

Absolutely agree, I do the same! - pestaa
(4) +1 for "Resource Oriented Programming" - Bracketworks
[+10] [2010-08-19 03:46:36] Adam Patterson

I use Dingo Framework. Its only 63kb


If you read the documentation ( I am not sure what else you really need in a FW?

(1) I have never seen a smaller and easy to understand PHP framework than this! Thanks for sharing, I implemented it in a small application which needed user login support, it worked great & it hardly took any time. - manubkk
[+8] [2009-03-29 16:59:51] GeekJock [ACCEPTED]

I found a Simple PHP Framework [1]...and it looks like a fantastic "no framework" framework ;)


(1) This is not even MVC! - RobertPitt
(2) Simple PHP Framework has a nice codebase, but it lacks documentation. Check out Flourish which is similar to Simple. - Yada
[+8] [2009-03-29 17:17:47] CMS

You might want to check some minimalistic PHP Frameworks:

I think they are simple, clean and fast enough.

Any of them will allow to use any model or object relation mapping (ORM) tool (like Propel [5], Doctrine [6], CoughPHP [7], etc...), althought Simple PHP Framework features a basic Active Record based model.


Ookuwagata link ( ) 404s, seems like it's dead. - Tchalvak
(1) Simple-php-framework is alive (moved to github). wephp had it's last commit in 2007. LightVC had it's last change notice on the site in 2008. - Tchalvak
[+8] [2010-10-01 14:06:19] RobertPitt

I love building my own framework from scratch, The most perfect framework to me would be something like so:

File Structure

  • .htaccess
  • index.php
    • /system/
      • /applications/
        • /front_end/
        • /back_end/
      • /libaries/
      • /requirements/

My index.php file would take care of defining certain constants like so:


define('SYSTEM_DIR', ROOT_DIR . "/system");


require_once SYSTEM_DIR . "/startup.php";

Simple as that, But within startup.php I would load the following criteria's for my framework:

  • SPL Autoloader, to load general classes / interfaces etc.
  • Load error checking class and start capturing output, encase some hook pre-sends whitespace
  • Create a registry objects to store objects like so:
    • Registry::add('Config',new Configuration_Loader());
    • Registry::get('Config')->system->host;
  • Clean all user input such as $_GET,$_POST,$_COOKIE with htmlentites
  • Load the route class and generate a route,
    • All this is for is to check for controller/method/param1 or ?c=test&m=test etc.
  • Once the raoute is bein found, I will send the route of to the Loader, witch in turns loads the required classes or throws a 404* error page.

when it comes down to the controller, as I have a registry object with a global scope i usually just do the following!

abstract class Controller
    public function __get($object)
        return Registry::get($object);

and then do like so:

class Controller_test extends Controller
    public function test()
        $this->View->title = "Hello World";


I tend to never create a template system as PHP itself is a great template system, I usually compose my view system with 2 objects!

First object is the View class witch just has getters and setters for the template data, and then ViewCompiler witch loads the template within the scope of its class like so

class View
   public function compile($template_name)
       $Data = ViewCompiler($template_name);

Then within ViewCompiler:

class ViewCompiler
   public function __construct($root,$data)
            require_once TEMPLATE_DIRECTORY . $root . '.php';
       $data = ob_get_contents();

   public function location()
       //use func_get_args(), to compile a new Route! and return with BASE_HREF!

Then you have a set of functions and helpers all locked in one class for the template system.

(1) I like it. One comment - cleaning _GET, _POST, and _COOKIES globally with htmlentities might not be the best idea. In my opinion it is better to keep input pure until each component needs to deal with input and let it decide how to clean (template cleans with htmlentities, database layer escapes appropriately, etc.). That way you don't end up saving < to your database or have to remember to decode it before saving. - NickC
Treating all data in its entities is the best way to do deal with things, IMO.. Then just use a ORM / DBAL to deal with injection, within the Input class you would pass GET/POST etc into a local variable, then add a method to access pure entites such as $input->get('some_key',true); // True for untouched values - RobertPitt
[+7] [2009-10-24 09:25:48] knorthfield

I like flourish [1]


[+5] [2009-09-14 16:52:53] Alix Axel

I made this one [1] ( updated development [2]) for my own personal use, it consists of only 4 functions:

  • DB()
  • Route()
  • Singleton()
  • View()

It's inspired by NiceDog [3] and DiBi [4]. I use it primarily for simple websites and APIs, and I find the DB() function quite useful because it's quite easy to implement (zero configuration) and supports all the following features:

  • SQLite 3
  • Arrays for SELECTs
  • Last Insert ID for INSERTs
  • # of Affected Rows for UPDATEs, DELETEs, ...
  • Prepared Statements and Escaping similar to DiBi

I haven't written any documentation for this but it should be pretty easy to understand if you study the code for a couple of minutes.

PS: I only use this "framework" for test cases and sometimes for low traffic stuff, a full featured framework should be used if you're doing something serious.


[+4] [2011-03-26 08:08:14] Romans Malinovskis
git clone git://

echo '<?php $config["atk"]["base_path"]="./atk4/"; ?>' > config.php
cat > index.php
class MyApp extends ApiFrontend {
    function init(){
    function page_index($p){

$api=new MyApp('myapp','jui');

Although it's better when things are in their own files, so look at

For hi-end apps with agile toolkit, you would end up with:

  • .htaccess and main.php for catchall
  • lib/ - for your code
  • atk4/ - no modifications inside there
  • atk4-addons/ - for some nice stuff you get elsewhere
  • doc/ - schema, db updates, don't forget "deny from all"
  • page/ - list of pages.
  • templates/ - you don't need unless you are making your own theme.
  • upload/ - storage for filestore:

See and for a code snippets you can place inside page_index($p); - Romans Malinovskis
haven't heard of this before, clean, well-doc'd, will investigate, thanks for taking the time to share, Romans. - Bill Ortell
[+3] [2009-03-29 17:00:10] J.C. Inacio

For any medium-size sites i tend to go with a good framework that fits the role - CI is usually a good choice.

For small pages, i have my own implementation of an ultra-lightweight (and fast) MVC "framework". It's not really a framework, as all it does is request routing/dispatching but it allows me to have a site structure very similar to, for example, CodeIgniter:


As for DB abstraction (again, on very small sites) i feel using PDO (using OOP) provides me with enough functionality to get things done, and quickly enough.

If you wanted more DB abstraction, would you build it using PDO? - GeekJock
Probably, yes. i don't see PDO having a major effect on speed over "regular" DB drivers and i feel the standard interface helps keeping the code clean. - J.C. Inacio
[+2] [2009-03-29 17:30:12] Fire Crow

I'm making my own framework to use.

I've set standards for the following,

standard datatree multidemensional array

standard way to process get/post data

then I build modules that work with each other and can be combined to make larger programs

e.g. a page program that handles the display of a page with several components.

that uses a html-text component, and image component and even a video component, and can use any other type of content I would want in the future.

the page system works in tandem with a navigation system, and they all work with a version control module.

Each time I build a site I consider how to make it out of reusable modules.

I do the same thing with my javascript functions so as I go I"m building my own framework over time.

I think that I can make decisions about my framework that make them more effective for my use than any prebuilt framework would, because when I build it for myself I can take alot of options off the table, things needed for projects that are outside my core market, that's what makes a custom framework more effective over a generalized one, it can be more specific.

(1) I think building your own will teach you a lot. I tried to do the same and found it very useful. In the end I got bored of reinventing the wheel though, so these days I use Code Igniter. - Jon Winstanley
Downvote me if you like, I believe in custom solution based programming, what has programming come to when programmers just reuse other peoples code. - Fire Crow
(8) "what has programming come to when programmers just reuse other peoples code" I'd say it's coming to what any other normal, respectable engineering task already is. - Adriano Varoli Piazza
Thanks, that explains a lot. - Fire Crow
[+1] [2009-03-30 06:31:01] Zyx

Currently, I maintain two projects built without an external framework. One is my blog, written a long time ago in two days and improved from time to time since then. The code is short, simple, fast and works, but is a bit messy and more complex functionality is hard to add in an elegant way (in fact, it was written to be rewritten as soon as possible, but it works for 4 years now :)). The only external libraries are GeSHi for syntax highlighting and OPT template engine.

Another project is a CMS with a small MVC core. It uses OPT, dedicated form processing tool and PDO extended with caching features and small improvements that speed up the programming. It also will be rewritten some day.

[+1] [2010-11-17 19:41:11] Pete

I tend to build a framework for a needed application made up of page controllers, library orientated, using MVC (C being page controllers) and dealing with each request individually. I never use a front controller as its simply idiotic as far as web requests go. The front controller is closer to the user, it's the browser.

If a web project your working on takes off, good luck trying to scale unique requests differently using this (chuckle).

RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule ^(.*)$ index.php [L]

Rant Over :)

The front controller is that .htaccess-enabled index.php file, not the browser. - stillstanding
[+1] [2011-02-06 01:41:17] Kyle Gadd

I share the same philosophy as above. Any framework must me simple, reusable, and small. Complexity and bloat only compounds the problem. My programming style has evolved to orbit around a single core nucleus of classes that only accomplishes what every web application requires. Handling sessions, making database calls, including javascript and css files, and putting things where they are supposed to go in an HTML page. My own "no-framework" framework of classes can be found at PHP Ease [1] where you will find the simplest of solutions to creating web apps that adhere to the DRY, and KISS philosophies. Specifically, check out the Page Class [2]. I'll never create another HTML page without using it. Anyone who would do otherwise is only torturing themselves.


[+1] [2012-01-26 21:11:22] Jason Ball

I created my own framework called beagleframework. It does basic MVC, but also has you put the core business logic in class files which follows more of the actual OO programming standards. The download is only 180KB and works great for CRUD systems. You can review it at


  • bin
  • htdocs
  • lib

Inside Lib

  • beaglelib
  • controllers
  • classes
  • models
  • views

you should add more details on file structure and your approach here. see the top rated answers in this question and edit yours :) - Arash Milani
[0] [2009-03-30 22:21:54] TokenMacGuy

I just about never touch php without the use of smarty. This by itself enforces a bit of structure to the app (though not terribly much) and smarty can be put to a tremendous amount of work.

Hmmm, interesting. I've read a lot of people saying that Smarty is unnecessary—an abstraction too many. - GeekJock
(2) with almost no other work, smarty gives a clean separation between logic and presentation. Since I don't really drink ORM kool-aid, my models mostly end up as sql. Thats as much as i need for a mid-size project. - TokenMacGuy
i will second smarty. I think that code separation is a must for clean code. - sarsnake
(5) I Agree with Abi, Its a pointless abstraction, With smartty you take the route of: Template -> Smarty -> PHP -> Compiled Output with PHP alone: Template -> PHP -> Compiled Output your just adding Smarty to change syntax, does not separate view from logic, You should just encapsulate your template loading in a name-space or a class with tight scope - RobertPitt
[0] [2012-01-18 10:09:55] icc97

I created a bare bones framework based off CakePHP [1] called Vanda PHP [2]. The core is 3KB (80 lines of code including comments). It has MVC and OOP but no DBO or REST. Its very useful as a learning process to see how CakePHP hangs together. I've also found it useful for using it as a base to refactor existing spagetti code.