It’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.