Three WordPress Updates in Eight Days

Eight days in April

On April 21 WordPress released 4.1.2, a security fix. On April 23 came 4.2, a new version with new features. Yesterday came 4.2.1, another security fix.

On many sites the security fixes installed themselves. WordPress emailed to say so, often to an address nobody reads, so plenty of owners have no idea.

Other sites are still on whatever version they ran last week, or last year. Nothing on the page looks different, which is why nobody has noticed.

Which of the two describes your site is worth finding out this week. The dashboard's At a Glance box shows the version, and so does the foot of every admin screen.

What each release fixed or added

4.1.2 fixed a serious flaw that could let an anonymous visitor plant code that runs in the browser of whoever views it, an administrator included, along with several smaller problems. The technical name is cross-site scripting.

4.2 brought emoji, a faster Press This tool for posting from other pages, plugin updates without leaving the plugins page, and switching themes inside the Customizer.

Behind the scenes it also converts the database, where the server allows, so that it can store emoji.

4.2.1 fixed a flaw in comments that could let a commenter take over a site. It affected earlier versions as well as 4.2.

Minor releases and major ones

Since version 3.7, in late 2013, WordPress installs minor releases by itself on most sites. A minor release changes the third number, as from 4.1.1 to 4.1.2, and is almost always a fix.

Major versions, which change the second number, as from 4.1 to 4.2, wait for someone to click update. They bring new features, and new features can upset a plugin or a theme.

So a well set-up site on 4.1 took 4.1.2 by itself last Tuesday and stayed on 4.1 when 4.2 arrived. A site someone had moved to 4.2 took 4.2.1 by itself yesterday.

Why a site did not update itself

• It runs a version older than 3.7, from before automatic updates.
• A developer switched them off in the configuration file.
• A plugin or the host turned them off.
• The server will not let WordPress write to its own files.
• The built-in scheduler is off, with nothing on the server replacing it.

The second is the most common surprise. A developer often turns automatic updates off during a build, intending to handle updates by hand, and the owner never learns that nobody now does.

A version behind

A site left on 4.1 keeps working. The question is what it misses as the months pass.

WordPress only promises to support the newest version. Security fixes have often been released for older ones too, but that is a courtesy rather than a commitment, and nobody should plan around it.

Plugin authors test against the current version and gradually stop testing against old ones. Sooner or later an update to a plugin you rely on needs a newer WordPress than you have.

And each month adds to the eventual jump. Moving from 4.1 to 4.2 now is a small step; moving from 3.9 to whatever is current next year is a project.

Plugins and themes wait for a click

Automatic updates cover WordPress itself. Plugins and themes normally update only when someone clicks, and on many sites that is where the real exposure lies.

In the same week as 4.1.2, a number of widely used plugins released security fixes of their own. A site with WordPress fully up to date and plugins from last year is still open.

Plugins nobody uses should be deleted, not just deactivated, since a deactivated plugin's files still sit on the server.

A worked example

A seasonal decorator dresses shopping centre courtyards, office lobbies and storefronts for Christmas, with smaller jobs for spring and Halloween. Its WordPress site shows each season's installations as posts with photographs.

April is quiet, and nobody had logged in since January. When the owner finally did, to add a spring window, a notice across the top said a newer version was available. She assumed that was the developer's job.

It was not. The developer who built the site had switched automatic updates off, meaning to look after them on a maintenance plan the business never took up. The site still ran the version it launched with.

A developer took a full backup, switched automatic updates back on, moved the site to 4.2.1, updated the plugins, deleted two unused ones and tested the contact form and galleries.

Comments on old gallery posts, which only ever attracted spam, were closed. The site's admin email now goes to the owner, and the developer checks the site after every release.

Before clicking update

Major versions deserve a few minutes of care. Back up the files and the database first, and know how you would restore them.

Update on a quiet weekday, not a Friday evening. Then check the pages that matter: the contact form, anything that takes bookings or payment, and the home page on a phone.

If something breaks, the backup is what turns a bad afternoon into a short one.

Who should be watching

Every WordPress site needs one named person who notices releases and checks the site afterwards: a developer on a maintenance plan, a host that manages WordPress, or someone in the business.

WordPress emails the site's administration address after it updates itself, and in some cases when it could not. Make sure that address belongs to someone who reads it.

The owner should know who that person is without having to look it up.

The counter-case

Some developers switch automatic updates off on purpose, for shops and complex sites where every change is tested first. That is a sound approach, provided each security release really is applied within days.

And a site with automatic updates on is not finished: plugins, themes and major versions still need someone. Automatic updates are a safety net, not a maintenance plan.

Keep minor updates automatic, take major versions within a week or two, and give the job to a named person.

Before the next release

1. Check which version your site runs.
2. Confirm automatic updates are switched on.
3. Back up everything before updating.
4. Update to 4.2.1, then the plugins.
5. Delete plugins nobody uses.
6. Test forms and payments afterwards.
7. Name the person who watches for releases.

Step seven is the one that prevents the next surprise. Most sites that missed this month's fixes did so because each person involved assumed someone else was watching.

What happens to a site left behind for years is covered in a site still running Joomla 1.5.

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.