I’ve been maintaining the Health Check plugin since 2017, its origins as a core plugin, and then as a community plugin focused on support, having been its primary uses.

I’m not going to stop maintaining it, but over the two years, it’s stagnated a bit, after its inclusion in core, keeping up with maintaining it became a chore, and not the labor of love that it started out as.

That’s changing 💪!

The plugins history

The Health Check plugin was originally created to provide some simple compatibility checks for PHP and MySQL versions before the release of WordPress 3.2, and then to check for support for the utf8mb4 SQL support later on, but has since been dormant.

The plugin was then adopted in 2017 (wow, it’s been a while, hasn’t it?) as a direct result of core ticket #39165, and a desire to provide debug information that end users can present to those providing support, but it not being the best fit for core at the time.

Alongside this debug information, various checks to identify common configuration errors on a website were introduced, still keeping the original essence of the first plugin in place.

At the end of 2017, the Troubleshooting Mode was also introduced, allowing less technical users, without knowledge of, or access to, staging and local development environments for testing, the ability to do the usual troubleshooting steps of disabling all plugins and using a default theme, without affecting regular site visitors.

Fast forward to 2019, and the Site Health checks, and Debug Information features from the plugin were introduced to core, as part of a larger Site Health component push, alongside things like ServeHappy (the endeavor to push users to upgrade their PHP versions).

The problem that needs solving

The major problem that needs solving at this point is the maintenance of backwards compatibility, and feature parity between WordPress core and the plugin.

The initial dream was that new Site Health features would land in the plugin first, to be tested out on the (at this time) more than 300 000 users it has to gauge the effectiveness of new tests, and value of new debug information.

Unfortunately, with a project as large as WordPress, this becomes difficult, and fragmentation is bound to happen, and I felt burnt out trying to think of ways to tackle the moving of tests back and forth in a reliable manner, especially as things landed in core directly for various reasons.

The various solutions considered

It should be noted that the following considerations were made back when the amount of WordPress 4.9 installations were much larger than they are today, and there’s been a noticeable shift of users moving up in versions over the past year or longer.

So many options for fixing this disconnect passes through your head, and they all have their pros and cons. I’m a huge fan of maintaining backwards compatibility, the user shouldn’t lose features just because something changed elsewhere.

Keeping back-compat files

The “simplest” fix, but this had one major drawback, you still need to maintain these files, not just with regards to PHP version changes, but if a security concern is discovered in these files, you need to address that. The Site Health Checks and Debug Information were massive elements

• Debug Information in WordPress 5.9
• Site Health Checks in WordPress 5.9

That’s a lot of code to maintain for no real gain.

Just delete the files

The second option, is of course to just remove the functionality that now exists in WordPress core.

Also viable, to make this an un-jarring experience to the user, the minimum WordPress version for the plugin would then also need to be raised to at least 5.2, it is at the time of writing set to 4.0 or newer (that’s a big jump).

The final decision

In the end, the need to reduce unnecessary complexity won, but “back-compat” is still important, but in a different coat.

I chose to create a Site Health “core module polyfill” for sites running WordPress versions earlier than 5.2 (when the feature was added to core), but with stripped and/or removed functionality.

The most complex part to maintain was always the Site Health check, these are going away. When a user visits the Site Health menu item, they will be presented with the following screen:

The Debug information is being maintained, as it is in the plugin before the release of version 1.5.0, the reason for this is that users may wish to update, but need to verify that their platform supports the newer versions of WordPress, or its plugins.

By doing it this way, users are not left confused as features go away, they are presented with a clear path to regain features, and an explanation of why things have changed. Both of these are equally important for making sure users are not left confused and frustrated.

Could this have been solved by just retiring the plugin and making a new one focused entirely on the troubleshooting aspects?

Oh absolutely, but over the years, the Health Check plugin has grown to be a recognized name in support circles to point users to for troubleshooting, and asking all those providers to change their routines, changing their documentation, getting new resources to show how it’s all connected? I don’t personally think that’s responsible either.

What the future brings

With moving to using core for checks directly, the plugin is able to make use of filters to dynamically add new checks which may not fit the core narrative, but still are beneficial to a large enough portion of users/support providers, instead of relying on matching back and forth between a plugin and core.

It also makes the entire plugin more maintainable, re-igniting that original passion for improving the various tools it offers, and wowee do I have plans for tools I want to add, and enhancements to the troubleshooting mode, but they’ve all been blocked by this frustration with the state of the original features.