What is the importance of writing a < WP 3.x compatible plugin nowadays?

3 Views

I am currently writing a simple-ish plugin with custom posts and a couple functions, using post metadata and adding a couple of variables to the “options” table in the database. During my research, I saw some references in the WP Codex about making the plugin backwards compatible with versions before WP 3.x and I was just wondering how important it is now to incorporate that compatibility.

For instance, the oldest version of WP I ever saw installed (by a client) was 3.2, or somewhere around there. I cannot imagine many people having anything older than 3.x but I could be wrong. I know in theory you should always try to make it perfectly compatible but, realistically, does anyone know how important it is to include that capability?

Read More

Thanks

Post Views: 3

Related posts

5 comments

  1. Always write plugins for the current version and keep the nightly builds from the upcoming versions in mind. Anything else doesn’t matter.

    Edit As @toscho pointed out in a comment:

    There might be some explanation needed to why it is that way.

    1. Because I say so.
    2. Plugins only need to be compliant with core because if all play with the rules, nothing will fail. If one plugin doesn’t play with the rules, then it has a bug. And that bug needs fixing and not anything else and not another plugin or theme.
    3. Users not updating WordPress is a result of buggy plugins that are used and can’t get abandoned in systems without a lot of work. As written in (2), that’s bugs you don’t have to care about. The bugs need fixing, not your plugin considering broken third party code.
    4. Legacy Code needs no support. It needs replacement. Not your problem.
    5. Things change on a large scale over major X.X versions. When you try to support previous versions, you often need different workarounds and lots of version checking. That is (a) a maintenance nightmare (b) increases the code base (c) makes unit tests impossible as they’ve to run on one version – not less, not more and finally (d) decrease server disk space and performance (in most cases).
    6. WordPress already has a very old code base that lacks improvements in lots of edges and corners. In short: WordPress is old, uses a not longer supported PHP version as its minimum and therefore you’re already supporting previous versions in much lower levels than in the public API of your application.

    Now go ask yourself:

    When you’re already supporting an no longer supported PHP version, why would you want to support an application that isn’t even supported by its creators?

  2. Remember the release of WordPress 3.0 required PHP5. At the time, many hosting companies were not yet running PHP5 on their servers. So there was a period of time when some WordPress sites COULDN’T update to WordPress 3.0 because their hosting companies were not keeping their servers up to date.

    Many years have now passed (3+) since the release of WordPress 3.0, so being backwards compatible with WordPress < 3.x is not very common plugins.

  3. Most WordPress installations are outdated. Currently, only 5.2% of all installations are running on the latest release 3.6.
    27.3% are still on version 3.0.

    You might think you have to support these old versions with compatible code. But think about the implications:

    • You have to test all officially supported versions.
    • You have to handle incompatible APIs like the media uploader, which changed drastically in 3.5.
    • You make your users think it is okay not to upgrade WordPress, because it still works.
    • You need more code, more tests and more time for support to do the same things.

    And the users of these will probably not even install your plugin because they know already new plugins break their site. In terms of market reach you might win a little bit with backwards compatible code. In terms of efficiency you lose.

  4. My rule of thumb for plugins I write is support for the current version minus 1, so all plugins I’d write would be compatible with 3.6.x and 3.5.x. While a particular plugin may work on earlier versions, I don’t guarantee it nor support it if you run into problems.

  5. Four months ago, I took over the maintenance of a popular plugin. Before I started working on it, the plugin hadn’t had an update in 2 years. I made a bunch of bug fixes, released the new version, and 2 days later heard from a guy who said the new version caused the white-screen-of-death on his site. After I looked into it, he was still running WordPress 2.9.2, and my update used the home_url function, introduced in 3.0. I have no idea why the guy decided to update this plugin immediately, even though he hadn’t updated his WordPress installation in 3 years. When I made the new version, I never thought to test WordPress 2.9.2.

    Here is the moral to the story: In your plugin’s readme.txt file, there is a “Requires at least” version number in the header. Use it. As you make updates, if you don’t feel like testing old versions, increment it. That will discourage users refusing to update their WordPress installations from updating your plugin.

    I’m currently writing a new, related plugin, and I’m planning on making it WordPress 3.6 only, because I want to use the getid3 library included in the core. I have no desire to release a new plugin for an old core version.

Comments are closed.