As many of you know, I run this site on WordPress. If you follow WordPress at all, you’re aware that a major release — WordPress 5.0 — was recently released with major changes including a completely re-thought editing system. There’s been a lot of worry and hand-wringing about upgrades and all of that.

I just wanted to pass along this data point: I’ve updated my site to WordPress 5, and absolutely nothing happened. Okay, not exactly true: page load speeds are way faster than WordPress 4 for me, both on the public site and in the admin area.

How to NOT run a WordPress site

Since I’ve been using and building stuff in WordPress for so long, I get calls from friends who need help, often of the “my god, Google is telling my I have malware on my site and I have no clue what to do!”

I’ve found in those cases one common theme: it’s not WordPress, actually, as some people complain. It’s people running WordPress without dealing with the necessary administrative aspects of running a site. They’ve typically downloaded a bunch of plug-ins, only a few of which they’re actively using, and haven’t been upgrading WordPress or the plug-ins as new releases come out. So when a security issue crops up, they don’t have the patches, and sooner or later, some miscreant finds their site, and that’s that.

Frankly, if you ignore the administrative piece — this is inevitable, and you can blame WordPress all you want, but it’s your fault for not running the site properly, not theirs.

(oh, and FWIW, my experience is that the vulnerability is almost never in WordPress, but in some random plug-in that was downloaded and abandoned and forgotten, so you can’t even blame WordPress’s code for being hacked)

How I run a WordPress site

So my first advice is simple: if you want to run a site, run the site. Don’t just install it and expect things to never break. If you don’t want to actually run the site, don’t host it yourself, put it on one of the services that will do most of the work for you — wordpress.com is a good option, as is Dreampress (which I use). They do most of the grunt admin work for you, saving you the time and hassle. All I really have to worry about is the design and plug-ins.

To simplify my life even further, I stick to a good quality premium theme where there’s a history of good support and updates. I currently use one from Elegant Themes and I’m really happy with their work. When I do my next redesign I expect to stick with it and just build out a new skin.

And… plug-ins. Can make your site really nice, and give you endless hell: my policy: as few as absolutely necessary, delete any plug-in that isn’t in active use, keep them updated religiously, replace any that hasn’t been updated in 6-8 months with some other tool, and well, try not to use plug-ins. The good news here is that as Jetpack has matured, I’ve come to trust it and it’s taken on functionality that used to be 6 or more independent plug-ins of god knows where it came from.

This site has 15 active plug-ins, which may seem like a lot, but five are part of WordPress core or Jetpack, one is from the Elegant Themes folks, and one from my hosting service (for cache management). Only one of the remaining has any visible UI component that might be open to hacker attack easily.

How I handled the 5.0 upgrade

A few notes on how I handled the 5.0 upgrade to make sure it was painless.

First, I used my other site (Silicon Valley Birding) as a guinea pig. It’s as close to generic WordPress as I could make it, including building based on a WordPress core theme. So I upgraded it to 5.0 early and watched — and nothing bad happened.

A month before the 5.0 release I started making sure all my plug-ins were kept updated, since all of the developers were busy stomping out bugs being found in the public betas leading up to release. Same with the Elegant Themes folks, I was getting theme updates as well.

Big hint on using themes in WordPress: child themes are your friend. When I designed my current site, I started with the elegant themes Extra theme, and immediately created a child theme based on it. I then built my design and customizations there. The reason for this is to separate my changes out from the main code of the theme, so that updates they make shouldn’t impact my customizations, and to avoid the pain and suffering that comes from having to merge their changes into my custom code. As long as they don’t make a theme change that breaks a piece of custom code, the updates should be painless.

TL;DR: the updates were painless. A bit of work upfront saves me more work later. This is another problem I see with sites I’m asked to fix: someone takes a theme and hacks it, then has no idea how to merge in updates from the original theme author — so they don’t. Even if it’s a security fix. Most people I know do that, never touch it, and then every few years throw it all out and start over with a fresh theme instead. That’s just an ongoing cycle of risk and pain.

So leading up to the 5.0 upgrade, I was upgrading religiously. Note that at no time did I use or run the 5.0 betas, just production systems and code. A week prior to the upgrade, I froze everything and let everyone else sort out the details when it released.

When 5.0 dropped, I upgraded Silicon Valley Birders, but not the main site. Nothing broke.

A week after release I started updating my plug-ins again, and then the theme. After about two weeks, the number of updates dropped off, WordPress hit 5.0.2 and then didn’t update for a few days, and once I saw that things were pretty quiet for a week, I pushed the button.

And nothing broke.

Which boils down to being a bit careful in the build, proactive in the planning, and a bit patient in the updating.. And a major release went down in a way that was in reality a big yawn. Which I loved…