Update 8/22/2017: Looks like the appearance editor is in the process of getting a makeover – finally! My post below still has some accuracy, but I’m glad to see some of the issues being resolved to make code editing easier.
Okay, okay, before you roll your eyes and abandon this post, I just wanted to share something. It occurred to me on my morning commute as I was handwriting new content aimed for beginners. I had to get myself in a mindset of what it was like diving into WordPress files for the first time again. Re-calling a greener Rachel lost in a labyrinth of files, desperate to complete the small task of changing a font color and not knowing where anything was – I realized that during this learning process, there was one adversary I encountered time and time again.
Said adversary stalled my progress in learning. In fact, it scared the heck out of me a few times whenever it caused the white screen of death before I even knew it was called that.
This adversary is the appearance editor on the dashboard. Thinking back on what I knew back then ( and didn’t know ), having this tool in my hands at the time only served to confuse me, discourage me, or give me impressions of WordPress that weren’t correct.
Here’s why I feel that way and why this tool should be approached with caution.
I’m sure my previous post might’ve been useful for those familiar with the WordPress directories and their innards, but what about those who aren’t? Browser cache? Config file? Browser console? What is all this dev lingo and how does any of this help the average joe with troubleshooting WordPress?
And so, I’m recycling some pieces from my last post so I can go over general steps for troubleshooting WordPress again in more depth. No geek speak, no dev lingo, just learning how to troubleshoot like a true marksman! Hopefully by the time we’re done, you’ll come out of this post feeling less like a blind troubleshooter and more like a sniper who hits the mark every time. Let’s get started…
I recently got into an interesting debate with one of my LinkedIn connections about whether or not we should keep WordPress sites up to date. Good points were made, disagreements were expressed, and in the end, I think we left it as:
“It’s up to the developer to decide what updates are right for the client’s site and understand the risks associated should they choose not to update.
So long as the developer is not only aware of those risks, but can take responsibility for the consequences should there ever be any, and they make the client aware of the risks as well – then to each their own.”
Although we didn’t totally agree in the end, having this discussion with John ( Let’s pretend his name is John ) really got my thinking gears turning. John had one very good point. What about sites that haven’t been updated for several years and are still somehow functioning? Updating a site like that would surely unleash all manner of hell!
So I thought, hey, I should write about that, how to update WordPress without chaos ensuing! And it gives me an excuse to use a witty title – hurray!
Anyway, in cases like John’s, or just in general, what steps should be taken to ensure that as little hell as possible happens? How do you know how much or how little preparation you should be making? And if heaven forbid, bad things happen after your update, how do these steps help to either resolve the problem or revert the site?
And as an added bonus, if all hell breaks loose after a WordPress update, how can we troubleshoot and survive the catastrophe?! Gear up and let’s get started!