I’m delving into angry-land here, so hold on to your hat.
So. You upgraded to WordPress to a major release without testing it first, and broke your site? It’s probably your own fault. Bring on the stones and when you’re done, let’s talk.
Ready to talk? Okay, you didn’t test. That’s why it’s at least partly your fault. This triples if the next words out of your mouth are “And my WordPress site is my life!” It quadruples if you say “My client sites broke!” It’s infinite if you broke your company site and you happen to be a WordPress based company.
But notice how I said probably? I can honestly say that 50% of the time my site breaks, it’s WordPress, not me, but I happen to run trunk without testing, which makes it my fault, not theirs. Seriously. I’m running trunk on a live site, which updates twice a day. I’m a little reckless. My life is WordPress, which makes me in violation of one of my own cardinal rules, but at the same time, the part of WordPress that is my life is supporting it, or breaking it and reporting it. For me, a broken WordPress install is one that needs my love to fix it, and I embrace that role.
You’re not me. And in fact, neither is my dad or my friends’ sites that I host. For them, I have a couple options: Let them upgrade themselves, upgrade them automatically, upgrade them myself. I use all of those methods, in different situations and with each of those, what happens when they break? I will say this, for everyone but me, if I have a contract to manage their updates, I test the update first. To the fellow who complained he had 200+ sites to test, I say “Well, that’s your job.” You agreed to manage them, you better do it right.
Telling people “Your site broke because you didn’t test.” isn’t an answer, though. It doesn’t explain why the site broke. The answer to that is a little more simple. “You have code that doesn’t work with the upgrade.”
And yes, it’s really that simple. You have a plugin, or a theme, or an add-on to your server, that doesn’t like the newest version of WordPress. Now, it’s a struggle to fix one’s site at the same time as placating one’s customers/clients/visitors, because you’re in a race against time. This is why you have to do that usual testing with plugins off and so on. Complain all you want, there’s no way around it. Point out you’re not a coder all you want, that’s actually why this happened to you and not me.
What do I mean? Well I am a coder, so when I install a new plugin I review it first by looking at all the code. You’re not a coder, I hear, but you can still review the plugin by looking at the updates, the author, their contributions to WordPress, the support forums, and the size of the plugin. The larger a plugin, after all, the more chances to go wrong. I also like to check /wp-admin/credits.php and look for the author. If they’re there, the odds of them not knowing that there was a change in WordPress that impacts their code is pretty negligable.
And this is how it works. It’s the addition of all things, combined to make a good, educated, guess as to the relative safety of your site. Good plugins that you’ve checked on, good themes ditto. Sure everyone can make a mistake, but good code makes fewer, good coders adapt well, and responsive coders react well. That’s the biggest thing. People will make a mistake and break your site, but if you use a theme were the developer is on the spot with patches and generally responds quickly (say, within 5 days), then you can be pretty sure that this developer knows when WordPress is releasing a new build, and that they should test Betas and RCs. That’s what you’re looking for.
This is especially important if your site breaks on a MINOR upgrade. If your site broke going from 3.8.2 to 3.8.3, and you find out it’s a theme, stop using that theme. That’s really hard, I know. But it’s really serious. A theme or plugin that breaks on the minor updates is doing something really wrong, or is taking advantage of a vulnerability which makes it dangerous to use. That’s it. That’s the reality. Either code is really bad or it’s really unsafe.
Neither of those things means the developer is a bad person. It just means they did bad code. We have all done bad code. We have all been the cause for bad and dangerous code, and we will all be so again. But again, it’s how we respond that makes us heroes or not.
Look for the heroes. They stand out. Use their code.
Comments
8 responses to “So Your WordPress Upgrade Broke”
None of the companies I work for/have worked for do it this way, but my attitude is that you are better off upgrading as often as possible and as quickly as possible. If something breaks, you’ll find out pretty soon and just need to fix it as quickly as you can. If things are breaking all the time, then you have a problem, but I’m guessing things only break every few years and it’s usually something which isn’t critical to the site anyway. The exception is if you are running really munted code, in which case that is a separate issue IMO. Good code shouldn’t break, usually.
@Ryan Hellyer: Also, I’m lazy, and it takes less effort to fix things which broke than it does to test everything all the time 🙂
@Ryan Hellyer: I feel that the further from ‘current’ you get, the harder the upgrade process becomes. Though I’m surprised to find that you never worked for a company that tested before the upgrade. Even running trunk is ‘testing’ in advance in my opinion. You know what’s coming, what’s changing, and how to adapt to it.
@Ipstenu (Mika Epstein): No no, ALL of the companies I’ve worked for test before upgrading. I was saying they don’t do it the way I do … ie: seat of your pants and hope for the best 🙂
@Ryan Hellyer: Oh that’s good! whew Well … not GOOD… 🙄
I’m a little post-fact-debuggo myself, but thats for me personally. I have three other sites I never test on.
@<a href="#comment-5@Ipstenu (Mika Epstein): 3380″>Ipstenu (Mika Epstein): You say “whew”, but I would not consider it a bad thing if all of my employers (current and present) simply upgraded and hoped for the best. If you are confident in your WordPress chops, then you are likely confident that the site will stand up to an upgrade.
(none of this applies if you are using plugins you don’t trust of course)
@Ryan Hellyer: It depends on the risk vs reward calculations. I test first on places where ANY unplanned downtime is critical. If there will be a loss of business, I test.
I’m confident in my chops and I only use plugins I trust and vet, but there are places I will still test first for WP.
Having done support I can definitely appreciate this. Would get questions with every major update if the theme works with x.x?
Most of the time it did but. Always cautioned people to do a backup first. At one point I managed a lot of sites and I had an update policy. Unless there was a security issue I didn’t update till x.x.x because that gave theme and plugin developers plenty of time to do any updates and if there was a problem it would be fixed.
I also run bleeding edge on a test sever and keep most plugins I use on that site to test how they work against code being developed.
In my opinion, if you are getting paid to manage sites you should have a dev setup where you are testing bleeding edge so you know what to expect with any given update. That makes you look like a rockstar to your clients because you can tell them about new benefits from the update before it is gold.