WordPress 4.0.1 and the Sites That Did Not Update

A release most sites received overnight

WordPress 4.0.1 came out yesterday, a critical security release for all earlier versions, and the WordPress team urged every site owner to update at once.

Most sites needed nobody to do anything. Those that support automatic background updates were due to receive it within hours, and many updated before their owners heard the news.

The question this morning is whether yours was among them. Some small business sites were not, and the reasons say a lot about who is looking after them.

What the release fixes

The most serious flaw affects versions 3.9.2 and earlier: a specially written comment could let someone with no account on the site compromise it.

Version 4.0 was not affected by that one, but 4.0.1 fixes several other security problems in it, along with a list of ordinary bugs.

Sites still on 3.7, 3.8 or 3.9 are not moved to 4.0.1 automatically. They receive a patched release in their own line instead: 3.7.5, 3.8.5 or 3.9.3.

Checking that it updated

• The dashboard: the At a Glance box and the footer of the admin screens show the version.
• The Updates screen: it says the site is up to date, or offers the update.
• The admin email: WordPress emails the site's admin address after an automatic update, or when one fails.
• The page source: many sites still carry a line naming the WordPress version.
• Your developer or host, when no one in the office has a login.

The number to look for is 4.0.1, or 3.9.3, 3.8.5 or 3.7.5 on the older lines. Anything lower means the update has not happened.

A business that cannot log in to its own site has found something already: it has no way to check, and no way to act on the answer.

Sites too old to update themselves

Automatic background updates arrived with WordPress 3.7, a little over a year ago. A site on an earlier version has never received a security release on its own.

Those sites are also the most exposed, since the critical flaw reaches every version up to 3.9.2. Each month untouched leaves them further behind.

Sites set up so they cannot

Newer sites can miss out too. A developer may have switched automatic updates off in the configuration file, on purpose or years ago for reasons nobody remembers.

Some servers refuse to let WordPress change its own files, so it asks for file transfer login details at every update. It then cannot update unattended, and waits for someone to log in.

Sites kept under version control, a system developers use to track code changes, are skipped on purpose, on the assumption that whoever manages the code will update it.

And the automatic update runs through WordPress's scheduled tasks, which start when someone visits. A site with that scheduler switched off and nothing in its place never runs it.

Switched off on purpose

Turning automatic updates off is not wrong in itself. Some developers test every update on a copy of the site, then apply it by hand within hours of a release.

That works only while someone is doing it. A setting chosen by a developer who has moved on leaves the site waiting on someone who has gone.

A worked example

A propeller repair shop near a marina on the coast repairs, reshapes and balances propellers for pleasure boats and small commercial vessels.

Its WordPress site dates from four years ago, and the developer who built it has since left the region. Nobody had logged in for over a year; news went on the shop's Facebook page instead.

After hearing about this release, the office manager found the login in an old email. The site was on 3.4, older than automatic updates, and the admin email was the developer's address.

The theme had also been edited directly, so a theme update would have wiped out the shop's changes.

The site was backed up and copied, and the copy updated first. The theme's edits moved into a child theme, a separate layer that theme updates leave alone.

Once the copy worked, the live site went to 4.0.1, and the admin email changed to an address the office reads. Security releases now arrive by themselves, with an email saying so.

What a missed release says

A site that missed this release is telling you something about its care: nobody logs in, the developer relationship ended, or a setting was changed and nobody owns it.

The version number is the symptom. The finding is a site with no one responsible for updates, which will matter again at the next release, and the one after.

Plugins and themes are separate

Automatic background updates cover minor and security releases of WordPress itself. Plugins and themes do not update on their own unless someone has set them to.

Outdated plugins and themes were behind many compromised WordPress sites this year, so confirming 4.0.1 is the start of the check, not the end.

Update them the same day, after a backup, and remove any that are switched off or no longer used.

The counter-case

Some sites have automatic updates off for good reasons. A developer who keeps the code under version control and tests on a copy may apply this release by hand today, which is just as safe.

Sites not built on WordPress are not affected at all, though they have update cycles of their own.

If your developer works that way, switch nothing on. Ask them today whether 4.0.1 is live, and ask to hear from them after each security release.

Making sure the update landed

1. Log in and read the version number.
2. Look for the update email at the admin address.
3. Back up and update by hand if the update has not happened.
4. Find out why the automatic update did not run.
5. Change the admin email to an address someone reads.
6. Update plugins and themes with the same care.
7. Name the person who checks after every security release.

Step seven matters longest. The update itself takes minutes; what sites that missed this release usually lack is a person whose job it is to notice.

How Drupal's security team told owners to treat sites not patched within hours as compromised, and why updates need someone in charge of them, is laid out in the Drupal 7 update that could not wait.

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.