How Does WordPress Maintain Backward Compatibility Over Time?

Backward compatibility is one of the pillars of the platform that comes with the highest priority. Over the past ten years, the technological progress in WordPress has been moving somewhat slowly, but that ensures that no WordPress website would be left behind.

For quite some time now, WordPress is officially supporting all PHP versions starting from PHP 5.2.4. Of course, PHP 7 is the recommended version for all hosts, but it would be unfair to bump it up to 5.6 and screw tens of millions of websites that still run on low-quality hosting infrastructures.

Stats gathered by all websites running WordPress to date are publicly available as well. Approximately half of these websites run PHP 5.2 through 5.5:

WordPress Compatibility For The Majority

Instead of ruining an entire empire of small businesses who have no clue about PHP versions and technical jibber-jabber, the WordPress leadership team (and all of us, contributors to the platform and the community) advocate PHP 7 and push for its support with every hosting provider that we have to work with. This naturally increases the adoption and upgrades business owners to the latest and greatest (well, at least 5.6 which is still awesome).

At some point, when there are almost no providers that still provide PHP 5.2, 5.3 or 5.4 hosting plans, the minimum supported version would be incremented as well. This would allow for refactoring iterations introducing PHP improvements such as late static binding (that is currently not supported in older PHP versions).

PHP – as a programming language – has also been very tolerant in terms of backward compatibility. You could break plenty of applications migrating across Python versions or .NET versions, but that’s (almost always) not the case with PHP or Java. Which is why WordPress is carefully designed to get rid of all deprecated snippets that were not supported in PHP 7 while maintaining complete compatibility with PHP 5.2.4 as well.

Backward Compatibility For Other CMS

Drupal has also been one of the reputable CMS in the PHP space that always carries the latest and greatest from a developer’s standpoint – being the “cool kid on the block” for geeks. But the lack of regular major versions and completely impossible update cycles have led to Dries (the platform founder) to finally adapt the safe updates model just as WordPress does, or software applications like Chrome – seamlessly and flawlessly:

One of the key reasons that Drupal has been successful is because we always made big, forward-looking changes. As a result, Drupal is one of the very few CMSes that has stayed relevant for 15+ years. The downside is that with every major release of Drupal, we’ve gone through a lot of pain adjusting to these changes. The learning curve and difficult upgrade path from one major version of Drupal to the next (e.g. from Drupal 7 to Drupal 8) have also held back Drupal’s momentum. In an ideal world, we’d be able to innovate fast yet provide a smooth learning curve and upgrade path from Drupal 8 to Drupal 9. We believe we’ve found a way to do both!

While Dries is right about the relevancy (I’m a fan of many innovations brought to Drupal), facts are that WordPress powers 28.2% of the websites online compared to 2.3% ran on Drupal. I know that those are merely stats, but from a small business’ standpoint, backward compatibility and safe maintenance are absolutely critical.

In terms of code compatibility, the architecture of the top 3 CMS in the PHP space is incredibly generic, thus flexible. It doesn’t follow the top normalization principles in the RDBMS world but instead allows for introducing new data types on top of what is already available. This means reusing the same database APIs for everything – be it products, galleries, contact forms, job offers, forums, or any other database object that can be represented as a Post.

WordPress Plugins and Hooks Consistency

Let’s touch on the plugin APIs as well – most of them are related to:

• creating new object types – through the Custom Post Types API always saving data in the {prefix}_posts table and the {prefix}_postmeta table.
• creating new taxonomies – other than categories or tags – stored in {prefix}_terms, {prefix}_term_taxonomy, {prefix}_term_relationships
• saving new options, settings, widget parameters – stored in the {prefix}_options table
• creating and managing users – {prefix}_users and {prefix}_usermeta

The generic model allows for building extremely flexible yet simple APIs. Database schema is always consistent, which makes the APIs fixed, and the plugins’ code easier for upgrades across major versions.

The hooks architecture is also massively powerful – tons of actions and hooks which can be reused for external activities without messing up with the entire life cycle. Pretty stable core infrastructure with numerous hooks for developers to use in order to extend the core platform’s behavior.

That’s quite different as compared to an MVC framework – you’ll need a set of controllers, a model, multiple views for each new data type unless you end up with the so-called God/Fat Controller that’s totally bloated and non-maintainable.

WordPress Core Life Cycle Explained

Take a look at the WordPress life cycle by Rarst – it’s fairly straightforward, with several entry points and a few major life cycle layers that could be used for everything (along with another couple thousand hooks in-between):

This has been the main flow of a WordPress request for many years now, and sticking to it prevents major regressions while introducing new enhancements to the platform.

There are several major entry points for admin callbacks, the WordPress front end, and AJAX calls triggered by a theme or the plugins. Overall, the consistency between hooks distributed across a website is fairly straight forward. For WordPress plugin developers, it’s all about studying several dozens of popular actions and filters used in most cases, and identifying the ones that would be applicable and helpful in certain situations.

That said, once your life cycle is set in stone, your database schema doesn’t need updates and you can build everything on top of the current data structure, what could possibly go wrong?

As a final note, I’ve discussed the WordPress Core architecture at a PHP conference as compared to a bunch of PHP frameworks, Django, Rails, ASP.NET MVC and a few more solutions that I’ve used over the years, it may add some extra context:

This post was originally published on Quora as an answer to “How does WordPress keep its code maintainable, tidy, and compatible (e.g., with PHP 7) while being compatible in its API with older plugins?”

Eager to deploy WordPress in your organization or scale a platform with up to 10M page views a month? My first consulting advice is free.