Xdebug CURL Cron Requests

Support
1

I’m successfully using Xdebug and Local with standard HTTP requests to WordPress (i.e load the front end or an admin page). However, Xdebug doesn’t working at all when trying to debug the WP Cron that has been triggered with spawn_cron (which triggers cron via wp_remote_post).

I toyed around with the Xdebug PHP settings so it would auto-connect back to the host IP address, but for some reason (which I wasn’t able to determine) I still had trouble capturing all cron requests (the change did work for some cron requests):

xdebug.remote_enable=1
xdebug.remote_host=192.168.95.1
xdebug.remote_connect_back=Off
xdebug.remote_port="9000"
xdebug.profiler_enable=0
xdebug.remote_autostart=1

Since I didn’t see another topic about this I thought I’d share this issue.

2

Hi @jakejackson1,

What IDE are you using?

Also, are you using any type of browser extension like the Xdebug helper that sets a cookie for Xdebug?

3

Hi @clay,

I’m on Windows with Local v2.1.2 using PHPStorm with Chrome’s Xdebug helper to automatically set a cookie.

In my testing I found Xdebug wasn’t triggered using the default settings when spawn_cron is called. I was originally testing this on a Subdomain Multisite installation, but after much trial and error found that the container wasn’t aware of how to lookup the subsite domains IP address. For example, you can ping the main website if you SSH into the container, but not the subdomain sites (the main OS host file was patched fine). I ended up swapping over the the Subdirectory Multisite installation to get around this issue.

Once I ensured Cron could be successfully triggered on the subsite, I went back to attempting to trigger Xdebug on the cron calls. If I accessed wp-cron.php via the browser Xdebug ran fine, so that ruled out any IDE problems. I also filtered the wp_remote_post call that actually calls wp-cron.php to include the XDEBUG_SESSION_START=1 param in the URL – in case the cookie wasn’t being passed (FYI, it was not). Still no joy there.

Finally, I adjusted the Xdebug PHP settings so remote_autostart was on, remote_host was set and remote_connect_back was off. Once I restarted the container I could successfully debug the cron tasks executed via spawn_cron. These settings changes helped diagnose why the default Xdebug settings weren’t working. As it were, xdebug.remote_connect_back gets the IP address from the $_SERVER superglobal:

If enabled, the xdebug.remote_host setting is ignored and Xdebug will try to connect to the client that made the HTTP request. It checks the $_SERVER[‘HTTP_X_FORWARDED_FOR’] and $_SERVER[‘REMOTE_ADDR’] variables to find out which IP address to use.`

But because the website was the one triggering wp-cron.php via wp_remote_post the IP address was the containers, and not me, the end user.

Once I worked this out, I went back to disable xdebug.remote_autostart=1 in the php.ini file so I could test if Xdebug would be triggered when the Cron runs. It didn’t. However, appending the cron URL with XDEBUG_SETTING_START did then work correctly (as per https://wordpress.stackexchange.com/a/268003/77011).

TL;DR: if you want to debug WP Cron without manually accessing wp-cron.php via your browser, adjust the containers /conf/php/*.*.*/php.ini file, remove xdebug.remote_connect_back=On and add xdebug.remote_autostart=1 and xdebug.remote_host=192.168.95.1 (double check that IP is yours). Restart the container.

Also, currently the Cron won’t correctly be triggered on a Subdomain Multisite.

1 Like
4