WordPress 5.2 adds a Site Health screen under Tools and emails the administrator a recovery link when a plugin or theme crashes the site. Fix the critical items, and make sure that email reaches someone who will act.

What arrived today

WordPress 5.2 was released today. Most of it is invisible to the people who run a business site, but two additions deserve an owner's attention.

The first is a Site Health screen, under Tools, which checks your site and the server it sits on, then lists what it found.

The second is protection against fatal errors. When a plugin or theme crashes the site, WordPress now emails a link to a recovery mode instead of leaving a blank white page and silence.

It also raises the minimum PHP version to 5.6.20, which matters for any site still running something older.

What the screen checks

The Status tab sorts what it finds into critical issues and recommended improvements, with the passed tests folded away underneath.

The sixth is the one most owners have never heard of. WordPress installs minor security releases by itself, but only when the server allows it, and until today there was no plain way to see whether yours did.

A second tab, Info, lists the site's configuration and copies it in one click for your developer. Send it only to people you already trust with the site.

The warnings that matter

A few items describe a site that is exposed today.

An old PHP version is the main one. Treat it as seriously as the notice that arrived with 5.1 in February: the fix is a tested upgrade, not a dismissal.

Debug output shown to visitors is next. It was usually switched on to chase a problem and never switched off, and it can show strangers how your server is laid out.

Waiting updates and background updates that cannot run belong together, since between them they decide whether security fixes ever arrive.

Inactive plugins round out the list: switched off, but still on the server, where their old code can be reached by anybody who knows where to look.

The warnings that can wait

Others can go to your developer without being treated as emergencies.

A missing PHP module usually affects one feature, such as how uploaded images are resized, and keeping a default theme installed is housekeeping.

Late scheduled tasks are common on quiet sites, because WordPress runs its schedule when somebody visits. The exception is a backup plugin that relies on that schedule, which is worth confirming.

A failed loopback request, the site's test of calling itself, is often caused by a security plugin or the host's settings. It needs a look, not a panic.

When a plugin breaks the site

Until now, a fatal error in a plugin or theme usually meant a blank white page, with no clue which of twenty plugins was responsible.

In 5.2, visitors see a short message saying the site is having technical difficulties, and WordPress emails the site's administration address with the name of the culprit and a link.

The link opens a recovery mode in which the faulty plugin is paused for you alone, so the dashboard works and you can deactivate it or call for help.

The public site stays broken until somebody does, and the link expires after a day. An email sitting unread in the wrong inbox over a long weekend helps nobody.

A worked example

A picture framing shop on the main street of a valley town had a WordPress site built in 2015 by a developer the owner has since lost touch with.

On a Friday evening in April, with orders for graduation and wedding gifts starting to arrive, somebody updated a plugin that clashed with the theme. Every page went white, and nobody looked at the website all weekend.

A customer picking up a framed print mentioned it at the counter on Sunday. Restoring Friday's backup on Monday took under an hour.

This week, preparing for 5.2, the owner found that the administration email was still the developer's old address, at a business that had closed.

Had 5.2 been running that Friday, its warning would have gone to a dead inbox. The address now points to a shared mailbox the owner and the site's maintainer both read.

Five inactive plugins came off the server the same afternoon.

Who should receive that email

The address is the email field under Settings, then General. It was typed in when WordPress was installed, and on many sites it still belongs to the original developer, a former employee, or nobody at all.

Use an address that belongs to the business and is read every day, ideally one that reaches you and whoever looks after the site. Changing it sends a confirmation to the new address first.

A developer can also route recovery emails elsewhere with one line in the site's configuration file, which suits a business whose maintenance company should hear first.

The PHP minimum

WordPress 5.2 will not install on PHP older than 5.6.20. A site on PHP 5.4 or 5.5 cannot take the update, and will stay on 5.1 until its PHP is upgraded.

That is not a safe place to wait. PHP releases that old have been without security fixes for years, and plugins will increasingly assume the newer WordPress.

The new version also refuses to activate a plugin that says it needs a newer PHP than yours, which closes one common way of breaking a site with a single click.

The counter-case

The screen is a checklist, not a diagnosis.

A site on a maintenance plan, where somebody already watches updates, backups and uptime, will learn little from it that its maintainer does not know.

A clean result does not mean a secure site either. It cannot judge a weak password, a plugin with a known flaw, or a backup nobody has tested.

And where nobody at the business logs in, the owner's part is simply making sure the right person gets the email.

Read the critical items, pass the rest on, and check where the recovery email goes.

This week

  1. Back up the site before updating anything.
  2. Update to 5.2 on a copy first.
  3. Open Site Health under Tools.
  4. Check the email address under Settings, then General.
  5. Send the critical items to whoever maintains the site.
  6. Delete inactive plugins nobody plans to use.
  7. Ask about the PHP version if it is flagged.

Step four is the one that decides whether the new protection does anything. An email that lands in a dead inbox on a Friday night is no email at all.

The PHP notice that arrived with the previous version is covered in WordPress 5.1 and the notice about your PHP version.


Frequently asked questions

What is the Site Health screen?

A new screen under Tools in WordPress 5.2. It checks your site and server, then lists critical issues and recommended improvements, with the passed tests folded away underneath.

Which Site Health warnings matter most?

An outdated PHP version, debug output shown to visitors, updates that are waiting or cannot install themselves, and inactive plugins left on the server.

What happens when a plugin crashes the site?

Visitors see a short message about technical difficulties, and WordPress emails the administration address with the plugin's name and a link to a recovery mode where it is paused.

Does recovery mode fix the public site?

No. The faulty plugin is paused only for the person using the link. Visitors keep seeing the error until somebody deactivates, updates or replaces the plugin.

Who should receive the recovery email?

Someone who reads email daily and can act. Use a business address that reaches both you and whoever maintains the site, set under Settings, then General.

What if my server runs old PHP?

WordPress 5.2 needs PHP 5.6.20 or newer, so the update will not install and the site stays on 5.1. Have a PHP upgrade tested on a copy.

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.

Not sure who gets your WordPress emails?

We will check where the recovery email goes, read your Site Health results with you and fix the critical items.

Start a Conversation