Problem/Motivation
Should this module call discoverCronJobs() on cache rebuild rather than module install?
It means that if a developer adds a hook_cron() to a custom module, they won't get a cron job for it automatically.
Steps to reproduce
Proposed resolution
Remaining tasks
User interface changes
API changes
Data model changes
| Comment | File | Size | Author |
|---|---|---|---|
| #5 | discover_cron_jobs-3317033-5.patch | 605 bytes | raushan |
Comments
Comment #2
raushan commentedI am working on this issue.
Comment #3
raushan commentedComment #4
raushan commentedAdd hook_rebuild to implement this feature.
After clearing the cache discoverCronJobs() will run and Cron will be listed on the cron list page.
Thanks
Comment #5
raushan commentedAdded a new line at the end of the file.
Thanks
Comment #6
raushan commentedComment #7
raushan commentedComment #8
liquidcms commentedThis would be excellent as the button on the cron admin page to "discover jobs" does nothing. Although, wouldnt we expect that it just runs the same command this patch is adding to cache rebuild? So possibly the question is what are these discovering?
OP mentions hook_cron but this is Core's hook for running cron tasks; nothing related to UC i wouldn't think. And there is nothing mentioned about hook_cron in ultimate_cron.api.php only a bunch of hooks which some other issues here have suggested are no longer supported. I do see a mention of hook_cron in the README; but no details.
So when i say neither this patch, nor the button on the admin page do anything i am referring to the only thing i have found suggesting how to add new cron tasks to a custom module:
- add exported config (chicken/egg issue) to custom_module/config/install/optional
of course this doesnt work well for modules which have already been enabled (as i think this patch is trying to address).
so i feel some documentation missing somewhere re-purposing core's hook_cron?
Comment #9
guiu.rocafort.ferrerAs far as i know, it goes as follows for hook_cron ( without the provided patch ):
1. When installing ultimate_cron, it will find all hook_cron implementations and create configuration objects for each one.
2. When installing a module which implements hook_cron, ultimate_cron will pick it up and create the configuration automatically.
3. When adding a new hook_cron to an already installed module, then the configuration will not be created automatically, not even cleaning caches. The "Discover jobs" button needs to be pressed.
When it comes to configuration objects, if you added a some cron configuration objects in config/install, and you want to add another one after the module is installed, then you have to write a hook_update to do that. This is not a ultimate_cron issue, but rather an issue with the module implementing the functionality, and it is also the case with other configurations that the module might add after it has been installed.
I tested the patch, and it discovers new hook_cron implementations when rebuilding the caches, so i would say it works as expected, and the issue can be closed. We might want to create a new issue on creating/updating the documentation about how the module works, but i would do it in a separate issue.
Comment #10
guiu.rocafort.ferrerComment #11
berdirI'm not certain this is a good idea. This changes config, it's not just cached data, and could be unexpected. And it does exactly the same as the button in the UI.
Comment #12
guiu.rocafort.ferrerThe way i see it, external events, such as the install of a different module, are already triggering config changes in the ultimate_cron module, so i don't see why that would be different in the case of cache rebuilds. Without this functionality, a module that wants to start implementing a hook_cron would need to do one of the following:
If we dedide on not implementing this, i believe that at least this should be documented, so module developers can implement a hook update to make ultimate_cron pick up the new hook, and create the corresponding configuration object.
Comment #14
berdir> The way i see it, external events, such as the install of a different module, are already triggering config changes in the ultimate_cron module, so i don't see why that would be different in the case of cache rebuilds.
installing a module implies configuration changes. a cache rebuild less so. But it should only do anything if code also changed, so fair enough. Merged.