Backward Compatibility – Is It A Good Idea?

WP Rocket has been backward compatible to WordPress 3.1 since version 1.0. We designed the plugin for almost everyone, even if you can’t update your website.

Similarly, WordPress itself is backward compatible to PHP 5.2.4.

What is Backward Compatibility?

In cases where one piece of software relies on another piece of software (or other component) in order to function – such as how WordPress relies on PHP – backward compatibility means that you can still use a piece of software even if the other required components are not updated to the latest version.

So you can still run WordPress even if your version of PHP is not up-to-date. Likewise you can still run WP Rocket even if your version of WordPress is not the absolute latest.

The goal, when you develop something with backward compatibility in mind, is that your product/service can be used by more people, even if they’re not using the latest components your product may require.

Sounds Reasonable, But Why is it Not a Good Idea?

It sounds good – more people means more customers – all you have to do is to be sure that your code can be used in many previous versions and you have to find a fallback function or something to “patch” this lack.

Why is this not so good? Because you always have to check that what you’re doing can be used with older versions. So with every release it becomes more work to maintain.

Over time this creates a halting effect on the code that makes it nearly impossible to clean up and “make things better”.

In regards to WordPress, PHP 5.2.4 is not maintained and not recommended. So, even though WordPress can actually work with 5.2.4,  I recommend you use PHP 5.4+.

In the case of WP Rocket, trying to make the auto update feature backward compatible was a bad idea, and I didn’t want to include all the code from WordPress 3.7.

Forward Thinking, Forward Compatibility

I think that we’ll ease off about the backward compatibility and not worry about trying to make everything work for a lower version of something else.

Instead of thinking only about backward compatibility, we’ll try to think also about forward compatibility, much more clever than just backward.

Forward compatibility means that you’ll have in mind the future of the code, not just past and present. The goal is to avoid unnecessary backward compatibility.

About

Creator of SecuPress, Julio is also co-organisator of WordCamp Paris. Compulsive speaker and WordPress expert, he's a specialist in security since 2002 and contribute to WordPress various ways.

Subscribe to our newsletter Latest news of the rocket, at the speed of light!

2 comments

Comment

Good point!

I actually would like to go a step further.

In an ideal world, everyone is running latest version of WordPress and plugins.

As plugin developers we actually have the power to force people to update their WordPress version.
Well, the user either “obeys” and indeed updates or removes your plugin, so you just have to make sure that your plugin does something supercool.

In most of my plugins I have included a minimum WP version check and when a new WP version is released I actually update them to reflect that minimum version, which I usually set 2 versions below current.

I think this makes much more sense than to try to be a product that you can use with some prehistoric version of WP, who would want that anyway?

Here’s to hoping that someday we can enter that ideal world!

Definitely, it is extra work to test with all the previous versions up to WordPress 3.1. May be you should limit only to 2 versions from the current one. So that, you can speed up your development process, and it is better to make it future proof 🙂

Leave a Reply

Your email address will not be published. Required fields are indicated by *