Any valid reasons to upgrade from WP 2.9.2?

[Elpie]

In this scenario, can anyone give me valid reasons why an upgrade from 2.9.2 may be needed?

The client doesn't use the media manager at all, nor the visual editor. Widgets aren't used. He uses custom post types, with a plugin providing the UI. Security fixes were backported from the 3.x releases. He doesn't intend to ever use multisite. Auto-updates are off and the only plugins used are custom in-house code. Same with his themes.

He is convinced that 2.9.2 is faster and performs better. Does anyone know of any benchmarking that proves or disproves this?

I've been asked to give reasons why he should upgrade and have been coming up blank with reasons so would appreciate it if any of you can help me out with some responses. Thanks.

[Ryan]

Security upgrades.

In particular, there are major flaws in the kses functions. I'm not sure if they affect comments though, and if they don't, then those flaws possibly wouldn't matter in most situations. I had a good look through the source code when they fixes were made, but I couldn't actually work out what flaw they were fixing and there was very little documentation on the changes (for good reason, since they wouldn't want hackers figuring it out).

Other than that, it's mostly minor security upgrades that I can recall. Most of which are only a problem in specific situations, usually involving logged in users. If they don't have any untrusted logged in users, then I suspect the kses issue is the only one I can think of, although even that may not be a real issue.

[Elpie]

Security upgrades.

They gave me a list of security updates they backported to 2.9.2.

Defense in depth for comment text.
http://core.trac.wordpress.org/changeset/17192

Drop pingback/trackback blogroll whitelisting feature. Too many ways to abuse it.
http://core.trac.wordpress.org/changeset/16638

Some escaping
http://core.trac.wordpress.org/changeset/16367

xmlrpc security fix - only needed if remote publishing is used
http://core.trac.wordpress.org/changeset/16803

Critical security patch
http://core.trac.wordpress.org/chang...2/branches/3.0

List of changes:
http://core.trac.wordpress.org/chang...2Ftags%2F3.0.4

Harden check_admin_referer() when called without arguments, which plugins should avoid. (r17387)
http://core.trac.wordpress.org/changeset/17387

Force HTML filtering on comment text in the admin (r17400)
http://core.trac.wordpress.org/changeset/17400

Fix potential information disclosure of posts through the media uploader. Affects users of the Author role. (r17393)
http://core.trac.wordpress.org/changeset/17393 *

Fix XSS bug: Preserve tag escaping in the tags meta box. Affects users of the Author or Contributor role. (r17401)
http://core.trac.wordpress.org/changeset/17401 <= not backported from 3.0.5 (not needed?) *

Fix XSS bug: Properly encode title used in Quick/Bulk Edit, and offer additional saniziation to various fields. Affects users of the Author or Contributor role. (r17397, r17406, r17412)
http://core.trac.wordpress.org/changeset/17397
http://core.trac.wordpress.org/changeset/17406
http://core.trac.wordpress.org/changeset/17412

* They don't have registration open and don't have untrusted users.

I've tested his changes out and everything performs well (surprisingly). I'm finding all this a bit awkward - first time I've been stumped for any arguments for upgrading!

[Ipstenu]

Future plugin compatibility. Make a list of the ones he uses and check how often THEY upgrade. Many drop support for older WP as time goes by. I do.

[Otto]

They gave me a list of security updates they backported to 2.9.2.

Reason to upgrade: To prevent a whole lot of unnecessary backporting.

In reality, 3.1 is faster, but not generally in areas you'd notice. Minor enhancements happen all the time.

[Elpie]

Reason to upgrade: To prevent a whole lot of unnecessary backporting.

In reality, 3.1 is faster, but not generally in areas you'd notice. Minor enhancements happen all the time.

In contrast - the backporting of security hardening only has to happen once (unless previously unidentified vulnerabilities are found). So this ends up with a stable, secure platform and no hassle with updates.

The company doesn't permit auto updates because they have to check that their modifications work and run their security tests before deploying. So, staying on one version saves them a lot of work in the long run.

It's an interesting thing to ponder but instead of me convincing them to keep moving forward with WordPress updates, the opposite thing has happened - I find myself agreeing with them :-)

[Ryan]

Perhaps they should be using a different piece of software. It seems like they're more interested in using a custom solution than a constantly updated system like WordPress.

[chipbennett]

Perhaps they should be using a different piece of software. It seems like they're more interested in using a custom solution than a constantly updated system like WordPress.

But they're doing exactly what Free Software promotes: they've developed their own derivative of WordPress, and using it according to their own needs as the end user.

[Otto]

The company doesn't permit auto updates because they have to check that their modifications work and run their security tests before deploying. So, staying on one version saves them a lot of work in the long run.

Since starting to work for matt, I've noticed that WP/Automattic tends to take the opposite approach. Most of their properties (wp.com, wp.org, half a dozen others I can think of) actually run on trunk, or reasonably close to it. Whenever I push a change to wp.org, I'm pushing the latest trunk WordPress code to it too. Thusly, everybody tries very hard to avoid making breaking changes to the core code except in special cases. This also means that any modifications as in plugins and such tend to be carefully chosen or carefully coded to survive upgrades and changes.

I've tended to go this route too, now that I use the sandbox system for testing changes. I can run my very own wp.org, with live production data, making any changes I want, testing them, and only committing them when I'm satisfied they don't break anything. Then I can deploy the whole thing with a single command. It's a very fast system to work with.

Does this mean more breaking the site? Sometimes. But only for a short time. Since we can run the entire site in a personal sandbox space, this doesn't happen very often. It also ensures that we're using the latest code all the time, and thus have desire to fix/improve it when there's something wrong with it.

Basically, breaking the live site for a short time is not generally a big deal when you are able to fix it rapidly too. Putting up with an inefficiency or a bug for long periods of time just because you have some kind of deployment schedule or need to do epic amounts of useless testing is kind of a pain in the ass.

And yes, "useless" testing. There's nothing wrong with testing, but there is something wrong when you have to go through a huge amount of testing for a simple feature change that you *know* only affects one small piece of a very large system. You should know what the change is and what the effects will be when you're writing the code. So should any other coder worth his salt. If you don't know that it won't break anything, then you shouldn't be the one making the change, or you shouldn't be making it alone. Peer review of larger changes is better than having large and pointless test procedures.

[Ipstenu]

And yes, "useless" testing. There's nothing wrong with testing, but there is something wrong when you have to go through a huge amount of testing for a simple feature change that you *know* only affects one small piece of a very large system.

Were you just in the meeting where I argued this? ;)