Mmmh, some progress: I’m able to activate wp-cron by browser (not really clear, because I have a white screen…): anyway, if I browse wp-cron, jobs are correctly executed and rescheduled… Now I have to understand why crontab do not work…
This issue has been reported here : trac Sometimes, HTTP requests fail. In this case, in particular, on localhost. That’s part of the reason why we suppress them. I’ve personally never seen this. I think it’s isolated to this server configuration. (Nacin)
I had the same problem. My solution was to define the timeout constant for the cron job by adding this line in wp-config.php: define(‘WP_CRON_LOCK_TIMEOUT’, 60); I added this before the line require_once(ABSPATH . ‘wp-settings.php’); and it worked. By default this is set to 0.01 seconds, which to me it makes no sense. This line sets … Read more
…if you have low traffic on your site it may never run due to the way how WP Cron works In your particular example it should always fire. Since save_post runs just before a browser redirect, the subsequent request back to the edit screen will fire the cron schedule. …won’t that delay the page rendering … Read more
Well….I’ve figured it out. Manually deleting everything in Crontrol didn’t help as much as I thought it had. I went to my wp_options table and deleted the entire cron entry. On refresh now, everything looked more or less how I expected, and all of my questions are answered now. When disabling WP Cron to enable … Read more
Because you’re scheduling the event – even though it’s set to run immediately (i.e. with time()), it won’t fire until a second request. So that log output is entirely expected. Try running it again, removing the code, then run once more – you should get: [time] test_action
It looks like Howdy_McGee pinpointed the issue in a comment on the original question: Make the new_interval() a method of your class and call the filter inside your activation hook (above the cron registrations): add_filter(‘cron_schedules’, array( $this, ‘new_interval’ ) );
There might be two ways: add_action( ‘draft_post’, ‘wpse_246730_my_function’ ); function wpse_246730_my_function( $post_id, $post ) { // Do your things // Just to stay safe remove_action( ‘draft_post’, ‘wpse_246730_my_function’ ); wp_publish_post( $post_id ); add_action( ‘draft_post’, ‘wpse_246730_my_function’ ); } Or make the post future status, and set a time after 10 or 20 mins to publish. Then use … Read more
You can use wp-cli to execute schedules without the detour via http request. Add in crontab -e. */30 * * * * wp cron event run –path=/path/to/wp-docroot By this you wont run into maximum execution time problems which could be the reason why you schedule execution got stuck.
Apparently what I was looking for was a hook that sets “do_ping”, and grepping through the theme and plugins there was none. My guess is that it was set through either an old theme or plugin, and not unset when that was deleted. However, I did discover that this function will globally unset it regardless … Read more