Security Releases and the Sites That Wait for a Quiet Week

A release that cannot wait

WordPress 4.7.1 came out yesterday. It fixes eight security problems found in earlier versions, along with 62 ordinary bugs.

On a great many small business sites, updates wait for a quiet week. Someone means to log in, check everything and click update when things calm down.

For a new feature, that is reasonable. For a security release, the quiet week is the wrong schedule.

Once a fix is published, the problem it fixes is public too, and anyone looking for sites that have not updated knows exactly what to look for.

What updates itself

WordPress has installed minor releases on its own since version 3.7, released in 2013. A minor release is one where only the last number changes, such as 4.7 to 4.7.1.

So on most sites, 4.7.1 has already installed itself, or will within a day or so. WordPress checks for these releases twice a day, and emails the site's admin address when an update is done.

WordPress also publishes security fixes for several older versions, so a site still on an older major version usually receives them too, while staying on that version.

Major releases, such as the move from 4.6 to 4.7 last month, still wait for someone to click update.

What does not update itself

• Plugins, which add forms, galleries, sliders and shop features.
• Themes, which control the design and often contain code of their own.
• Plugins bundled inside a theme, which may not appear in the update list.
• Premium plugins whose licence has lapsed, which stop receiving updates.
• Sites with automatic updates switched off, by a developer or a host.

The third is where most owners get caught. A slider or page builder that came packaged with a premium theme often updates only when the theme does, and sometimes not even then.

Plugins carry much of the risk

Security problems in WordPress itself are found and fixed regularly, and the automatic updates deal with most of them.

Much of the trouble on small business sites comes from plugins and themes instead. There are tens of thousands of them, written by developers of every standard, and updated or abandoned at their own pace.

A fix for a plugin arrives as an update in the dashboard, on any day of the week. Nothing installs it unless someone clicks, or unless automatic plugin updates have been deliberately set up.

So a site can be fully current on WordPress itself and still be running a contact form plugin with a known hole in it.

Why sites wait

Updates wait for understandable reasons. An update once broke the site, and nobody wants to repeat the experience during a busy week.

Often nobody is clearly responsible. The developer finished the site years ago, the office assumes it looks after itself, and the update notices pile up in a dashboard nobody opens.

And sometimes the person who used to do it has left, taking the habit with them.

A worked example

A software consultancy with six developers builds custom systems for clinics and distributors. Its own marketing site runs on WordPress, set up a few years ago by an employee who has since left.

Updating the site was always for a quiet week, and the developers were always busy with client work. Everyone assumed WordPress kept itself current.

WordPress itself did. The emails confirming each automatic update went to the former employee's address, so nobody saw them, but the version number was right.

The plugins were another matter. The contact form plugin was more than a year behind, and the slider bundled with the theme had not changed since launch, though its maker had published a security fix.

The fix was not a project. One developer now owns the site, checks it on the first Monday of each month and within two days of any security release, and the admin email goes to a shared inbox.

Who checks, and when

Someone has to be named. Not the office in general, and not the developer unless they are paid to do it.

A monthly check covers routine plugin updates. Security releases, for WordPress or for a plugin the site uses, get a check within a few days, whatever else is happening.

Knowing when they happen is easy: the official WordPress news page announces each release, and the dashboard's Updates screen lists everything waiting.

Checking that it happened

Checking takes a few minutes. The dashboard's Updates screen shows the WordPress version and lists every plugin and theme with an update waiting.

If a site on 4.7 has not reached 4.7.1 by early next week, automatic updates are probably switched off or failing, and that needs looking into on its own.

After any update, test what matters: send a message through the contact form, put a small order through the shop if the site has one, and look at the home page on a phone.

Make updates safer to run

Much of the fear around updates comes from not being able to undo one. A recent backup, stored somewhere other than the server, removes most of that fear.

Remove plugins the site no longer uses. A deactivated plugin still sits on the server, and its files can still be reached.

For larger sites, a copy of the site for testing updates first, often called a staging site, is worth the setup. For small ones, a backup and a quick check afterwards are usually enough.

The counter-case

Not every update is urgent. A major release with new features can reasonably wait a few weeks, until its first maintenance release is out and plugin developers have caught up.

A very simple site, with few plugins and no forms, has less exposed and can be checked less often.

And a site looked after under a maintenance agreement may already be covered, though it is worth confirming what the agreement includes, and that someone is actually doing it.

Security releases are different. They go in within days, for WordPress and for every plugin the site runs.

Before the next release

1. Check the WordPress version on your dashboard.
2. Open the Updates screen and list what is waiting.
3. Take a backup before updating anything.
4. Update plugins with security fixes first.
5. Test the forms and key pages afterwards.
6. Remove plugins nobody uses.
7. Name the person who checks each month.

Step seven is what keeps this from being a one-off. Without a named person, the next security release will wait for a quiet week too.

That person also needs a login of their own, which is the subject of passwords from the developer's handover email.

Frequently asked questions

West Coast Media Solutions Inc. provides web design, web development, hosting, digital marketing, and business consulting to organisations across Canada, drawing on more than twenty-five years in the field.