Couple of days ago there was an interesting post on the Dire State of WordPress, talking about the issues developers have when working with this hugely popular content management system:
When you learn PHP from WordPress as I (and probably many other people) did, you just assume that all the idiosyncrasies and illogicalities are par for the course when building a CMS-driven site. It’s taken me several years to realise that it doesn’t have to be like this. In fact, it wasn’t really until I started learning more about OO principles and working with frameworks that I started looking at WP in a different light. Why is every instance of every model treated like a post? Why can’t I extend the functionality of a post type without writing a whole mess of hooks, filters and functional code into a file that isn’t semantically related to that post in any way?
These may sound like the gripes of someone whose needs will never be met by something like WordPress, but the lack of fundamental logic that gives rise to the above issues is what makes WordPress problematic for developers at all levels. And because the crossover on the venn diagram of ‘people who know good application development practises’ and ‘people who build sites in WordPress’ is such a thin sliver, it just trundles along in its current hokey state, baffling both the unseasoned and the proficient developer alike.
As expected, this generated a lively discussion on Hacker News.
Technical debt
Now, I've used WordPress on-and-off ever since it was still called b2 cafelog, but I wouldn't consider myself a WordPress developer. But still, looking at it mostly from the outside, it is clear that many of the issues WordPress users and developers face today result from technical debt accruing from bad architectural decisions done a decade ago, and the missing will to correct those.
WordPress is still undergoing a transition from a blogging platform to a general-purpose CMS. The changes this requires mean that without a sound architecture, the problems with the underlaying engine will only become exacerbated.
This is not something unique to WordPress. Many popular CMSs, including Drupal and TYPO3 have been suffering from the same problem. We all in the open source CMS community have been there. The difference however is that these projects have identified this issue, and have taken steps to correct it.
Start decoupling
The reason why CMSs become so messy is because they all try to be so many things at once. A CMS is a web framework, a CMS is a web editing tool, and a CMS is a content store. But each of these are in reality their own, specialized areas, and so the principle of separation of concerns tells us that they should be handled by separate pieces of software.
I wrote a still-popular post titled Decoupling Content Management two years ago to argue just that. Projects like PHPCR and Create.js have since then sprung up to move that from idea to practice, and have already been adopted by many CMSs.
In nutshell, the transition I want CMSs — WordPress included — to make is this:
Here is my talk on the subject from JS.everywhere in Paris late last year:
We also talk about the cross-CMS collaboration this enables in the TYPO3 Neos launch video.
Think about it, developers from Midgard CMS and TYPO3 working together and sharing substantial parts of the user interface codebase, while still enabling each project to retain a unique look-and-feel!
Non-participation
Over the past two years I've given tens of talks about Decoupled Content Management in various developer and CMS conferences. In these events I've talked with a lot of developers from various different CMSs from both the open source and proprietary worlds. But despite its popularity, WordPress core developers have been absent.
Symfony activist Lukas Smith has noticed the sam
Truncated by Planet PHP, read more at the original (another 1671 bytes)