Yeah, this happens. Sometimes you get an update from a WordPress plugin or a theme and this breaks everything. You meet with the dreaded White Screen of Death (WSOD) HEADS MUST ROLL!!! amiright?!
Well, not so fast. Here’s where Open Source takes as long as it will take you to drink… well maybe half a cup of coffee… to learn about and understand what’s going on under the hood, and why you shouldn’t be carrying out updates on mission critical websites during the middle of your trading hours.
In my regular day job, I work on eCommerce stores. This includes large eCommerce stores which do multiple millions in monthly revenue. This experience has taught me a lot of things, but in relation to updates, the lesson is this: if you care about your website or application, you do not update in production.
What does production mean? The website which is visible to the public, right now.
So how do we update?
Updating in Staging First
We use a “staging” copy of the website, which is an exact replica of the live site, visible only to admins. All good WordPress hosts will offer staging sites, usually with a one-click clone process, and some form of automatic “keep the public out of here” authentication thrown in.
Kinsta, WP Engine and Cloudways all offer staging environments. <- Please note these are affiliate links. I will be credited with a referral fee if you signup for these hosts – this does not affect the price you pay.
Once you’ve copied your site, login to staging, and make your updates. Test everything is working. Assuming it does, either push staging to production OR run the same updates in production. BEFORE you push to production, make a backup of the production site, in case things don’t work in production as they did in staging, also because this is a good idea.
Good hosts will also often automate the collection of a backup before pushing to production, too.
What if there is some error in staging?
Following this workflow, if you do find your staging site fails on update, you’ll remember what you just updated (your theme, or some plugin) and be able to report this to the developer of that theme or plugin. They’ll need more information from you to diagnose, but after a short period of time, they will be able to push an update resolving your issue.
You will be able to follow the process again, and successfully deploy the (now fixed) update.
The developer who helped you out will thank you for helping to debug a pesky issue. In addition, you didn’t need to pay anybody. If you are a developer (like me) maybe you’ll find and resolve the issue yourself, and contribute your fix back to the original developer – and all other users of the software. This is how Open Source works. People help to maintain a software, which means fixed costs are very low, and all you need to pay for is hosting your application.
Because you carried this out in staging first, you never impacted your production website, which was up the entire time.
There. That wasn’t so hard, now was it.
Never a white screen in sight, and all you had to pay for it was a few moments, and a couple of clicks. Plus, you may get the warm glow of contributing to something bigger than yourself, rather than to the coffers of some Nasdaq listed tech company.