If you have logged into your WordPress and found an alert to update, then this article is one you might want to read.
You see, WordPress gets updated a lot. Sometimes the updates are small security fixes. However, once a year or so, there is a major update.
Before we continue, I want you to think about something. When you see that WordPress released an update, what do you do?
- Do you update right away?
- Do you wait?
- Do you ask your theme developer for compatibility?
- Do you look at your plugins for updates related to compatibility?
- Do you do something else?
The reason I ask is because with WordPress 3.5, there was a fairly major change in the core source code, that affected many WordPress theme and plugin developers. As the community guy for a company who develops WordPress photography themes, I can tell you first hand that the release of WordPress 3.5 drastically changed the daily activities of each employee for a few days.
Without going into too much nerdy details, WordPress changed some of the code that many themes and plugins relied on. So in turn, development had to be made (by many companies) to add a workaround. In addition to the development time for the workaround, we had to do a lot of internal testing on various environments, and then release an update to all of our users.
That short story is pretty much what sparked the question I stated above. So I went on Quora and Google Plus to ask communities the same question I just asked you. Here are some of the answers I received.
- Richard Saasta on Google Plus said he does a full backup using BackupBuddy. He then updates WordPress and verifies that everything is working correctly. If something goes awry, he then has a clean backup that can be reverted to.
- Tony Davis on Google Plus said that he keeps a separate domain with the exact theme and plugins of his other install. He will do an update in that test environment before making an update to the live site.
- Mickey Mellen on Quora said that he updates his plugins daily, and because most of his websites run the same plugins that he will update one of the smaller sites first, and once verified he will roll out updates to the rest.
At this point you might be wondering how I deal with WordPress updates on my own website. I did a lot of research on good web hosts, and in the end decided on going with a WordPress specific host, WP Engine. ?One of the big advantages of hosting with WP Engine is that they handle the WordPress core updates. (They won't touch your theme or plugins) Another big advantage is the built-in staging option. So whenever a WordPress update is imminent WP Engine sends an email to users with a time frame when all users will be updated. They instruct users to take advantage of the staging feature and to update a test site. The beauty of the staging site is that it is identical to your live site. Doing this can verify if a site will fail with a WordPress update, before going through with the update on the live site. Make sense? So my workflow is as follows:
- WordPress update released
- WP Engines emails a deadline before the site will automatically be updated
- I create a new staging environment
- I manually update the staging environment to the latest WordPress
- Test everything
- If something fails, I email WP Engine to say “please do not update me because XYZ”
Make better sense?
Now that I have gone through all of that, I want to ask you again. When you see that WordPress released an update, what do you do? Now that you've read the article, will you do something different?
Thanks for reading,
Scott Wyden Kivowitz is a NJ photographer and the Community & Blog Wrangler at Photocrati.?
Hi Scott, nice article.
Our take on this is to review the change log, and unless there is something to make our lives easier, it gets deferred for at least a couple of weeks.
Then everything gets tested on our test server. If all is well, then it gets rolled out to Production. Worst case scenario, Production Server can do an immediate restore via backup, to get to where we were before.
A security update to a theme or plugin gets priority and we’ll check it out as a priority item.
For the big, scary plugins with plenty of users, such as W3Cache – we go straight to the support forum to check other folks experience.
So, there is no hard and fast rule – and you get to learn which plugins are authored with extra care!
Interesting read. I normally wait and let the dust settle after a big update to WP and always make sure there is a back up in place that I can revert to should anything go too wrong when I finally update.
I used to do the Backup Buddy routine with an alternate URL –
apply updates to alternate site
wipe out production
create new database
migrate alternate to production
The migration timing was tricky – my prod site was down for the duration and once I got caught in a server error that took almost 2 days to sort out (yipe)
I made the WPEngine move as well and am happy I did. My only wish is that I could keep a duplicate site in the staging area for tests and updates and then copy the updated staging site back to production. The way WPE does staging I end up doing updates twice which is time consuming.
WPE has another feature that I love – you can create a snapshot of your site at any time and revert back to the older version quickly in minutes.
So for anything other than a major update what I do is:
Create a snapshot
Update the production site
Test – if all is OK – leave it – if not revert back to original and then use staging area to figure out what went wrong.
Now my updates are fast and safe.
Just like major service pack releases on OSes etc.we tend to wait for at least a few weeks to see what issues crop up. Of course, that being said, I always keep an eye out for security related updates which are always a priority.
We also tend to wait for all the major plugins to release updated versions with compatibility fixes.
We run a single multi-site install on our own servers hosting all our clients. Our code is fully version controlled with GIT, which means that even though it’s one multi-site setup, it’s possible for us to run each site independently from a slightly different code version during upgrades or patches.
Our procedure is to checkout a new code branch into a staging website that uses the same URL as whatever site I’ve chosen to test and host that on the SAME apache instance, but on a different IP address. I then use my local hosts file to access the staging site. This gives me the closest possible replication of a production site to test the upgraded code on.
The database is always the trickier part of all this, especially if it’s necessary to make some changes in the site setup to make it compatible with the new code version. The options here are to either put the site into a database read-only mode for the duration of testing and deployment (which is usually always possible) or create a SQL deployment script for the upgrade using Redgate MySql compare or manually by comparing (diff) database dumps.
On rare occasions, if the upgrade involves some kind of changes to the apache, mysql or general server setup, then we create a snapshot copy of our EC2 server instances to create a test environment that way.
In a nutshell, as much as I like the idea of what great companies like WPEngine offer, especially to people hosting one or two sites, it seems to me that for larger deployments they impose more limitations than they offer solutions compared to running your own server. Especially when you get into more complicated upgrade scenarios.
Of course this doesn’t take into account the server work required to keep that secure and fast, which is a whole other topic entirely.
I haven’t used WPengine myself, so I’d be curious to hear what do you guys think?