We recently adopted a website at my job, which was built with a “custom framework”. Yes, we’ve all come across these, if not built them ourselves. Often the first thing that comes to mind is: “I can obviously do this better”. That’s what I thought too, but figured it would be smarter to use established PHP components.

The why

The problem with these frameworks is that often nobody but the creator actually know how they work. You could either spend a lot of time getting to know the framework OR modernize it using modern PHP components, like the Symfony components. I decided to do the latter.

This framework was probably not all that bad for its time (the wayback machine tells me it originates from +/- 2010): It’s OOP, has a front controller, a relatively logical directory structure and it utilizes a self-made active record pattern.

So why even bother to modernize it, you ask? I was asked to implement a relatively large new feature, which also involved removing a bunch of old code. I saw this as an opportunity to use today’s best practices to implement the new feature.

And, besides the previously mentioned “not that bad parts” about the framework it still had some pretty bad parts:

Every single file is located in the web root. I even came across a manual for the framework that anyone was able to reach. No thanks: I already have enough nightmares about WordPress as it is.

Every single class is located in the “classes” directory. From entities(which also happen to be repositories) to the router.

Above, I called it router, but it was more of a slug to php file matcher

No namespaces.

No separate environment configs.

No templating engine.

There’s probably more, but you get the idea.

The how

I recently read up on Fabien Potencier’s “Create your own framework” posts (must read by the way!) and started thinking if I could come up with an even better way to implement the MVC pattern than the Symfony standard edition.

Well, I couldn’t. It could be because i’ve grown so accustomed to Symfony’s way of doing things, but it could also be because I don’t have much experience as a software architect. Either way, I decided to stick with the Symfony standard edition for all my projects.

This lead me to the conclusion that the best course of action to modernize this framework was to slowly start using Symfony’s components.

Step 1: Move all php files out of the web root

At first the directory structure looked something like this, with every single file in the public_html directory:

project/ public_html/ classes/ css/ images/ js/ manual/ pages/ private/ admin/ templates/ tests/ uploads/ index.php

I decided to move everything except the js, css, images and uploads directory (and of course index.php) outside of the web root and ended up with the following structure:

project/ classes/ manual/ pages/ private/ admin/ public_html/ css/ images/ js/ uploads/ index.php templates/ tests/

Looks better already doesn’t it? Luckily the references to each directory were all relative and in one place, so that didn’t give me too many problems.

Step 2: Introducing namespaces

Note: Step 3 kind of makes this a redundant step. I kept it in anyway to remind everyone to always plan ahead.

The current autoloader didn’t do much more than fetch a php file with the corresponding name from the classes directory. Upgrading it to be able to use namespaces was pretty easy: