Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
I created a module with hook_cron implementation, then moved that implementation to a different location specified in ultimate_cron job config yml.
After clearing the cache the new job was registered properly, however, the old implementation stayed in config and is causing PHP errors because the module attempts to run a non-existing function.
Comments
Comment #2
Berdirwhat php errors?
what should happen is that it is skipped and that the UI allows you to delete that job and reports it as broken.
Comment #3
Graber CreditAttribution: Graber as a volunteer commentedWarning: call_user_func() expects parameter 1 to be a valid callback, function '[the old hook_cron implementation]' not found or invalid function name in Drupal\ultimate_cron\Entity\CronJob->invokeCallback() (line 316 of /var/www/html/hinderpremie-sts/modules/contrib/ultimate_cron/src/Entity/CronJob.php) + trace.
I deleted the old config manually using PHP:
Drupal::configFactory()->getEditable('ultimate_cron.job.[the old hook_cron implementation]')->delete();
Ok, to think of it, yes There was an option to delete the job from the UI, shouldn't it be done automatically though?
Imagine a contrib module beeing updated with removal of no longer needed hook_cron and the site logging warnings..
Took me a while to find out what the problem was, but what if a site admin doesn't know where to look?
Maybe something to consider..
Comment #4
BerdirThe problem is that code changes/deployments don't trigger anything we can listen to, so we could only clean it up when pressing that rebuild button on top.
My reason was to make this change obvious and not automatically deleted it. But there shouldn't be PHP errors leaving open to investigate that. Can you add the stacktrace too?
Comment #5
Graber CreditAttribution: Graber as a volunteer commentedI'd have to go through a heap of db_log pages it's a dev site. You can reproduce by simply deleting some hook_cron implementation after it was registered.
Yes, there is no removed code trigger, but a solution would be to delete all config items added by the module automatically and recreate them on cache rebuild. The problem is they may have some custom settings from the UI.. Maybe just a check if the callback exists on cr and cleanup or simply catch the warning with is_callable and show a relevant message to the site admin with a link to the cron jobs form?