Last month, a post started making the rounds on the internet decrying the dire state of the WordPress codebase. James highlights several legitimate gripes but unfortunately he muddles the discussion by mixing major problems with otherwise minor concerns. Another problem, is that James’ post considers the issues purely from a technical perspective but ultimately business concerns are going to motivate a drastic change in WordPress. Looking at James’ post and from my own run ins with WordPress, the biggest problems with WordPress as it exists now are:

Broken data model: As James pointed out, as people have started to use WordPress like a CMS with by adding things like custom post types and plugins it’s clear that the underlying data model is too rigid to properly support this need. The result of this, is that developing custom database functionality is notably difficult and it limits the types of extensions that can be built purely inside WordPress.

Limited separation of concerns: Throughout WordPress, globals are heavily used, templates are free to interact with the database, and there’s generally no concept of MVC separation. Apart from being confusing, this makes it difficult to effectively reason about the behavior of a WordPress install, making “smart” caching impossible. Additionally, it makes it difficult for dedicated “frontend” developers to work on templating since they’re often left juggling PHP code. Both of these issues ultimately make running a WordPress site more expensive since you’ll need more resources for operations and development.

No OO/Encapsulation, No Namespaces, No API: Owing to its PHP4+ heritage, the core WordPress code is entirely procedural and because of this every function touches the global namespace. Also, WordPress doesn’t have native support for serving as an API backend and exposing its data in different formats or interacting with non-browser clients. The OO and namespace issue is largely technical but it makes it difficult to develop modular WP components or mixin off the shelf PHP packages. The lack of a robust API makes it impossible to use a single WordPress installation to serve content on the web but also serve as a service for mobile clients, which ultimately limits its utility.

So how do we fix it?

“Fixing” an application as large as WordPress is obviously a herculean undertaking, especially because of the need to balance the existing ecosystem with the need for a clean, strong foundation. The reality is that modernizing WordPress is ultimately going to require a full rewrite but I think it could be strategically orchestrated to win community support for the backwards compatability breaks.

Without further ado, here’s how I would do it:

June ’13 – Release Twig for WordPress

Twig for WordPress is a fully featured implementation of the Twig templating engine for WordPress. It allows developers to write WordPress themes in Twig instead of mixing PHP and HTML. Along with Twig, the plugin includes modern template caching techniques like partial page rebuilds and ESI support. In order to leverage Twig and its related benefits, developers have to write their themes with reasonably strict View/Controller separation since variables must be explicitly passed to Twig templates.

Theme designers are initially hesitant but once they see how much easier tracing the structure of Twig templates is versus straight PHP they’re converts. Developers are also fans since they enjoy being able to make the necessary page variables available in a template and then hand pages off to be themed. Benchmarks are done. Hackathons are sponsored. Themes are converted to Twig.

September ’13 – Release Doctrine Power Tools (DPT)

Leveraging Doctrine2, DPT enhances WordPress by augmenting it with the Doctrine2 ORM and associated “power tools”. This allows developers to seamlessly create new MySQL tables and then automatically generate administration CRUD for those tables. In addition, custom plugin code can choose to leverage Doctrine2 to interact with the new tables. With DPT, WordPress administrators are also able to design custom forms to insert data into custom tables and then filter and export the data in these tables.

Developers familiar with ORMs are immediately excited and after they try it out they’re hooked. They start evangelizing DPT in the community because it takes the drudgery out of creating custom database functionality in WordPress. Enterprise users slowly get wind of it and adopt it as well since it empowers their marketing team to do more without involving developers. WordPress has an ORM. Everything isn’t being stuffed into wp_posts.

January ’14 – Release WP Paladin Alpha

WP Paladin is a PHP 5.3+ object oriented rewrite of WordPress with an additional “compatibility layer” which provides compatible legacy plugins and themes access to the normal WordPress API. From a user perspective, Paladin has the same installation procedure, Admin UI, and basic functionality as stock WordPress. Additionally, a handful of the most popular plugins have been ported to be 100% compatible with Paladin. Technically, WP Paladin shares several key Symfony2 components with Drupal 8, notably the HttpKernel, which allows interoperability with other apps using HttpKernel. It also supports Twig templating and ships with the Doctrine2 ORM and DPT.

