Supporting older WordPress versions in a Plugin/Theme?

The practice of only supporting latest WP version seems popular in WP development circles, yet there is massive percentage of blogs running outdated versions. Not supporting those plugins seems it can lead to significantly less usage than if (some) older versions are supported.

Support of older version comes with major issues, especially:

Read More
  • Complicated testing for multiple versions (unit tests?);
  • No access to latest functionality or having to backport it;
  • Incompatibilities of your code between WP versions (works in one, breaks another);
  • Wider hosting requirements range (older PHP and MySQL versions, dropped by WP).

  1. In your experienced had you ever had to support older WP versions in your code?

  2. Which organizational and technical practices had produced good results?

  3. What type of code do you use to manage the multiple version support.

Related posts

Leave a Reply

4 comments

  1. Supporting old versions of WordPress seems reasonable, but is it really necessary? Personally, I think supporting old versions is waste of efforts and time and it prevents end-users from updating their WordPress installs. What’s the point of being a WordPress developer if you’re encouraging users to remain using insecure and out-of-date versions?

    Just adding a function that checks the version of the DB/WP version and displaying a warning message if the site is running outdated version will remind the user to update; everybody knows how to update WordPress these days–just a couple of clicks and WoW, WP is running the latest version.

  2. I think support for backwards-compatibility for at least one major WordPress version is reasonable, though there’s also nothing wrong with requiring the current version. Some functionality just can’t be implemented in a way that degrades gracefully (see e.g.: Post Formats).

    There are cases where 2 major versions might be necessary, but anything beyond that really starts to push the bounds of reason. The pace of WordPress development – not to mention, the pace of discovery/creation of new exploit vectors – is such that it is imperative, with respect to both functionality and security.

  3. How likely is it that admins decide not to update WordPress, but still update the individual plugins? Won’t they just have forgotten the site? Set it up for a client, and then only touch it again when it needs an improvement (or is hacked because vulnerabilities were not patched…).

    If you don’t want to include too many backwards compatible hacks in your code, but still give the users of older WP versions some support, you could consider developing new features only for users newer versions of WordPress, but still backport security issues. So they can still use the features, and be sure that vulnerabilities that are discovered will be patched.

    Say version 1.5 was the latest where you still tested on WP 3.0, since 1.6 you only test on WP 3.1 and 3.2. If you want new features, you will have to update to plugin version 1.6, and update WordPress (or risk bugs). But if you are happy with the features of 1.5, you can install version 1.5.1 if it is released to fix a security issue in 1.5.