If you ask a developer why WordPress has so much more success compared to other CMS like Drupal or Joomla, one concept will pop up for sure: Backwards Compatibility. Since the beginning of WordPress, its developers focused on one issue: Not to break functionality from one version to another.
One example are deprecated functions: Functions which aren’t used no more in one version won’t be simply kicked out. They remain in the core and will be marked as deprecated. They remain quite a while till they are finally kicked out. Long before this happens, developers can inform themselves on this page, which of the WordPress functions are deprecated. And also by using
WP_DEBUG they will be informed.
Another example is the database. The
wp_links table is currently of no use in WordPress. It sounds simple: WordPress doesn’t need this table no more and deletes it. But nobody knows, which data is stored in this table by single installations and how this data is used. To simply delete this table would have drastic consequences. Data, which WordPress users have collected with a lot of effort would simply disappear. Instead of keeping a consistent structure and remove this table, WordPress still keeps it, although it has no current use for it.
Related to this topic: Did anyone wonder, why the Post ID in the table
wp_term_relationship is called
object_id and not, like in any other table
post_id? Even rows of
wp_links used to be connected to terms. So back then, the developers decided to call this column
object_id, since it contained not only post IDs. But nowadays the column basically contains only post IDs. Still the name remains. Why? How many plugins are out there, who access this table via SQL and are using
object_id in their syntax? All these plugins would break! WordPress has a history and you can read its history by reading its inconsistencies.
Even in revised functions you will find examples: Take the second parameter of
load_plugin_textdomain() as one. You always have to set this parameter to
false. Until version 2.7 this parameter was carrying the relative path to the directory with the translations. Today the relative path is defined starting from
WP_PLUGIN_DIR and not from
ABSPATH. So the second parameter is deprecated and you define the relative path by the third parameter. But still, the second remains since old plugins might still use it. If you would remove this parameter, plugins would break.
From the user’s point of view, this all might look different. With every update the forums are floated with questions like “I just made an update and I can’t reach my admin no more/ I don’t see my pictures no more/ I can’t reach my site no more”. But all these questions lead us only towards two insights:
- How important backwards compatibility really is and
- how difficult it is, to realize backwards compatibility in an environment like WordPress.
For developers backwards compatibility is a double-edged sword, because it bloat your code. For some out of proportion. But if you consider the recent debate about security and the necessity to keep your system up to date, most developers conclude: there is no other way than backwards compatibility. Everything else would lead to a disproportionate effort especially for small bloggers and businesses or – if you consider almost 20 percent of the internet sites are run on WordPress – to a much more insecure Internet.
But: Is the concept of backwards compatibility only a topic for the core developers or do we plugin and theme developers have to be alerted too? Of course it has to concern us too. To update a plugin has to be a secure process which doesn’t break things.* Exactly like updating WordPress. This is the reason why Pippin Williamson, author of Easy Digital Downloads, gave a great speech on the Loopconf 2015 addressing backwards compatibility. I think every developer should watch this:
*) I have to admit, I need to do some work on one of my plugins as well to match the criteria of backwards compatibility. Well, not now, but this post shall be a reminder for me too 🙂