Since Twig for WP was released in June ’13, dozens of Twig themes have become available and early adopters are eagerly experimenting with Paladin. Although it currently only supports a handful of traditional WordPress plugins, it’s faster, easier to develop on, and plays well with others. The excitement is palpable. Blog posts are written. SXSW tickets are bought.

March ’14 – Release WP Paladin Beta

WP Paladin Beta is similar to the initial release except the “compatibility layer” has been removed, critical bugs have been fixed, and the platform is significantly more stable. The beta version is launched at an exclusive SXSW party to a frenzied mob. It’s taken a little less than a year, but the WordPress codebase has been modernized and new features have added. Additionally, the most popular WordPress themes and plugins have been ported to be compatible with the Paladin codebase.

The download counter hits 1 million by the end of SXSW. Congratulations are in order. VC Money is raised.

Great, count me in!

Doing something like this would certainly be a great way to “earn your stripes” but ultimately it’s going to end up burning thousands of man hours for an unknown payoff.

But who knows, maybe a company with deep pockets, talented engineers, and a disposition for risk will give it the ole college try.

  • http://www.facebook.com/Draconyster Roman Dracony Tsjupa

    WordPress is not a CMS, it’s a blog engine. If anyone is trying to use it as a full-blown CMS he must understand the risks of doing so. Changing WordPress to be a CMS will send it down the path of Joomla and Drupal, which are almoast dead.
    Who uses a CMS anyway nowadays? If you need a lot of customization you just pick up any random framework and code it. It’ll be faster than learning cms stuff anyway. WordPress actually does have a sort of an OOP structure with classes like WP_Query that WP functions wrap around. And frankly if your data model differs greatly from WP Post/Page model just create a table and query it yourself.

  • http://www.facebook.com/rickskuipers Rick Kuipers

    “Who uses a CMS anyway nowadays?” Are you serious? :P

  • boltcm

    This is something only the developer of a framework would say. ;-)

  • mindctrl

    “Who uses a CMS anyway nowadays? If you need a lot of customization you just pick up any random framework and code it. It’ll be faster.”

    I want some of what you’re smoking. :p

  • http://dinhe.net/~aredridel Aria Stewart

    Check out Modyllic — https://github.com/OnlineBuddies/Modyllic — it’s a PHP-based “schema manager”, which I’ve integrated with WordPress before. Creating tables and keeping the schema accurate is super easy, and doesn’t require the “migrations” that ORMs typically do: write your schema, and it applies the difference and updates the tables.

  • http://dinhe.net/~aredridel Aria Stewart

    And a blog engine is about managing the …content … of a blog^Wwebsite. It’s a CMS!

  • der5chlaefer

    Do you have a link to a version of WP Paladin?

    I’d like to have a look at it, but can’t find it…

  • mykle

    If you were going to rewrite WordPress from scratch, why would you use PHP? OO-PHP code is twice as miserable as procedural PHP code.

    As a programmer I agree that most of the limitations you mention are sucky, but I don’t see that any of the resulting problems you describe actually exist. WP today cheerfully exposes its contents in all kinds of formats — RSS, XML, JSON, whatever — and has plenty of mobile users, and zillions of modules, and fairly effective caching. “Dedicated frontend developers” won’t find Twig any easier than PHP, I wager.

  • http://www.setfive.com/ Ashish Datta

    Interesting perspective, although personally I prefer dealing with OO PHP since its much easier to reason about the code. Granted, as they say “you can write FORTRAN in any language” and I’ve certainly seen my fair share of crazy OO PHP.

  • http://www.facebook.com/sam.selikoff Sam Selikoff

    I came across this article talking about static site generators, and it reminded me of this post. I’d be interested to hear your thoughts on the future of CMSs, given the recent pushes towards static sites & the API movement.

    http://developmentseed.org/blog/2012/07/27/build-cms-free-websites/

  • Michael Gile

    what is “Doctrine Power Tools (DPT)”? I can’t find this anywhere, released or otherwise.

  • http://www.setfive.com/ Ashish Datta

    It was actually just a fictional library – it unfortunately doesn’t exist.