Silent cron failure if spawn_cron() fails to make the POST request

[idrarig]

At the end of the spawn_cron() function a request is made using wp_remote_post() to wp-cron.php to trigger the cron functionality. If this call is not successful, the cron jobs will never work. The call may fail if the host is not configured properly. This can happen when WordPress knows itself as ​http://localhost while we access it via some port mapping rule as ​http://localhost:5555. I think it would be wise to give a warning somewhere because with modern technology (containers or VMs) and routing this problem happens easily and it's hard to debug. I don't know WordPress enough to suggest where the warning should go, but the user or the admin should definitely know of these problems.

[johnbillion]

Thanks for the report, idrarig.

Can you explain a little more about your configuration, and why WordPress is set up as localhost but is accessed via localhost:5555?

The reason the response isn't checked is because the request is designed to be a fast, non-blocking one that is simply triggered on the current page load. The return value is of no interest to spawn_cron(), and checking its response would mean blocking the page load while the request occurs.

P.S. you can check that WP-Cron is working as expected on your site with ​the WP Crontrol plugin.

[idrarig]

What you say about not checking the result of the remote request because of speed issues makes perfect sense to me too, so let's not change that.

Still, another way to report this setup problem would be to do a check when installing WordPress, or after activating a new plugin. The check could be trying to issue a GET request to the website to see if it's reachable from within the website itself.

To better explain my configuration, let's consider another scenario. Suppose you have a machine (be it a container, VM, VPS, whatever...) accessible from a certain public IP 1.2.3.4, and then configure the DNS so that yourdomain points to 1.2.3.4. You install WordPress on yourdomain and this goes smoothly. But if the machine itself does not really have the public IP 1.2.3.4 but is on a private network 10.0.0.0, and routing/firewalling is not properly taken care of, the machine may not see itself as yourdomain. This happened to me in production with a proprietary webapp, but the setup problem applies to any website.

During development, I have a port mapping localhost:5555 -> container:80 set up by docker. This way I installed WordPress on ​http://localhost:5555, but from within the container the request to ​http://localhost:5555/wp-cron.php cannot work.

(I didn't try the plugin you mentioned but according to the description, it wouldn't help with reporting these kinds of problems.)

[SergeyBiryukov]

Duplicate of #23133.