WordPress 4.0 Would Be a Good Chance for a Rewrite

May 22, 2013 by Matt | Posted in WordPress 8 Comments

WordPressIt’s no secret that the WordPress codebase is a mess. It seems that not a week goes by without some blogger publishing a post criticizing it. Unfortunately, fixing it is no simple matter.

One of the goals the WordPress project holds is to maintain compatibility with older plugins and themes that may not have been updated to work with the latest version, which means, well, not changing things that would break old plugins. Or adding new functions and leaving the older, redundant ones behind to maintain compatibility. It’s that methodology that led the developers to bake the infamous Magic Quotes functionality into WordPress itself, when it has been deprecated and removed from newer versions of PHP, so as to not break plugins expecting that behavior. (Which means plugin developers have to unescape strings before passing them to prepared statements, like they should be doing.)

That’s just one example of something I find vexing about WordPress, and not really indicative of the deeper structural issues that others complain about.

Sadly, the core developers would never agree to just dump everything and rewrite from scratch. It would break everyone’s plugins and themes, and it would take forever for them to be rewritten. That thought lead me to an idea, though. There’s a similar parallel to this: Python.

Version three of the Python language was released several years ago, but Python 2.6/2.7 are still used more widely than the latest and greatest. Why? Because scripts written for Python 2.x have to be adjusted to work with the newer version, which doesn’t retain backwards-compatibility. Projects like the Django framework are currently straddling the two versions, offering support for both through a compatibility layer, while slowly phasing out the older. Their plans are to slowly drop support for previous point-releases in the 2.x line while targeting Python 3.

A similar roadmap could be used with WordPress. Let’s say that WordPress 4.0 should be a completely rewritten, modern PHP application with a minimum requirement of PHP 5.3. The developer team would basically create a new dev branch and get to work, while still maintaining the 3.x branch for awhile. As the new version progresses, developers of plugins and themes could follow along and incrementally make changes to support any differences in the API. This would make it possible to do a full rewrite, and give the creators of actively developed plugins and themes a chance to catch up. (It’s high time to axe antique plugins designed for Magic Quotes and other PHP4 crimes against humanity.)

Once the 4.0 branch reaches completion, and the timeline for third-party developers to update their stuff nears its end, the 3.x branch is ended. Sites that depend on ye olde software could still delay updating until their dependencies are patched.

For another parallel, look to Laravel. They have the old Laravel 3, which people looking for a stable framework stick with, and the subject-to-change development branch, Laravel 4. The latter is significantly different, and will one day replace Laravel 3, but the older version isn’t being dumped until the shiny new version is 100% complete.

Personally, I think this issue is going to need to be addressed soon. WordPress’s reputation of being a “bloated mess of spaghetti code” is surely exaggerated, but certainly not unfounded. It needs work. Yes, it will cause incompatibilities, but that’s a part of the life cycle for any major software product. Sometimes you just need to cut the legacy software loose and begin anew, like Apple did with the OS 9 to OS X transition.

  • http://www.wordpresssources.com Mahesh

    Yes, that is what I often think about too. It often ends with high memory usage it seems. I wish WordPress 4.0 removes all the unnecessary code that are loaded to while creating a page

  • http://shanegowland.com Shane Gowland

    WordPress doesn’t use semantic versioning. WordPress 4.0 will be no-more a significant update than 3.7, 3.8 or 3.9.

  • RW

    I look forward to an efficient, more streamlined wordpress core. One without the built-in extra garbage, more security around the login process, and removing that annoying dashboard feed. Shane, I’m afraid that you’re probably right, but doesn’t the wordpress community decide what’s going to be involved in an update? What’s to stop the programmers/developers involved to not do something ground breaking for version 4.0? Glass half-full…

  • http://www.rosehosting.com/linux-vps-hosting.html Rose Hosting

    If the developers drop everything and start from scratch, won’t WordPress be a completely new CMS?

  • Dave

    How many times do we see posts about wanting to use wordpress as an actual application framework. Re-writing from scratch and making the entire application a framework that is modularized where even the blog itself is just a module could be a ground breaking thing to do. Heck, redevelop the entire thing under something like Larevel (Just one example) could be a real hit. Will it ever happen? I fear not… However, too bad as I think the proper framework thing could really be a serious boon for the future of wordpress.

    • http://www.photogabble.co.uk Simon

      It’s interesting to see posts like this article crop up from time to time. A good four to five years ago I myself would exclusively develop websites using WordPress; indeed it was one of the reasons why I began to develop my PHP skills.

      Then I got a job as a software engineer and began using frameworks such as CakePHP, CodeIgniter, Symphony and more recently Laravel3/4. Since having worked in an engineering environment working to tight coding standards, having recently started developing a few small websites in WordPress feels somewhat archaic.

      WordPress as a blogging platform is easy to use and pretty extendable however when you dig into the codebase it is amazingly spahgetified and would certainly benefit from a re-write. The reason why that hasn’t happened and is likely not to happen with WordPress is that the status-quo works, new features and bugfixes in a release are visible and thats what WordPress users are looking for – there would certainly be a degree of disapointment if after months of development the next version brought nothing to the table other than a rewrite of code that a large proportion of its users will see no benefit from.

      In addition a whole re-write would take a long time, we are talking six months to a year and yet even with extensive testing it would likely still break a lot of peoples websites, owned by people who aren’t knowledgeable enough to know how to fix it.

      With that said I have toyed with the idea of re-writing wordpress in a framework such as laravel(4) and on the surface it doesn’t “look” hard. I would use the sentry composer package as a foundation for the user authentication system and then build each distinct component of WordPress from the ground up such as taxonomy(tags/categories/etc), content(pages/posts), comments, feed, media, plugin, admin, multisite, etc. Given enough planning upfront you could map out each component and its requirements on the others and then begin building them in an order that would ensure you could finish one component and not have to touch it again until the project was complete (refactoring due to bad planning is horrible to go through.)

      Once that was done you would have to write a tool to migrate a vanilla wordpress install into it as it would have a considerably different database structure and then an additional component to provide legacy support to all the wordpress functions currently in use mapped to the new systems methods so that legacy plugins and themes still work.

      Once done you would have a modular “WordPress” clone, built for developers. However due to the use of a PHP framework and composer you would have restricted those who could use it to people with intermediate/advanced knowledge in PHP and server stacks. So to make it more accessible you would need to write an installer that sorted out the composer packages, ran migrations, seeded the tables and did housekeeping required before the system is ready.

      That is a lot of work for a team of developers, let alone one man on his own ;) Which is why I shelved the idea, even though I have written both the taxonomy and content packages. Doing the whole lot on ones lonesome is a tough, lonely job.

  • Muhammad Abbas

    Mirillis Action Serial key
    Hey admin your sharing way is unique. This is fantastic site…I enjoyed reading your articles. This is truly a great read for me.

  • FredLuis

    Great article, I unfortunately had some problems printing this artcle out, The print formating looks a little screwed over, something you might want to look into. pressure cleaning