Recently, I discovered an interesting little problem. I run WordPress on
my books-only website, and naturally, there’s testing
that needs to be done to make sure everything is hunky-dory ere any changes are introduced to the
domain. One such change was the introduction of the Site Health check tool in WordPress 5.2, which
tells you of any critical issues and recommended actions for your setup.
On its own, this is fine, but then I noticed a couple of supposedly critical errors showing up with
update to 5.4, indicating a sudden new issue with the domain. The errors were: The REST API encountered
an error and Your site could not complete a loopback request. The details for both these read: Error:
cURL error 28: Operation timed out after 10000 milliseconds with 0 bytes received
(http_request_failed). Weird. Let’s debug.
Problem in more detail
Critical issues sound alarming. But then, you need to look at potential problems carefully, to
understand what the actual impact is. Quite often, companies are over-stringent with how they treat
bugs and problems, because no one wants to be accused of being too lax with issues that could lead to
security complications. So let’s have a look at the status report:
The first issue reads as follows:
The REST API encountered an error
The REST API is one way WordPress, and other applications, communicate with the server. One
example is the block editor screen, which relies on this to display, and save, your posts and pages.
The REST API request failed due to an error.
Error: cURL error 28: Operation timed out after 10001 milliseconds with 0 bytes received
(http_request_failed)
The second one has the following text:
Your site could not complete a loopback request
Loopback requests are used to run scheduled events, and are also used by the built-in editors for
themes and plugins to verify code stability.
The loopback request to your site failed, this means features relying on them are not currently
working as expected.
Error: cURL error 28: Operation timed out after 10001 milliseconds with 0 bytes received
(http_request_failed)
The first error tells us that this is one way WordPress uses to communicate with the server – this
means there are other ways. The error isn’t explicit in whether this will actually cause possible
issues when performing various operations.
It does specifically mention the block editor – the
whole new Gutenberg thingie introduced in WordPress 5.0, which I
do not use, and instead rely on the awesome Classic Editor. So maybe this is a non-issue to begin with.
Then, there’s the question of actual functionality – none of the mentioned functions are affected.
WordPress works and does everything as it should. Perhaps a false positive? We shall see soon.
The second error talks about scheduled events – like background updates, overnight tasks, etc.
Again, if you have none configured, this is a non-issue. If you do, and they run correctly, then the
problem does not affect you. The error does say “working as expected” – but this is not a very
deterministic, precise statement. It makes troubleshooting more difficult.
Source of the problem
But let’s assume for a moment that these are actually real problems. The question is, how do you
troubleshoot where they stem from? Not an easy thing, and there’s nothing in the actual error messages
that can steer you in the right direction.
So what I had to do was manually turn off every single non-default component, one by one, and then
re-run the health check, to see whether any one particular element was at fault. Luckily, I could test
this at leisure, but imagine the impact in a production setup.
Now … after a while, I had tried every single plugin and theme that I was using, and none of these
seemed to affect the outcome. WordPress continued complaining. Then, I decided to expand my search. I
happen to be using an .htaccess file, with basic authentication and a few other useful details, as a
secondary layer of access control to the admin page. Lo and behold, removing the auth part fixed it. No
more health check errors!
AuthType Basic
AuthName restricted
AuthUserFile /home/mastablasta/wp-admin/passwd
Require valid-user
So it would seem – WordPress Site Health does not like .htaccess files. I haven’t explored exactly
how this trips the checks, but then, I do not need to. One, I know what the source of the problem is.
Two, the errors do not affect the functionality that I want and need, hence this is a non-issue.
Conclusion
It is obvious that the problems in Site Health are internal – after all, they only started cropping
up with the move to WordPress 5.4. Of course, some piece of code somewhere has changed, but then,
essentially, if a core product behavior is suddenly radically different than it was just before the
update, and there are no huge problems in the other elements of the site’s functionality, then it’s
quite likely the issue stems from said core product update.
I do like the idea of this site-issues-at-a-glance kind of thing, but I am not happy with the false
positives, or the goose chase that the errors have created for me, even if only briefly. Errors need to
be meaningful. If I have no insight what might be wrong from the way the error manifests, then there’s
really no point showing the technical details. The cURL error 28 and .htaccess seem so far apart.
Anyway, here we are. If you’re affected by a similar problem, have a look at your site configuration,
see if you’re using basic auth, and perhaps suffering from the same would-be bug. We’re done here.