That’s a good description @michelts!
So the add_action with the callback should indeed be registered in for example the init hook. Or anything that is also executed / instantiated when wp-cron runs.
I’m not sure about how calling add_action
in the init
hook ensures the class whose method you’re calling gets instantiated? But it’s an important point: an instance of the class must exist at the time the scheduled job runs.
In my case I was calling a static method, so I didn’t have that particular problem – but you’re right, it can be the cause of this issue in many cases.
-
This reply was modified 2 years, 3 months ago by andfinally.
Michels idea triggered my idea that maybe some code is not available and the error just lets wordpress to remove the cron job without logging – BAD PRACTICE, or is there a wp cron log directory that I am not aware of?
Anyway with me, a plugin was not activated at cron job execution. I disable some plugins for other calls than admin, I load certain plugins especally for cron jobs, but the check for a cron job did not work.
The check if it is a cron job was url based (stripos($request_uri, ‘wp-cron.php’);) and it seems that with a linux solution that uses native cron jobs with sudo crontab -e generates no url.
So I did the check differently with php_sapi_name to check if the call was triggered by the command line(https://stackoverflow.com/questions/16702472/run-a-php-script-only-from-cron-or-check-if-request-from-cron). And voila, wp cron works as expected.
Again, just deleting a cron job in case of an error is very hard to debug… My assumption is – I do not dig deeper now – that some issues of disappearing cron jobs are related to errors that are never logged.
Probably my situation is very unique, but it took me hours to find it out, so maybe these short lines help someone else.