Don’t Fear the Auto-Update – Stay on Top of WordPress
April 15, 2016
Recently I’ve noticed a new sort of FOMO in the online community, fear of missing out on breaking changes. Every time a new version of something is released, from iOS to WordPress, there’s a large chorus of ‘wait for the .1 release’ online. And I have to say that I understand the hesitance. Breaking changes and glitch interfaces are not fun, and neither is cleaning up a broken mess or trying to roll back a site. WordPress auto-updates are a huge cause of concern for many developers.
Take a look at some WordPress releases, though, and you’ll notice that the .1 and .2 releases aren’t just for fixing bugs, but for repairing security vulnerabilities that can usually predate the original .0 release. There’s only a certain amount of time we can spend riding out the storm, and I’d rather just set up my sites so that I can ride the edge of the wave, even if a little dangerously.
There’s a lot we can do to prepare for auto-updates because there is, fortunately, a set of standards in our community for how change is enacted. In fact WordPress is notoriously backwards compatible, even to a point of concern for some who’d like to see it moving faster into the future.
Let’s look at three of the root causes and solutions for fear of the auto-update.
Using low-quality marketplace themes.
Disclaimer: I’ve never used any of the popular theme marketplaces, so I’m not speaking from experience. However, I’ve heard a good deal of gruff in the community about the quality of most paid themes. It sounds like there’s a few standouts that are tried-and-true, but that a lot of what you get is unreliable and won’t offer much support when you need it. Often these themes are great for unique situations, but fail to have the resources to be quality tested for the various real world uses that push WordPress to the limits of functionality.
Solution: Build your own themes and child themes, or at least stick to the main paid contenders (Genesis, the default themes, etc). It may seem like more work, but the peace of mind in knowing that your clients can get all the auto-updates, specifically security updates, is worth the time. It’s definitely more work clearing out a bunch of PHP script injections after getting your site hacked. It’s definitely more work writing an ‘I’m sorry your site is down, I’m working on it’ email to multiple clients while trying to fix ten broken sites.
I recommend building your own personal parent theme for all clients so that you’re drawing from the same functions across the board. Familiarity with your theme’s inner-workings will make every update a little less scary.
Using low-quality plugins.
To be honest, most of our fear comes from plugins. We generally expect the core itself to be tested and proven stable by the time it is released, and if we’re writing our own themes or child themes, we have a firm grasp on how our sites will reach
Solution: Stick to the big guys and cannibalize the little ones. This may sound harsh, but so is letting a client site crash because you had twenty-five plugins running, ten of which were 50 lines of code or less. With the recent left-pad catastrophe in the node.js world, it feels like a good time to think about why open source code exists and how to use it most effectively.
For example, I feel confident that I can use a plugin like Yoast SEO even when they have some missteps along the way. I know that they’re a large business with a team dedicated to making sure their plugin is update and ready to respond quickly to any issues.
On the other hand, if I’m looking for an easy way to, say, make my embedded youtube videos responsive, do I really need to rely on a plugin that has less than 1,000 active downloads and maybe twenty lines of code? If it’s open source, what I should be doing is downloading it, opening it up in my code editor, and seeing how it works. Maybe I should do this with two or three plugins that offer this feature, then write my own function based on what I learn. Then I can have the peace of mind in knowing exactly what went into my site, plus I learned something new.
If we rely too heavily on open source code to do our job for us, we end up losing control over our work. There’s definitely a time and a place for relying entirely on open source code, for example, when using WordPress itself! But we should only be relying on code we know is still being maintained, something harder to keep an eye on in this current landscape of web technologies.
Not Knowing What’s on the Other Side of Update
Ultimately, our largest fear is the fear of the unknown. When the announcement of a new version hits our feeds, we might rush to see what projects finally made it through this time around. We see something like Responsive Images or Embeds and start to sweat. This is not good.
Solution: Pay attention to the release cycle. WordPress core development is a community effort. The core team are very transparent about what they do because they have to be. Every new feature is explored in depth and blogged about in detail. If you’re making our living on developing websites, you need to stay on top of the latest news, at least on a surface level.
Obviously the dev industry overall can be a little crazy, with new package managers, pre-processors, post-processors, and task runners popping up every day. It can get hard to filter through the ‘best weekly design news’ emails and articles and stay on top of what matters. But if we’re building WordPress sites for clients, WordPress core should be at the top of our reading list.
Everything from features to the promotional Introduction video is part of a community effort and is visible leading up to the release. Dedicate a small portion of your time to staying educated, much like you hope your doctor is skimming over the latest research from time to time, not treating you with science from his 1970s grad school program.
If necessary, install the beta version on a local test site that replicates a lot of the themes/plugins you use. Spend a little time preparing by
Of course some times are just too big to fail, which means you should have a local test version ready anyway. For everything else, updates will always be scary, but what is the alternative? Running your site or your client sites on outdated software? Imagine the potential consequences.