First, I’d like to say thank you to the team here at WP Realm for allowing me to join and contribute to what has become a very valuable source of WordPress community related news. My name is Scott Basgaard, a WordPress “fanboy” and Support Ninja at WooThemes, and I’m teaming up with Mason James and Andrea Rennick to deliver a weekly column here at WP Realm from the trenches of the support world. We hope to bring you an interesting article and/or story from our experiences helping out others in our daily support routines. With that said, let’s talk about upgrading and staying up to date with WordPress as it’s something I constantly run into.
It’s safe to say one big reason for WordPress support related issues is due to the fact that the user is simply unaware of the importance to stay upgraded up to date.
Not just the core WordPress install, but themes, plugins and additional add-ons/extensions. A well developed product isn’t released and left stagnant to age and die off, but is constantly being taken care, via new features, bug-fixes and security patches, to stay “fresh” and compatible with WordPress as it continues to release new features and functionality, and to keep up with the rapidly-changing internet as well.
When I’m helping out a user with a specific issue, depending on the information provided, my first response is usually along the lines of:
Hi,
Have you tried disabling ALL of your plugins to see if there is a conflict?
Also, please make sure you are running the latest version of WordPress and [Insert Theme/Plugin Name(s) Here].
Thank you!
Scott
At least 75% of the time the issue is usually fixed with these two questions. Either there is a conflict with another plugin which will need to be looked at or upgrading resolves the problem.
So my question is: Why aren’t we upgrading?
While we don’t have auto updates, like with Chrome, upgrading is super simple and literally takes one click. Most of us are well aware when there is an available upgrade for WordPress, themes and plugins, from the WordPress Dashboard. Even most themes/plugins, which aren’t hosted on the official WordPress.org repository, hook into WordPress’ upgrade notification area. Why don’t people upgrade?
- everything is working as it should and there is, or what seems to be, no reason to.
- there is the fear of something breaking.
Both of these are valid reasons, and I usually feel the same way, but I’d argue that you’d be better off finding out a problem with a new release rather than running into bigger issues down the road.
Most importantly, with an increasing security awareness in the WordPress community I would say stay up to date to make sure you are the safest from any security vulnerabilities which may have been patches in the latest versions.
Agree, disagree or have any additional info or feedback you’d like to share? Make sure to let me know below.
Hey Scott : )
Sadly, I think it has to do with two things:
1) People are scared. They just don’t know what will happen when they upgrade. They think they can’t handle what would be required if something went wrong, and they probably don’t realize how damn successful WordPress automatic updates are.
2) People are definitely hacking WordPress themes and probably hacking plugins too. They don’t know better. Themes need to be installed with a preconfigured child theme by default in my opinion to truly prevent themes from getting hacked. Plugins are probably trickier, and I’m not sure how you could prevent users getting their fingers in them other than a bunch of notices.
My two cents!
Thanks for the additional feedback Brian, worth way more than two cents!
I totally agree and while it is intimidating I’m hoping comfort can be found with proper backup solutions set in place.
I think as a community we need to continue providing best practices as best we can. Cutting corners by hacking core (sadly I’m still seeing this), not taking the additional few minutes to setup a child theme and modifying plugins instead of suggesting additional hooks from the developer will always lead to trouble.
Confession: sometimes I get fear when updating client sites. I don’t usually do ongoing management and support, so if they call me up a few months/years after the project ends to sort something out for them I log into their back end and in 95% of occasions they haven’t updated. I have to hit the update button, but I do think “shit – what if this breaks!”
When I think about the small businesses and non-profits that I’ve worked with, they tend to be the “set it and forget it” types. They think of a website as a whole, complete object when they should think of it as an evolving creature that requires maintenance. Even if the website itself doesn’t change, the world around it does so the website has to adapt. I do try to drill this in but often these are places with one person running the whole ship, and once they have a web presence they just forget about it.
I think the emergence of WordPress management and support agencies (like Mason’s WP Valet) will start to mitigate against this so long as people can be convinced of making the investment.
āshit ā what if this breaks!ā
In such cases I tend to do a full backup first, update, if all went well backup again, zip it, send to client, get kudos for going the extra mile. Clients tend to come back š
1) People are scared!
You’re right, but not just of technical issues. Look how often the admin UI changes.
Lets look at 2011, where the UI changed on Feb 23rd, July 4th and Dec 12th.
If you’re someone who’s job it is to use WP once every week then your UI changed once every (most small websites / news updates / classrooms etc) then the UI changed once every 14 times you used the software.
This was my number one complaint from friends/clients using the software last year.
2) Hacking.
Hacking is sometimes needed though. If you’re using bbPress for example its a must. Or if you need blog posts pre-1970 (a pre-req for all educational software in the EU). and 100s of other things. The mantra of don’t hack the core is directly opposite the idea of OSS.
My favourite one is that the core still needs (15 releases now ) to have any user you want to moderate comments given the capability to edit any content on the website. Every single one of our installs have a hacked core to get rid of this.
“Don’t hack the core” isn’t really contrary to OSS, as long as you’re not expecting the OSS people to support your future product.
I used to work on *NIX servers, and if you wanted to make tweaks to the system that survived upgrades, there were clearly-delineated things that were editable, and things that were definitely not. Ripping apart your sendmail config file was just fine, since it was a config file. But if you went into sendmail and rewrote large parts of the code, expecting your hacks to survive an upgrade would be silly.
Out of curiosity, have you tried to submit your core mods to the WP codebase?
Your post is very accurate, however the whole point may soon become moot, as the discussion of “silent upgrades” for future versions WordPress (Ć la Chrome) is slowly reaching critical mass.
I guess this would also help us to “enforce” the mantra of “don’t hack core”. Over the past year more and more jobs I took on involved rounding up work some other developer forgot or helping out someone who had less experience as a developer. In pretty much 50% of the cases WordPress core or plugins had been meddled with, breaking something after being updated.
Somehow this still seems a suitable solution for a lot of people out there. Maybe hash checks would prove valuable for these silent upgrades, to prevent breaking fucntionality. An opt-in would be the bare minimum, in my humble opinion.
We should set up wpoutlaws.com where we name and shame developers who hack the core š
+1
I doubt that will happen soon-ish.
I’m not sure how I feel about silent upgrades, unless there is some sort of option for turning them off. I think there are lots of reasons why it is a bad idea. Though I’ve not been following this discussion and didn’t realise it was even on the agenda.
I would *love* to see this. I know it’s been talked about a good bit, but I really look forward to its implementation.
Cool concept, but not likely to work in every scenario. This would have to be something that has an on/off switch I think.
For large WordPress implementations with a lot of dependencies and heavy load, a silent upgrade may be more dangerous than helpful :/
On there other hand, for people like me that have 2 visitors on their blog, this is highly welcomed š
Can’t wait for this either. Not looking forward to supporting it though š
I would only want that if optional or as a plugin. For a lot of site owners such a builtin system would be a big no-no (thinking of ISO servers, etc).
Silent (or rather automatic) upgrades are, in my view, not always the best idea. For example, every time a new major version arrives, i’s usually within a few days or weeks that the first .1 release is published, fixing significant issues. So I just stay with the safest version of the previous major release until the childhood diseases have been cured. Personally, I’d like to have a choice to upgrade, so I would favor being able to enable or disable automatic upgrades.
I get the fear every time. I shouldn’t as I think in all the cases I only once had a white screen of death ā that was pretty nasty though. Tip ā don’t do it last thing at night after a couple of glasses of wine.
I also have clients who are set it and forget it types. I like to host them on my own server and do maintenance for them and then I know things are being updated ā because I do it!
MKJ did a live update of WordPress Multsite during his talk at #wcuk (under much duress from the audience). It was a hair-raising moment!
Sadly the security risks here become higher with every version a user lets pass by. Like Scott said, as a community we need to continue providing best practices as best we can.
The newest version of WordPress doesn’t have a public vulnerability, at least not currently public, right? Without known vulnerabilities in the latest version, attackers concentrate on scanning for versions with known holes, it’s an easy win to infect and reinfect there. Go for the low hanging fruit, besides, there are tons of them. If your site is running the latest and greatest, you won’t put a smile on the attackers face, and $$$ in their pockets when they realize he/she can own you.
There are many attack types, but in my every day, the biggest target of entry point is through outdated software with known vulnerabilities.
End-users often don’t know that there is a better way than hacking core, or that if their plugin/theme was coded using best practices it likely won’t break upon updating WordPress…..
…It’s all of our responsibility to educate and follow suit. We need to be making folks better aware, or we’re just part of the problem.
I agree that it’s our responsibility to educate and follow suit, but I think that our reach is only so-far. After all, 16% of the web is using WordPress so there’s a whole jungle outside the WordPress community. There are WordPress users who are doing all sorts of crazy things that would probably make us cry at night (and doing it running on WordPress 2.8).
How do we educate these people? Plenty of them probably don’t even know who Matt Mullenweg is.
It’s a focused discussion here hence my emphasis on WordPress, the problem is indeed bigger than our beloved platform. That said, the responsibility is still the same, just at on a larger scale.
True team effort and a lot of patience. This is definitely not the same geeky audience who used to have a website back in the day. You know, the guy/gal with a bucket of caffeine sitting in the corner rocking out HTML with inline styles?
In the end, what people need to know is there’s a better way of doing things, not who Matt Mullenweg is. Besides, he only represents 16% š
Totally agree. It’d be nice to see something on the WordPress.org homepage. And maybe make the nag update more alarmist – something like “WordPress 3.5 is available. Please update now or your site will get hacked!!!!!!!”
Well… maybe less alarmist but something with a greater sense of urgency might encourage more people to click the button.
Can we educate users that often the thing they need to check most is their host? 99% of the hacks I’ve been seeing they did not get in via WP or any plugin/theme (that i know of).
They do need to know their $5/month shared host is not going to help much either.
I need better educated about that tbh š
Interesting, Andrea. You should contact me on that, I’d love to learn more. That’s definitely not in the majority of issues we see every day. In most cases they have 50 websites and all running old versions of TimThumb, or Joomla, WordPress, etc.
Although I do agree that cheap does not mean more secure, or better by any means!
This topic alone would make a great article. I’m happy to see WP specific hosting providers like Page.ly, WPEngine and ZippyKid come to the rescue as I can proudly recommend them to users.
The big question is, though, HOW do we educate them? I mean, how are we actually going to be in their face?
I know for a fact that for a lot of people the fear of breaking stuff when upgrading is a big one. Not surprisingly so btw. Back in the day you had Joomla (and even before that Mambo) and whenever you tried to upgrade that you were in for some serious pain. I suspect the past experience of such issues is what’s still bugging us in WordPress today.
There’s something to be said for WordPress.org to make it more clear that upgrading is a breeze (as well). Obviously if you have a bunch of shady plugins installed you still might be in for a surprise, but nonetheless, with a proper backup process in place reverting back and waiting for said plugins to update is relatively easy to do these days.
It’s not just shady plugins but also themes. What if you had a no longer supported child theme based on a trusted platform like Genesis. If Genesis were to deprecate certain functions being used by that child theme a silent update could severely mess up that website. Lots of situations where things could go awry.
Talking about backup processes in combination with silent updates. I think the backup/restore services like the ones WP Engine or Vaultpress offer could be something that would eventually ends up in core. Even in cases where the Dashboard would go completely FUBAR a backup could/should be reinstated through a backup system, which could even allow for a reinstallation (with preservation of data). Magento offers /downloader and a cleanup script that even in the most dire situation should get your store up and running again (if you have a decent hosting environment).
Quite right, yes.
I find it’s definitely fear most of the time. In odd cases, they didn’t know there was an upgrade, partly because of the “set it and forget it” kinds of sites. Some people I talk to have upgraded other plugins and something broke and they didn’t know how to get out of it. Often they don;t realize that there are *less* issues if they keep everything updated all the time. The biggest problems are when I see they done things like:
– updated the theme but not WP or the plugins
– updated WP but not the theme or plugins
– updated plugins but not the theme or WP
But i think the big thing here is education and assurances that when something breaks (it’s a when not an if) that these things *are* recoverable and they will not lose their content.
People do run businesses and update could lead to any form of incompatibility. In practice premium themes and plugins are large enough to include tons of code – which could lead to bugs during the update process. In addition to that, WordPress introduces some internal changes or deprecates functions and not every theme/plugin author is up-to-date with these changes. Adding the custom changes applied to plugins or themes due to client requests and voila – check out our newly updated buggy website, with no easy way to downgrade back to the stable release š
Not that it’s an excuse, but it’s a valid point though. One of my clients runs online training courses and is afraid to update as on his demo setup there are a lot of notices and warnings triggered after the update.
Training is the one I bang on about all the time.
Most clients have some form of documentation on how to use their CMS (WordPress), and that becomes out of date every time we make a release – even more-so when we change the UI.
Its a cost that we as geeks often forget about, but the software is about the end user, and I’m sorry to say they need training.
This becomes even more important once we start thinking about catering for “people with disabilities”. As I once asked Otto – how does a blind person see the changes to the UI?
Personally I am one of those people who decline to upgrade straight away but having read this I might be quicker. For me the reason was simple. I only install plugins that are compatible with the version I’m running and if I upgrade I see lots of plugins that get flagged as untested with my version. I’m always nervous about installing things that might cause problems down the road so I’ll go look for a tested alternative. By sticking with older versions I see more approved plugins.
I think there was a good point made earlier that you’ll probably get more issues by not upgrading but the truth is you get more warnings and notices if you update straight away. I suppose the lesson is that ‘not tested’ doesn’t always mean ‘it wont work’ and almost certainly doesn’t mean ‘there is no way back if this goes pear shaped’.
Be brave, upgrade. Everything’s gonna be okay.
I guess this raises another interesting question: What is worse: running a plugin that isn’t tested with your version of WordPress, or running an old version of WordPress? My money would be on the old version or WordPress – there’s a lot more scope for hackers scanning old versions of WordPress than old versions of individual plugins I would think.
Another thing I constantly see is WP_Debug set to display errors to the browser on a live site.
I think people are scared to death of PHP notices as well.
While this can be useful when developing it should be turned off once live and logged to a file.
You should follow Mike Little’s suggestion here and log these to a file:
http://codex.wordpress.org/Editing_wp-config.php#Configure_Error_Log
Things like core deprecated functions, other various warnings/notices, etc. will often show up and you shouldn’t be letting the world know.
Indeed. And, IMHO, developers should read up on DTAP: http://en.wikipedia.org/wiki/Development,_testing,_acceptance_and_production
Just thinking about DTAP (and version control) already helps to prevent such errors.
I have experienced the pain of upgrades going wrong twice in the past, both occasions were because the developer who I had taken over from had used the twentyelven theme as his starting point but not renamed it. Turns out it was the same developer on both occasions.
Fortunately I had backed up wp-content before I started.
“While we donāt have auto updates, like with Chrome, upgrading is super simple and literally takes one click. Most of us are well aware when there is an available upgrade for WordPress, themes and plugins, from the WordPress Dashboard. Even most themes/plugins, which arenāt hosted on the official WordPress.org repository, hook into WordPressā upgrade notification area. Why donāt people upgrade?”
Upgrading is super-simple, unless it’s not. This is because end-users don’t think like programmers, and they can’t be expected to. Work through this with me.
A failed upgrade doesn’t necessarily leave the site at the old version – sometimes it leaves it at a point where it’s completely unusable. If their IT person isn’t standing next to them when they do this, they probably wind up going to the support forums (frantic, because their site is *broken*) and are told to restore from backup, disable all of their plugins, and try again.
The problem with that advice is that even if they can do it (not all end-users know how to restore from a backup without help), and even if it works, it’s a complete non-solution for several reasons.
First, it’s a non-solution because logging into the wp-admin area is usually the first step of performing some sort of task. This is usually a massively inopportune time to do an upgrade, since there’s something else on the user’s plate already. And if that upgrade breaks, they might not have time to deal with the issue at that point.
Second, it’s a non-solution because asking a user to leave plugins disabled isn’t viable from a business point of view. Site owners use plugins because they need the functionality that plugins provide. If that functionality is a user’s favorite quote function, disabling it is an annoyance. But if it’s their entire e-commerce platform, they’re out of business.
Third, it’s a non-solution because their site used to work, and now it doesn’t. Whether this is because of a poorly-constructed WordPress release, a poorly-designed theme, or a poorly-written plugin is irrelevant, because a broken site *now* is worse than a site that might *potentially* be hacked some day.
Of course for many end-users, a broken site means calling an IT person and writing a check to make it work again.
Having that experience *once* is enough to make most users not want to do an upgrade *ever again*.
Other than that though, there are two major things we could do to make upgrades more likely:
1) Don’t rely on notifications in the wp-admin. The average end-user doesn’t go into the wp-admin section just to see what’s up – they go in there because they have a task to do. It’s like stopping you before you get in the car to go to work and telling you that you should fix your brakes before you leave – it’s a silly expectation. An email to the site owner explaining, in detail, why upgrades are necessary, and reminding them to schedule some time to do them would be a better option.
2) Yes, there’s a “one-click upgrade” option – but there’s no “one-click revert to previous version” button in case something breaks. I think that this feature alone would alleviate many users’ concerns with upgrading.
Automatic upgrades (without user intervention) aren’t the answer here. Better user education and a bit of a safety net for when things go wrong would be a much better use of the developers’ time.
Just my $0.02.
Great comment. I absolutely agree with all the points you bring up. My clients do not upgrade because they are either scared or busy doing other things.
I’d love to see a build-in backup solution (optional) that would let the user download a zipped backup of their current site before an upgrade. Something like:
“Before you update to the latest version of WordPress, would you like to download a backup of your site? This will allow you to roll back your site in case something goes wrong during the update process”
Then IF something would happen the user (or me) would be able to quickly re-install WordPress by selecting the zip backup during the famous 5 Minute Install;
optional: “Do you have a WordPress backup you’d like to deploy” (Browse)
Automatic upgrades have been extremely reliable for me so far, but a built in basic Backup solution would be a great safety net I think.
+1 +1 +1 +1 +1
Yes! And maybe an option to reinstall core, plugins and themes ( and maybe tagged/older versions of those? ). But all in an elegant way similar to what you’re describing.
I often don’t update plugins for security reasons. I security audit most plugins before running them on my site and I’m often worried that the developer will introduce some new “feature” which will introduce more problems than it fixes. This doesn’t bother me with respected developers, the likes of Mark Jaquith, Joost de Valk etc. aren’t people whose code I usually bother reading before upgrading, but randoms who I don’t know, I am much less trusting of.
One thing we in IT need to understand is that people DO NOT LIKE CHANGE. People like the idea of change, but not the cost of change.
To us geeks, who are used to updating software, the cost of change is low. The cost of change is not only measured in dollars, but in time, effort and confusion. While there is no doubt the WP UI is simple, the cost to the user for the constant Admin UI changes is very large indeed.
Like I said when we did WP3.3’s UAT on 60% Mac users, and 0% IE users – we are not the average user!
WordPress is a great example where the cost of change is both high and constant. We have taught people/users/clients/friends/parents that clicking the “upgrade now” button will invariably change the Admin UI without warning.
So, it’s not just a fear of something not working in a technical sense, its that something will change and the user wont know how it works anymore (WP3.3’s horribly inaccessible hover menu is a great example).
Moreover, we have to stop treating people with contemp if they aren’t convinced to do what we say simply by our rhetoric. If you want someone to upgrade their software we need to give them a carrot and stick argument; because the constant stick of “you’ll get hacked” does nothing but diminishes the opinion of the software in the eyes of the user.
Bluntly, we need to give people a good reason to upgrade from THEIR perspective, not from our perspective. Thats something we techies, and especially in the bubble that is WP, are really bad at doing.
This, right here.
I’m to the point where I start hosting arrangements by telling clients that WP is free of charge, but you do have to keep up on upgrades for the site to be secure and well-functioning. If you present it as a bit of a tradeoff to begin with, it doesn’t shock them as much down the road.
Of course being able to answer their questions when they have problems is a good idea too. š
Hi Robert,
For the most part though, that depends on the size of the client and how much legal restrictions are on them.
While everyone is happy to hear that something is Free (yay!), there is always a trade-off. Free is not always better.
If you’re in the EU, and especially in the UK / Holland / Germany, then the bundling of security, functionality and UI changes together comes with a great number of RISKS in line with accessibility/disability-discrimination laws.
The argument has to be Cost of Software vs. Cost of Upgrade. We can’t ignore the “Cost of Upgrade” or pretend that it’s free simply because the Cost of Software is $0.
Real World Example: Upgrading to 3.3 (and it’s lovely mouse-focussed menu) causes all sorts of issues for clients with staff who fall under PWD. One staff member in particular, could no longer use the admin area as they relied on a screen reader and keyboard; and thus by upgrading to 3.3 this person could no longer do her job. So the “Cost of Upgrading” was the RISK of being sued by this person for failing the disability discrimination act (not to mention *wrongful dismissal*) versus the RISK of being hacked if they stayed on 3.2
Thats where we start having issues. Once we move to larger clients, we run into more and more so called “edge cases”. Here in the UK, there are 2.6million who are PWD, which accounts for roughly 7% of the workforce. When 1 in 13 people can sue you for upgrading to WP3.3, the fact that it’s “Free Software” starts to matter very very little.
I see where you’re coming from here, definitely. Most of my clients are small businesses (many of them even single-person entities), and (thus far) I haven’t had any accessibility issues.
It would seem that the ideal solution here would be to un-bundle the security, functionality, and UI components, or (as an alternative option) to just offer security updates to old versions for some period of time.
Either that, or have a few disability testers working on WP. š
I agree. Upgrading ensures that bug fixes and security vulnerabilities will be fixed. As time goes on, the code can (should) only get better.
Silent updates give more control to developers than to users, which means software makers prefer automation eliminating choice; sadly they can give that control to bad actors who seize the implementation and insert their own preferred malware, as some Windows users found with the Flame code using Windows Updates — which caused Microsoft to silently update it’s own update mechanism as a cure… Then again, many regular updates to software forced by devs are regressions or dislikable.
There is nothing so good as being in control of your computer and the software you choose to run; and the same applies to your website. However, if an update borks something on your computer, such as a browser, it is recoverable because you can use a different browser: if a WordPress update borks your website — which seems to happen depressingly frequently — and a user gets an error page or a white screen, the site may or may not be recoverable. And a lot of people won’t be able to get it back. This presumably annoys them when they elected to update — how much worse if a silent update happened and when they next look at the site it is no longer there. With no explanation because they didn’t even know an update had occurred.
Again, silently updated browsers ( not that I would use one ) have limited scope in the numbers of operating systems they cater for: hosting set-ups and servers and plugins form a rich mix of variables for things to go awry.
The mistake devs and enthusiasts make is the liberal fallacy that assumes everyone must do as they want them to, because they know best: upgrading is not a moral issue. It is a choice.
I am not going to upgrade WordPress ever again because I will not have a rotten toolbar ( nor shall I use fly-out menus since they are vastly inconvenient ): toolbars are bad, bad things; they chose to give no options in these ‘upgrades’ and they have that right, just as I have the right to ignore them and live with the consequences — if any.
The important thing is that themes, cms, plugins can be updated in an automated way, silent or not (with the ability to disable silent updates, so the default should be on). Without that the user is less likely to upgrade. For sure there is a risk associated to upgrades and that’s why WP, for example, should have an easy rollback function integrated with it’s update mechanism.
There are certain plugins that are supported up to a certain version of wordpress and the new plugins updates do not work in a way that I like as much as the previous plugin version. There are certain plugins that I keep at previous version so stay with previous version of wp as well. Is this a valid reason? Do you think a plugin maker would keep supporting a previous version of its product so that users could upgrade wp when updates are available?