minimal-mvc: Frugal PHP micro-framework with basic routing and templating

Why would I choose this over a package like Slim?

@pritaeas Most modern PHP frameworks like Slim make heavy use of OOP which introduces cruft and bloat. As you can see in that example itself, just for printing a simple Hello string, they ended up creating one Factory class and two other classes for request and response.

While OOP certainly has its uses, not all use cases need this level of bureaucratic scaling.

The vast majority of PHP apps are, in fact, small-medium ones like a simple weblog or a forum which can do with procedural code and less bureaucracy.
I am not asking you to choose this framework, it is not even ready in fact. Still an alpha version at best, needs a bit more work to be fully usable. But I can see some promise in this for a truly minimal and utilitarian PHP micro framework.

When I first created the platform that powers DaniWeb, I did so only after many years on phpBB, and learning that framework inside and out, and making lots of phpBB mods, and then many years on vBulletin, and learning that framework inside and out, and making lots of vBulletin plug-ins. Despite DaniWeb being my first web development app that I've ever written from scratch, and first app out of college, I took everything I've learned from the previous two forum frameworks I had experience with, and merged them together to create something that took the best of each of them, and rewrote things I didn't like about either of them.

That being said, I commend you on what looks like you really understanding Codeigniter 3, and then taking that knowledge to roll your own framework that took what you liked about CI, left out what you didn't, and made it more suitable to your needs.

However, I would have to respectfully disagree here when it comes to OOP. I think that, aside from the absolute most simple PHP implementations (e.g. a static website for a brick 'n' mortar that uses PHP for a contact form, etc.), OOP is an almost necessary way to organize code, work with data objects, and work with data stores. For example, in the most simplistic case where there is a login system of any kind, we want to recognize a User object, with methods that can be acted upon that object such as login(), logout(), edit_profile(), etc.

In the case of DaniWeb, there are Post objects, Thread objects, Forum objects, and Member objects, and pretty much all functionality can be accomplished with methods that act upon any combination of those four things.

It is not lost on me that what I'm describing are classes that are unique to my implementation, and obviously one wouldn't create a micro-framework with Post and Forum classes built-in. However, you proposed that weblogs or forums would do better with procedural code, and I would beg to differ on that :)

However, I do feel that even a micro-framework could benefit from a built-in User class that natively has login() and logout() methods, and is easily extensible to create other methods that the specific app would want for a User (e.g. a blog might want $user_obj->publish_article($blog_entry) or an e-commerce shop might want $user_obj->purchase($product_obj), but both would be taking advantage of the login/logout stuff already being handled).

In the case of DaniWeb, there are Post objects, Thread objects, Forum objects, and Member objects, and pretty much all functionality can be accomplished with methods that act upon any combination of those four things.

I just want to also add that I rolled my own ORM such that each instance of any of these classes maps directly to a row in a MySQL table of the same name. Each of the classes has a push_to_db() method to commit changes to the object.