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!
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.
Good post! Personally I make a point of assuring that my non-tech-savvy clients do not have to deal with updates and the issues that come forth out of it themselves. This way they can focus on what they do best, and I focus on what I do best!
You’re exactly right.
I’d even go far as as to say that for some client installations – depending, on how tech-savvy they are – you could even hide the upgrade notice for plugins, themes, and WordPress so they aren’t even aware that there’s something to change.
Yes very true, we can suffer from the urge to stay updated, and to not have to support older versions (a mental throwback to IE 6 perhaps?). It is hard on users especially when they are using various plugins or a theme that haven’t been updated for a while themselves, suddenly to be faced with a new version of WordPress and incompatibilities left right and centre.
“Apple doesn’t tell you to buy a new Mac.” But I don’t agree with this :)
Yeah, I think that developers, designers, and generally for tech-savvy people get the itch to constantly stay updated, but, as you mentioned, this can be detrimental to customers.
One of those things we’re responsible to manage, for sure.
Meh, in some cases. Fair enough, though – you get the point ;).
Larger companies should rethink the costs and benefits of what they are doing, or even the value of using WP when viable upgrade-in-place options exist. If custom theme and plugin development leads to about the same practical outcome as “hacking the core,” that’s a problem — a security problem.
I think you bring up an interesting point. Personally, I’ve yet to find a framework or application foundation that doesn’t bring a set of headaches when it comes to upgrading – be it .NET, Rails, etc.
That’s not to say that WordPress is better – I don’t really think it is, I just think that maintaining software versions and dependencies is tricky stuff. With the way the web is going, it’s getting easier to maintain the software, but we’re not “there” yet, you know?
Anyway, your point on hacking core is spot on. As far as I’m concerned, core files are off-limits. They should be treated as binaries.
Very true; painless upgrades are an ideal you might realize more through luck (and application of the KISS principle) than any in-built characteristic of a particular framework, but aren’t there unique things about WP that might give it a higher risk of upgrade breakage relative to the amount and type of customization you do with it?
What I meant about hacking the core is that it often feels to me like a lot of WP customization is similar to doing just that, since it still creates the risk of something breaking when the core changes. Elaborate frameworks that extend and modify the core API are perfectly legit and useful; this is what needs to be done to take WP beyond its blogging oriented core self. Yet the complex dependencies that result are what cause the “don’t upgrade–yet” scenario, aren’t they? In a real-world context of limited budgets, bureaucracy, and zero-day exploits, that’s a problem. It’s potentially less of a problem if your core product does more of what you need on its own, or if it makes a tighter separation between presentation and logic.
This isn’t an anti-WP comment. I use WP a ton, but when it comes to more complex customizations, I find myself calculating the tradeoffs in using WP, which include the future total cost of owning and maintaining it.
Within the range of PHP based “CMS” products there’s a lot of diversity in this area, from core products that have a completely standardized presentation framework or do absolutely nothing with presentation. Themes developed on those systems ought to be rather future proof. Significant extensions to logic and functionality on the other hand will probably always be a source of upgrade trouble even for quality code that’s maintained vigilantly.
It’s as if you are talking to me personally…
We (internet agency) always update our clients WordPress websites as soon as possible. With service agreements we take responsible for these updates. A solution for small websites might be not to update. Instead, at development install a backup plugin and take care that the website is periodically updated into the cloud. Whenever something happens there is always a safe backup that can be restored.
You’ve got it figured out, Erwin. That’s how it should be, in my opinion.
When you deliver a solution to a client, you should also include some level of support or at least bring up the option for an agreement; otherwise, if the user is left to manage it themselves, they can do more harm than good which may ultimately cost them more money rather than having the support option to begin with.
Do you mean “small” or “static?” Yes static, “brochureware” type sites that have changes made to them over long periods of time can be safely backstopped from harm by proper hosting and security plus a safe backup. The problem that arises then is from people who choose to let their site ferment in its obsolete juices until disaster strikes or the server stack passes them up. Having had clients like that, I’ve actually shifted to avoiding them or impressing upon them the value of a simple content strategy, putting them on a hosted service, or doing static sites for them without a CMS or SQL. “Normal” WP (and other) sites get updates pushed to them as they come, with special handling when things break or seem liable to.
Hi Tom,
Good to see this post, especially since it goes against the presumed mantra in the community that everyone should always upgrade. Upgrading is a good idea for many reasons but often there are even better reasons not to upgrade. Glad to see you make that point.
Thanks, Mike – you’re right on and I’ve tried to outline many of my points in the posts and in the comments.
This is just one of those things that I see causing more problems for less experienced users that we – as developers, designers, implementors, or what have you – have a responsibility to manage and to own that.
And I see far too few of us doing this.
Mike, you say “there are even better reasons not to upgrade”, what reasons?
Upgrading to a newer version, in most cases, is mandatory. Unlike other software, WordPress actively support only that last branch. Which means all older branches are not supported and they are not secure.
I will repeat that – all older versions of WordPress are not secure. It’s not “Microsoft Windows”, you don’t get 10 years of upgrades for each major release.
When you are using WordPress you have to upgrade. And your clients have to be aware of that. It’s your job to tell them that.
Hi @Rami,
I think Tom covered it pretty well in his post, but since you ask I’ll be more explicit albeit in a general way.
If the cost to upgrade ($cu) is greater by a significantly percentage ($sp) than the estimated cost of a realistic worst-case exploit ($ec) times a risk factor ($rf) then don’t upgrade:
It’s not black and white. It’s a business decision, not a technical one.
The fact that WordPress is insecure is not always relevant. If the site is not hosting visitor accounts and is on a server that is not connected to any other systems of concern and the risk of allowing the site to be hacked is low and current backups are maintained and a few hours of downtime would not really matter and recovery would be easy and it costs a large amount of money to upgrade because of customization that breaks on newer versions then it doesn’t always make business sense to upgrade. Except for “current backups are maintained” the above describes many personal sites and a lot of small business sites.
Yes, it is a best practice to upgrade, but it’s not always the correct business decision. Best practices are rarely absolutes.
If you have clients then yes it is your obligation to make them aware of the risks of not upgrading. But it is not up to you to make the decision to upgrade for them. If I had to guess I would expect that most often the choice not to upgrade comes from the client for cost and/or resource reasons; that has certainly been my experience.
If it’s your own site then you get to make the decisions for yourself. I have chosen not to upgrade sites that if I lost wouldn’t really matter to me.
And if you are doing support for a theme or a plugin then you don’t have an agency relationship with the user regarding their site and you can’t decide for them if upgrade is the appropriate choice, nor is it your responsibility. Only they are appropriate ones to make the upgrade/no upgrade.
To summarize and clarify, upgrading is usually best approach but there are legitimate circumstances for which is not.
That’s good stuff Mike. Thanks for sharing it.
-1
Sure I agree in principle that you should not upgrade just because there is a new version, but usually there is a reason why there is a new version. your formula don’t take into account the $benefits_from_new_version*$money_made_by_using_them (maybe the changes brought a faster admin, saving you time when publishing new posts) and ignores the $time_to_make_complicated_multi_version_upgrade*$cost_of_hiring_mike_schikel_for_an_hour that you will have to pay once you will decide to upgrade if you are very far behind the upgrade curve.
Yes, you can decide for yourself when and what to upgrade, but you have a unique knowledge, probably better then most people hacking WP for a living, and don’t forget that most WP sites are not maintained by a pro at all.
If you upgrade, and your upgrade fails, you should be able to revert (WP core should be improved in doing this by default) and then you know that you have a problem and can decide if and when you should dedicate resource to solve it. Ignoring the possibility of upgrade failure until the time in which you have to upgrade, a time in which you are usually on a tight schedule, will cost you more money and stress then a frequent upgrade.
It is the responsibility of the people building the site to take upgradability as one of the core goals of the site and build it from modular components that will be easy to replace or cheap to repair if they break on upgrade. I have seen too much bad unmaintainable code from people I have been told where experts.
But all this is really avoiding the main issue which is money. In true open source spirit no one is willing to pay money to have backward maintainable plugins and themes they got for free. For money I will be happy to backport any new functionality of a free plugin or theme, and even upload the forked plugin to the repository, heck I’m sure that for money the authors will do it themselves….. Calling the unpaid authors to keep supporting older WP version to the benefit of greedy businessman is very cynical.
Hi @Mark k,
Try as a I might after reading your comment I still don’t really see what you said that contradicts my point, except maybe that my decision formula for all-inclusive of every possible consideration?
Fine. But you are treating these formula factors as if they are all quantifiable in the ways we can count money in a bank account. They are subjective and thus guidelines, and my own reason to reduce them to a formula was to make argue against the assertion that because older versions of WordPress can be insecure that the only viable action is to always upgrade 100% of the time. I reject that fundamentalism, and if I read your reply correctly you acknowledge the same?
So the fact my formula wasn’t complete really doesn’t matter as the only reason it was there was to argue there *are* valid reasons *not* to upgrade. With that do you disagree?
If you look at my formula you’ll see that the consideration were business considerations, not technical ones. The cost of an exploit may be bad PR, etc. But in some cases that really doesn’t matter.
Yes. But that’s forward looking and doesn’t not take into consideration existing circumstances, which is what my point is about. We’ve all heard the old adage that hindsight is 20/20 but unfortunately few forward actions are taken by people with the benefit of hindsight.
Now that’s really a different discussion, isn’t it? :)
Funny, I thought that was exactly what my formula was intended to address, that cost of upgrading — money, or time — is a major factor to consider.
Funny, recently I’ve been active on another comment thread on this blog where I’ve commented about effectively that same sentiment. I assume you’ve missed that thread?
I’m hoping that wasn’t an implication aimed at me…?
Finally, if you are going to individualize your examples to include my name, can you please at least spell my name right? :)
LOL, sorry for the misspelling but my point was relating to you and other core developers/contributors. You track trac and the development blogs and probably get on IRC and the hackers list, therefor you have the knowledge to quantify the various parameters in the formula.
I never said the S word in my comment because I don’t think that security should be the only reason to upgrade, and a new version may always contain new exploit. But how can you even start to quantify the damage from a security breach without knowing what form will it take? If I can install a mu plugin that sends to me the passwords you use on your site I can very likely use this info to get into your gmail account and the amount of damage I can do from there is much bigger then PR damage.
So while in principal I agree that someone qualified enough can use your formula, I just don’t think there is any living person qualified enough for that, and if there is, the cost of using his service will be much greater than upgrading. If you have the backups to recover fast from a security breach (which you always should) then why are you hesitating to upgrade?
I simply don’t see any true reason to avoid even trying to upgrade. If a blogger/business is not feeling like doing that minimal, almost risk free effort, then why should anybody do extra effort for him, and backporting is an effort.
And the cynicals are the users of themes and plugins that get upset for not getting free support on their terms. If they want support they should pay for it. Try to get them to do anything for free…
To sum it up. upgrading is best practice. and most people are running current or one before current versions, so why should developers set up development environment for earlier versions? It doesn’t make any economical sense.
It is a legitimate decision to not upgrade but it has drawbacks and people that decide to follow this path should simply accept them and not complain about them.
I find that ironic because I often feel on the outside when it comes to the group that would be considered “core developers/contributors”; just look at how rarely they address one of my issues on trac. But I digress…
Respectfully speaking I think you are allowing a pre-concept of me cloud your perspective on this discussion.
I apologize if it appeared I implied that you did; was not my intention. I mentioned Security because the reply you gave a “-1” to was itself a reply to someone who claimed Security is *the* reason someone *must* upgrade (emphasis mine.)
That comment right there tells me you have not yet grasphed the point I was attempting to make. Not all websites based on WordPress are mission critical nor have confidential information that would be damaging if exposed. In those cases the need to restore from backup is often all the potential damage that can really occur.
Only if the site really matters, and only if there are other users allowed to create accounts on the site or if the owners use bad password hygiene.
Yes, for a mission critical site. But not all sites are mission critical. That’s the KEY point, please acknowledge that in any further reply.
I never said I was hesitant, I said there were good reasons to not. For example, when custom development is incompatible with new versions and the cost to redevelop is prohibitive or the site is not a priority.
This is starting to feel like a “religious” argument. I can understand differences in values related to abortion, and gay marriage but do we really need to elevate upgrading WordPress to that level of acrimony?
Did I ever say anything about backporting plugins? No I didn’t, and I think that’s one of the things people who don’t upgrade rightly need to accept.
_Question:_ Have you developed a plugin and then had unreasonable users demand you backport their plugin because they don’t want to upgrade? Is that where your strong feelings are coming from?
FWIW, if it is I agree with you; if users want to use the new features of your plugin then they need to upgrade WordPress. Period. If not, then the old version is all they get (unless they pay you for it and you want to accept payment to do the work, of course.)
BTW, for our clients I have to maintain backward compatibility because that’s what they pay us for so they can reach a wider audience. But that’s completely different for plugins offered to the community by altruistic developers.
I’m in complete agreement with that. But that concern is orthogonal from the rational and informed decision not to upgrade.
Agreed. But like leaky abstractions there are few (any?) best practices that necessarily apply 100% of the time.
It’s becoming clearer to me your response on this thread is based on your experience with unreasonable end-users. And I’m in 100% agreement with you there but please do acknowledge that I posted about another albeit tangentially-related issue.
I’m all for a statement published somewhere canonical for the WordPress community “signed” by all “core developers/contributors”, and myself, that explains in simple terms that users can expect reasonable support if they upgrade to current versions but if they don’t all bets are off and all support is on them.
Finally, you state my exact thesis perfectly! We are in sync. :)
grr, made a long comment and lost it, so we will just agree to disagree on the importance of upgrading and whether there are real life valid reasons to avoid it.
In addition I opened this ticket http://core.trac.wordpress.org/ticket/23720. I don’t expect anything to happen as a result, but sometimes miracles do happen.
We should also remember that WordPress bundles 4 types of “updates” together in a new point release:
* UI changes (major and minor)
* Bug Fixes
* Functional changes (new features)
* Security patches
Each of these has to be valued individually on a case by case basis. I think we would all want every WP install to be as secure as possible, but to ignore the trade-off that brings in terms of UI changes, or workflow changes would be folly.
We also need to remember that the “WordPress Core” is not always completely standalone or silo’d in it’s functional reach. It took just over 2 years to launch bbPress2.0 and a further amount of time for bbPress2.1 to launch with the functionality to move an original bbPress site over. For two of my large clients that meant not upgrading WordPress for 26 months. bbPress 0.9 had a dependancy on WP 2.9 (and thats with a hack to make SSO work – it actually only worked up to 2.7/2.8).
If you saw my WPUK talk from last year, you’ll have seen that upgrading a University intranet site to WP3.3 caused an increase in support requests by over 275% due to the UI changes (we stopped monitoring in that stage and had to change how we handled the requests).
3.3 also made WP’s admin section an incredible inaccessible nightmare. None of our Government, Education nor Charity sector clients could upgrade from 3.2 to 3.3 (or 3.4) as doing so would have put them at risk of failing one of our anti-discrimination laws. I raise this point to show that it’s not always a technical decision on whether to upgrade or not – there has to be a business case on the risk of upgrading versus the risk of not upgrading, and that is different for each organisation.
I think many “techies” out there as well need to accept just how many clients are using older versions of Internet Explorer than you’d like, and also how many are working with JavaScript turned off. This becomes especially true when you move into the enterprise market. WP in the last 3 releases has been *difficult* for those markets, even in traditional roles such as intranet blogs, WP is getting a very bad name.
My motto is this: you should keep your software as up-to-date as you feel comfortable with. To some of you, thats the nightly. awesome. To some of you, thats the last version that works with your dependancies. awesome. To others it’s somewhere in between.
If there’s one thing I’ve learned in life, and I’ve probably only learned 2-3 things, it’s that you cannot make sweeping generalisations about what people should and should not do, and expect them to be applicable.
“Thou shalt upgrade”
– Matt 3:16
“Thou shalt way up the benefits of “change” versus the negatives of “change”, and do what is best for you”
– Kevinjohn 3:16
I think your break down is spot on. Specifically:
I’ve been trying hard to avoid bringing up the security issue not because I don’t believe in it, but because I think it’s a can of worms that should at least be dedicated to a discussion in another post, but since it’s already come up, I’m fine discussing it.
The thing I view about security is that people use this and a blanket argument for why WordPress should always be upgraded. The thing is, not every update to WordPress implements new security updates.
On top of that, I think that the level of security is proportional to the use case of the site. If you’re a single blogger, your level of security is no where near demands what, say, a multi-author web application storing sensitive acme type requires.
Don’t read me wrong: I’m not dismissing security. It’s important. But it’s also relatively to a degree.
This is fascinating – I’ve never even considered this as a potential issue.
As someone who primarily builds sites and applications for others, I don’t ever work in this particular sector of the industry (and I have no desire to either, so you’re a brave guy ;).
Yes – I’d also say that although you can’t force users to upgrade WordPress, you can select what versions of WordPress your work will support. Those are two completely different things.
There’s nothing wrong with amputating previous versions of WordPress for the sake of your plugin, but I just don’t believe in forcing users to upgrade WordPress when you’re not completely aware of the circumstances surrounding their implementation.
In short, consider me preaching the gospel of Kevinjohn 3:16.