Forgotten wisdom from PHP; Why modern frameworks should envy the CMS

I heard a story a recent Ruby User Group presentation entitled “Things that Ruby Can Learn From PHP”.

The speaker took the stage, stood silently for a minute, then sat down again. There was much hilarity and applause.

The PHP Elephant logo carrying the Ruby logo with its trunk

He was catering to his audience, of course. Attendees at a user group will always think of their own language as superior in most others. But it was an interesting question, and one more deserving of critical assessment, because there was something very unusual which happened in the world of PHP, something which I have yet to see in any of the other, recent web languages.

Many years ago, before I had formal software training, I too mucked about in PHP land. This is not unusual, PHP is easily available, on free or nearly-free hosting accounts, and most people can pick it up almost as easily as they can with HTML. It’s a basically an entire platform written in a microtemplating language, and that made it easy.

Of course, as time went on and applications got bigger, this pattern of “everything in the UI layer” became less effective. New frameworks cropped up which folled MVC prinicples. This is what happens with almost every language which reaches affluence.

Something else happened with the PHP ecosystem though, something I don’t recall seeing in any other language framework trends. The frameworks evolved to target non-technical users.

I’m talking about platforms like Drupal, Joomla, WordPress… Tool kits which allow people to create completely custom applications with only minor technical skill. You want to do ‘x’? Install the ‘x’ module, configure it up with a set of screens, and away you go. You want to store ‘y’ in the database? Use the content creation kit to define a new data type in the UI, and watch everything else spontaneously work with it.

These platforms are not frameworks in the popular sense, they are Content Management Systems. Really though, the difference is only in the nomenclature. For those willing to put in the effort to write code, the act of creating a module for one of these frameworks is not substantially different to writing code for any other framework.

The difference is in the attitude to the domain, to interoperability, and to configuration. Where most frameworks consider the domain, plumbing and configuration to be the domain of the developer, these CMS frameworks consider them to be the domain of the user. It is a subtle perspective shift, but one with broad reaching applications.

For example, if a module can’t be installed, configured and maintained from a well defined UI, then it’s not production ready. If it doesn’t automatically cater to as-yet unimagined data types, it’s not production ready. If you can’t take a piece of functionality from one application, drop it into another application with a different domain, and see it fully integrated and working without a restart… It’s not even ready for beta-testing.

It’s a different type of software quality, a form of completeness which is very often forgotten or ignored completely by developers in other frameworks where the Test Coverage is King, and config files are his courtesans. Even the most ‘accessible’ of the popular frameworks, tools like Ruby on Rails, require code pretty much from the get go. You can’t define your domain without source code, you can’t use a database without editing XML or YAML files on disk, and you certainly can’t download a module, click a button and expect it to seamlessly integrate with the rest of the system. This is something special and unique to the PHP CMS land.

So yes, I do believe that there is a lot to be learned from PHP. Not from the language per se, most languages these days are interchangeable, but rather from the focus on modularity, maintainability, completeness, and non-coding developers.


Leave a Reply

Your email address will not be published. Required fields are marked *