I think one of the major characteristics of anyone who’s a digital native – that is, anyone who spends a vast amount of time on the Internet and that has a certain level of proficiency – has no problem upgrading their apps to the latest version and tinkering around with the new features and/or looking for new bugs.

I mean, we can always roll back, right?

And when it comes to WordPress – especially for those who build things for the platform – it’s not at all uncommon to see us urging our users and others to upgrade, as well.

I love updates as the next geek, but we can’t blame others for wanting to wait to upgrade WordPress immediately, nor can we expect everyone to upgrade WordPress as quickly as we do.

Upgrade WordPress (Or “We’ll Do It Live!”)

Upgrade WordPress - Do It Live!

Upgrade WordPress – Do It Live!

For many of us, we love upgrade to the latest version as soon as it’s available. Heck, we even enjoy using the betas and the releases candidates just so we can test out the newest features.

This works fine for individuals, designers, developers, and more advanced bloggers, but if you’re a company who’s entire intranet or core application is built on WordPress, you’ve got an entirely different story.

For Larger Companies

For those companies who are powering their public and/or private sites on WordPress, odds are that they’ve not only developed custom themes or plugins, but more advanced tools all based on a certain version of WordPress and its API’s.

Clicking on that Upgrade Now link is dangerous because it can completely break the digital backbone of their business.

On Downtime

First off, upgrading without testing may lead to a busted site or intranet, and no matter how severe the problem is, downtime is lost revenue and that completely undermines parts of the purpose of even running a business.

On Development

When a company does decide to upgrade, it takes a significant amount of time and resources to actually perform the work to bring everything up to the proper level of compatibility.

Because, let’s face it: Although WordPress generally does a good job of maintaining backwards compatibility, it’s not without it’s faults.

For anyone that’s worked in a larger company, you know how this goes:

  • You setup a development environment with the latest version of WordPress
  • You branch the code powering the current version of the site
  • You work on upgrading the application
  • You undergo the QA process.
  • Assuming all checks out, you merge everything back into the main branch of the code and deploy

That’s a lot of work to be done for the sake of upgrading a version of WordPress especially when it’s not at all uncommon for a bug fix and/or a new security release to be updated hot on the heels of a major update.

On The Individual Bloggers

For individual bloggers – be it casual bloggers or professional bloggers – they may be comfortable with WordPress, but they may not necessarily be technologically savvy.

So if their blog looks like they want, they’ve got their plugins configured how they want, and they’re able to continue publishing without problems, what’s the problem?

Plus, many of these people don’t keep up with WordPress news (and that’s not a bad thing) so they don’t know what they’re missing in terms of new features or bug fixes.

Therefore, what’s their incentive to upgrade?

I’m not necessarily saying they shouldn’t (if nothing else for the sake of security), but I am saying that it’s not unreasonable to assume they are one, two, or three versions behind the current release.

A Note To Those Who Build

When it comes to troubleshooting WordPress-related issues, the first question that we should always ask users is what version of WordPress they’re using.

The problem is that we often take the wrong approach once we get the answer: Rather than trying to be responsible developers and/or designers and provide a solution by updating a our code or explaining that the theme and/or plugin is simply incompatible with their version of WordPress, we tell them they need to upgrade.

I get this mentality – I’m guilty of it – but it’s wrong.

We should not make something that’s our problem the customer’s problem. Similarly, when something is wrong with your car, Honda doesn’t tell you to buy a new car. Apple doesn’t tell you to buy a new Mac.

A mechanic attempts to fix the problem by diagnosing the solution and then providing one, if possible. This is the route that we should take.

This isn’t to say that users should never upgrade, but that we need to stop making our problem, their problem and do what we can to provide a solution. Perhaps that means a code change on our part, perhaps it means they can’t use our work, or perhaps it means we explain in clear terms the problem with incompatibility.

Whatever the case, asking users to do something that we should first attempt is bad business. And although upgrading WordPress may ultimately provide a solution, it’s not always the solution.