OK. Maybe I’m being a little dramatic, but I was inspired by my previous post on Google’s Mobilegeddon to write about WP Release Days.
Release Day’s are days when a new WordPress version becomes available. TODAY is WP Release Day. If you’re reading this post, most likely today is a release day, or a release day is coming up very soon.
In the past, WP Release Days would cause less drama, but since WordPress now installs with auto-updates out-of-the-box, many people are caught off guard when they log in and notice things are all different (or… GASP! broken!). It’s important to note though, that auto-updates only apply to security patches (as a rule), they are NOT applied to major point releases like 4.6, 4.7, or even 5.0.
Because I do WordPress support professionally, and moderate several heavily trafficked WordPress groups, I see a lot of the WP Release Day dramas played out live. It’s painful to hear about because often these folks are responsible for client sites, and their clients are the one’s suffering.
But what provokes this post is the blame that is always, inevitably placed. Without fail, every WP Release Day starts and ends with expletives thrown at “WordPress”. Here’s a laundry list of scapegoat statements:
Everything was fine before this release. WordPress shipped a bug!
The last thing I need right now is WordPress screwing up all my client sites!
They could at least give us a heads up before pushing these crappy updates on us!
MULLENWEEEEEEEEEG!!! AAAAAAAARRRRRRGGGGGHHHHH!
Varying forms of that is how we celebrate WP Release Day. It’s like Festivus. More or less.
All of these grievances are misguided and inaccurate. It really boils down to one simple thing.
If you are responsible for managing websites, either prepare for Release Days, or stop managing websites.
I hate to be so blunt, but it’s really the bottom line. Managing a website means exactly that: Manage it! If you aren’t prepared, then you can only blame yourself.
So let’s go one-by-one to explain why there’s one finger pointed at WordPress and four pointing right back at you (cheesy, but it works).
I can’t prepare for new releases because I never know when they’re coming
There’s LOTS of ways to know when releases are coming. Here’s just a few:
WordPress.org frickin’ Blogs about it
Here’s the link: https://make.wordpress.org/core/
It’s that simple, subscribe and pay attention.
Core commiters throw a frickin’ party in Slack
Join Slack, and pay attention. Here’s how to join Slack.
Here’s a preview of the party they threw today. Look at all the fun emoji’s!
Watch new releases progress in Trac
Trac is where all issues and new features of WordPress are “tracked” and discussed in detail. I’ll admit, this is by far the most difficult and geekiest way to see when updates are coming, but it’s effective and educational. But here’s a few resources to give you a head-start:
- Tom Ewer’s post on Embracing WordPress Trac
- Lamosty.com’s piece on using Trac
- A fun personal story of working with Trac
So really, there’s no excuse. You can be fully informed of when new releases are coming, and if you manage even one WordPress site yourself, then you are responsible to be informed.
OK Fine. I know when it’s coming, but I can’t prepare because the new version isn’t available for me to test.
You absolutely can test in advance. Here’s several ways to do that:
- The WordPress Beta Tester plugin allows you to update any WordPress site with the latest development version of WordPress.
- WordPress Core is synced with a Github Repo.
Ya, but I can’t run that Beta plugin on my clients sites! You’re crazy!
Whoah, whoah, whoah, whoah.. WHOAH!
No one said anything about testing releases on live sites. If you are responsible for managing your clients sites, you better be developing them locally or at minimum with a live staging or development site. Here’s some resources on that.
- How to Use Desktop Server — this is a really easy tool to develop all your sites locally, and even deploy them live with your changes.
- How to use Local by Flywheel — this is a great tool for developers, freelancers, agencies, particularly when you want to test against different versions of PHP or MySQL or support local SSL certificates.
- Installing VVV — this is another local development tool. A bit more robust than Desktop Server. Great for emulating live environments.
- The WordPress Developer Intro to Docker — Some Devs swear by Docker. This is a good intro to it.
- Can’t decide between VVV or Docker? You’re not alone. Delicious Brains breaks it down for you.
If you’ve never done local development before, yesterday is as good a time as any.
But I need more time. I can’t plan my life around when updates are going to be pushed to my sites
First off, yes there is such a thing as “auto-updates”, but that’s not what we’re talking about here. Those are security only updates and are REALLY good for you — it’s basically free code.
For major point releases (4.8, 4.9, 5.0, etc), those are never auto-updated, so you can run that update whenever you like. Test it somewhere safe, and don’t ever feel pressured to force an update if you’re not ready.
Particularly if you’re a small eCommerce site or NGO running donations — don’t risk your big campaigns on WordPress updates. Wait and do them safely on YOUR schedule.
Regarding auto-updates, if that whole idea just makes you feel insecure you can disable them with one line of code:
define( 'WP_AUTO_UPDATE_CORE', false );
Put that in your wp-config.php and smoke it. Done. Now you can sit on your old WP Core versions as long as you like, just don’t blame me when your clients are like “Why does it say I need to update WordPress?”
OK. But listen, every time WordPress updates it breaks something. It’s terrible!
Now we’re venturing into the ever so slightly more understandable complaints. I totally get how it might seem to be that way. But let me ask you this:
Q: What’s worse than a website manager who doesn’t prepare for a new WordPress release?
A: A plugin or theme author who doesn’t prepare for a WordPress release.
“WordPress” is not breaking your sites. WordPress is just fine, and most likely it’s even more stable, a bit quicker, a bit more secure. That’s what iterative development does to code. The problem is that you hit “Update” with all your outdated plugins activated.
So here’s a quick run-down of how to update without breaking your sites:
- Backup your sites, including databases.
- Deactivate all your plugins. All of them. Say Bye-bye Dolly.
- Then update all your plugins, and all your themes. You might see some Translations get updated too (Props to the GlotPress community!)
- Now update Core. You should be TOTALLY fine.
- Now activate each plugin one at a time. No Bulk options here. One at a time.
- If you hit a problem, now you know EXACTLY which plugin author to come charging after for breaking stuff, and you know exactly how to get your site working fine again… keep that plugin OFF.
Alright… I’m feeling a little schooled now, but the truth is I manage a ton of sites and what you described is a ton of time. I hate having to do this all the time.
Ya. I get that. That makes sense. But again, this is your JOB. You asked to manage all these sites. If you aren’t getting paid enough to spend this time, then go work on that before you hit “Update.”
But honestly, the best way to deal with that is to use one of the really awesome services that do all of that for you. Here’s a few:
All of these services tackle this problem from different angles, and each excel in different ways. Do some research just by googling “InfiniteWP vs ManageWP” and there’s tons of very opinionated articles about each of these.
BONUS: If you want more of a set-it-and-forget-it setup, where you pay someone else to do all this dirty-work for you and your clients, then definitely hit up the folks at WPSiteCare.com They do all of this for you for a fee.
OK. You’re Right. I’m out of excuses.
I know. That’s why I wrote this. Thanks for reading. Go ye, and update WordPress fearlessly!
One thing to note is that auto-updates are only for minor versions by default. Minor versions are often also security releases. There are some hosts that do auto-updates for major versions, but at this time, that is not a core decision. Putting
define( 'WP_AUTO_UPDATE_CORE', false );in your wp-config will disable auto-updates for minor and security releases which means you will need to manually keep your site updated when a security release comes out.Thanks for the clarification Aaron. Good point!
Hi,
If I understand correctly you have to copy your sites to local every time you want to update? I have a client site that hasn’t been updated in ages and he recently asked me to take care of it. I’m not super experienced in fixing broken sites so I’m pretty scared that something will “break”…I certainly do not want to do the updates on the live site.
I would say rather, if you are managing a client site, you should have a local and dev/testing site where you can test updates before going live. That way you don’t have to copy to local first.
Just wanted to apologise for commenting on this with the wrong account…
Hi Luisa,
Like psykro said, local is best for testing, then you can push to a live staging to confirm everything looks the same in a live environment, then that pushes to Production. That’s standard practice for professional devs.
But I know from my own experience that it takes a long time to learn those skills and get those tools configured and do it in a way that is safe and doesn’t take gobs of time.
So for this one client, here’s what I’d recommend:
1) Install the Duplicator plugin on your live site : https://wordpress.org/plugins/duplicator This will allow you to export an “Archive” or ZIP file of the whole site including the database.
2) Buy DesktopServer. Choose the Import tool, and Import that site from the ZIP file. Duplicator and DesktopServer work really well together.
3) Do all your updates locally. If there’s errors, you’ll find them here and can report to your client about the work involved in getting everything up and running with the latest.
4) Once you and your client agree to terms on the time spent on updating, do the work locally and use DesktopServer to push it live.
Once you have that in place, get in a habit of doing ALL your updates locally first, that way the local copy is always in parity with the live. From then on it gets easier.
Thanks and good luck!
Thank you so much!
Well played Matt. Well played.
Two thoughts to add:
1) I think it would be helpful to touch upon how to have this conversation with clients. I mean, what do you say to (a client saying), “…what do to mean WP auto-updated and broke a plugin?? I don’t give a $#%^ I didn’t ask you to update it. Fix it. NOW!! And I ain’t paying for it.”
I’m sure you’d agree, not every client is willing (or able) to pay a monthly maintenance / retainer fee. In fact, it would be interesting to study / know how many actually do vs how many take the “pay as you go” route. I could be wrong but I’m willing to bet it favors the latter. Needless to say, the small fish often have the biggest mouths.
In either case, broken sites upset clients. And preventing that, as you show above, takes time and effort. Time === money, right :)
2) Instead of gazillions of WP devs and “lay people” (i.e., those not interested in Slack, reading the core’s blog, etc.) chasing the same WP tale/tail , wouldn’t it make a lot of (#@$%^!) sense if there was a simple email list to sign-up for and/or a FB group and/or a Twitter accnt that did nothing but broadcast this schedule. NOT the day to day minutiae (e.g., following core) but simply “3 days to Pepper…” and then “2 day to Pepper…” and so on. Less noise. More quality. I think you get the point (of reducing so much duplicate effort.)
Matt – You’d like to discuss #2, please send me an email. Perhaps it’s something – with some help – I can add to the WPezDeveloper umbrella?
Per your first point, the way you have this conversation with clients is to explain before you even start a project for them that a website is software, and as such, needs to be updated frequently for security purposes and at any time that a major software release comes out for the platform it’s being built on. Then explain that you offer maintenance plans to mitigate the risk of running out-of-date software on their website, explain the pricing, and explain that they are assuming full responsibility for the maintenance and upkeep of their site without a maintenance plan and that your company charges x-times normal rates to fix a site that breaks or is hacked because it wasn’t on a maintenance plan. Set the stage WELL in advance and these conversations don’t have to be difficult :)
Hey Mark.
1) Check out our WP-Rollback plugin which will allow you to very easily revert plugins back to their functioning versions. Then bug the hell out of the plugin developer until they get it working with the latest Core version.
Generally, I suggest don’t manage a website unless you’re getting paid for it. Clients who don’t understand that or treat you that way should get fired.
2) Love that idea. But it’s not so straight-forward. An actual date typically isn’t published until Release Candidate 2. And it’s published in a blog post, so doing this programmatically would be challenging.
Here’s what I think your tool *could* do. You could monitor progress of Core based on Trac programmatically and show “Version 4.7 is currently in Milestone 1”, then Milestone 2… etc. Then it gets to Beta Version 1, 2, 3, 4, etc. But then when it gets to Release Candidate 1 add a message that says “Time to start testing with Version 4.7!”
Thanks for reading and your feedback!
Actually, there is a schedule like this. You can read about it here https://make.wordpress.org/core/4-7/
This schedule is always subject to different changes but at least we know there is one.
I love this. I love everything about this. Great write-up.
I wonder if it might be useful to improve the messaging on the update screen to suggest deactivating all plugins prior to update. This tip alone is something I don’t think a lot of users really think about before updating and as you’ve stressed, is likely the easiest way to discover (and target) problem plugins without getting blindsided.
That’s a good point. The default notification is pretty small and just says “Backup your Database, and read this article”:
https://codex.wordpress.org/Updating_WordPress
Destin Meza of WPEngine did a presentation at a couple different WordCamps on this subject. We did a write-up on it at WordImpress:
https://wordimpress.com/afraid-wordpress-updates/
Your suggestion reminds me of the popup we use in WP-Rollback which really makes it clear:
https://github.com/WordImpress/WP-Rollback/wiki/Rolling-Back-Plugins
I think it’s worth discussing ways to improve the user experience of the Core update process for sure. Thinking of it as preventative support rather than reactive support. Thanks for chiming in!
Mika Epstein brought up a good (very unfortunate) point with this approach, and that is that there is a disappointingly high number of plugins that straight up delete options on deactivation (wut). I think that qualifies as developer error, but would no doubt come back on core as “WordPress’ fault”. Sigh.
Hot damn, where’s the like button for this comment…
Much of maintaining and upgrading WordPress “the right way” depends on having the foresight to include a support plan from the outset of the project. The regret of omitting support is a growing pain that I suspect is all too common, and articles like this will hopefully save others in the future.
The reality is maintenance/upgrades require tedious work, and it’s even more tempting to take shortcuts when you’re not being paid for your time. You need to either take responsibility for it upfront or make the client aware of whom it’s being offloaded to in advance. There will be conflicts, and someone will be called. If you don’t designate who, then it’s you by default.
Agreed! Thanks for reading Kevin!
Great post. If you’re creating value for a client, as in supporting the site, doing updates, etc., you should be compensated for it.
If you’re not providing support on a “best effort” basis, then shame on you. There will be combinations of WP, a given theme, and a given set of plug-ins, that simply will not work together…perhaps ever.
Setting client expectations is critical; just like being prepared.
Very true. Thanks for reading and your input.
With all the conversation above it feels like I am the least experienced person here. Let me share what I do in case of any upgradation – may it be WordPress itself / theme in use / plugins in use / new plugins to install. I always use WP-Staging plugin (https://wordpress.org/plugins/wp-staging/) and first make the upgradation in the staging site. When everything works out ok, I make the changes to the actual site – uses a little extra time but saves a lot of frustration over broken site, threatening words from clients and finally I get a good night sleep.
That sounds very responsible. Do what works, just do your job. That’s exactly what you’re doing! Nice!
Thanks Matt :-)
Bookmarked and sent to some of my clients. They understandably wonder why they should pay for maintaining free software. This article should answer most of their questions. Thanks!
Glad to hear. Thanks for reading!
Incredible post. Love everything about it. On point.
Thanks Ahmad!
Matt
Great post ! I never thought of turning off all plugins first. I’m definitely going to teach that to my students. :)
I always update in two passes
first plugins and themes, then WP.
I also love that you stress for people to take responsibility for their own sites. Often people complain and don’t realize how good they have it with free WordPress.
Christina
Thanks Christina!
We build websites for a living, like many others in this discussion.
Our philosophy has been different from the very start. We work hard to avoid problems as opposed to figuring out how to fix them later on.
After many years in the business using several different platforms we standardized on only developing client sites using the Genesis framework and (obviously) themes that work with it.
These days many themes contain built-in functionality (i.e. Elegant Themes.) We believe in the semi-strict separation of “view” from “function.” Thus we use themes that concern themselves with appearance and we use plugins for functionality (i.e. a portfolio.)
Second, we don’t use plugins for simple things… we prefer to just add the code ourselves (we have ‘deep’ technical / PHP abilities and an in-house library of routines.) We especially stay away from complex page-builder plugins.
More important than the framework and the theme is our philosophy of using as few plugins as possible and we would never use an “aggregator” plugin like Jetpack. We vet the plugins we use very carefully by looking at the code and seeing if the developer followed the “rules” set by WP codex. If we can follow the code then we feel safe that if there is a break that either we can fix it and/or explain to the developer what and where the issue is.
OK, maybe our sites don’t have all the whiz-bang eye-candy that others have, but they are solid out of the box, stable, maintainable, and they don’t break in the future. And for that, we charge ‘extra’ in that we are not the cheapest design house on the street. We tell clients that it is harder but better and cheaper in the long run to build it right instead of throwing a bunch of ‘unknown’ plugins into the mix and hoping for the best when WP updates come around. That is part of the value we sell.
We tend to build Volvos and Ford pickups, not Ferraris and Aston Martins!
That’s definitely a very reliable strategy to mitigate potential upgrade issues. In my experience there’s no amount of vetting that can protect you from an update that just doesn’t play well with other plugins in your environment, so staging/local is always best.
Thanks for reading and for you input!
We don’t design sites but we host them and manage them for clients who would not be able to do it themselves. We also rescue clients from situations where they have been hacked or made vulnerable from hosting/update failures.
As we use our own infrastructure and run servers in KVMs, we find it best to create a restore of a current server image complete with WP installs DBs etc and then apply the update(s).
This way we can hack about on a known and working base and find the problems across the whole platform eg Apache, Nginx, PHP requirements, OS changes and WP core.
We also keep the plugins and themes up to date in a similar way. It has the benefit of showing you the whole process and the resulting improvements or bugs before you present your clients with a headache.
Whether or not you use VMs or have the capacity online, it is also a great way to check your general backups and recovery processes work properly before you need it in anger!
That’s definitely a great strategy as well. Very reliable and makes sense for larger agencies for sure. The majority of the WordPressers and site owners I interact with don’t have the resources or knowledge to do a setup like that. The bottom line though is simply to understand where your responsibility starts and where WordPress Core stops and be responsible rather than just blaming the code which thousands of people all over the globe have contributed to. Thanks for reading and for your input!
I offer a service for my clients that includes WordPress Core and Plugin updates, most of whom are sole proprietors/professional bloggers. I don’t offer hosting, and I’m not the original developer for these clients (most either use an off-the-shelf theme and figure it out themselves, or hired a developer/designer for an initial design, but have since parted ways).
Because of my price point, and the variety of hosting accounts my clients use, it’s simply impossible for me to maintain development servers for everyone. Even deactivating all plugins and reactivating one-at-a-time would be too time-consuming…and would likely introduce much greater downtime/maintenance windows.
As such, my update strategy is:
1. Backup.
2. Wait a day or two after updates are released before actually updating (unless it’s patching a security vulnerability). Wait a few days for major version changes.
3. Update plugins manually, one a time. Check functionality after each.
4. Update all plugins before updating core.
5. Fix any problems after-the-fact, or roll back if I can’t find the solution quickly.
With this strategy, the amount of time I have to spend fixing issues is far less than if I were to have a dev site for each, or to follow the “deactivate all, update, reactivate one-at-a-time” strategy, so I’m able to charge my clients a more affordable price.
With regards to WP Site Care — I’d be willing to bet they don’t follow the deactivate-update-reactivate strategy either… and I’d be surprised if they’re not using scripts to update plugins, rather than having a real human run the updates.
Sounds like a solid strategy. While I don’t know the intimate details of how WP Site Care manages updates, I know them and their reputation and they’re solid. But I know plenty other developers like yourself who offer these services and the personal touch is something some business owners really highly value, so I think there’s always room for both. Thanks!
MULLENWEEEEEEEEEG!!! AAAAAAAARRRRRRGGGGGHHHHH!
Too funny
Thanks for stopping by Corey!