Intro to Codit Crons - Cron Jobs made easy.
Codit: Crons uses the Codit framework to make the development of multiple cron jobs easy. In most cases it ends up being both more flexible, and safer than custom coding hook_cron() in a custom module or Feature for a site.
Why should I consider using Codit: Crons?
- You can have multiple cron jobs each with their own timing.
- Simple to add, disable, or enable a cron job.
- drush codit-crons-add {cron_job_name}
- drush codit-crons-enable {cron_job_name)
- drush codit-crons-disable {cron_job_name}
- Simple to see a list of enabled cron jobs
- drush codit-crons-list
- Uses Drupal Queue system to prevent one bad cron job from de-railing the others.
- Plays nicely with Elysia Cron. If you use Elysia Cron, then each cron job from Codit: Crons shows up where you can override its timing rules. Or run it by hand.
- Portability. Copy a cron job directory from site A to site B.* As long as the cron job does not rely on external code that is not on site B.
- Less potential code bloat. The code for each cron job is only loaded when that cron job runs.
- All code, no admin.
Why not just create a custom hook_cron() for each cron job I need?
- There can be only 1 hook_cron / module.
- Working out custom timing in each hook can be troubling. (which is why Elysia Cron was created and is so popular).
- Doing more than one cron job in a single hook_cron is messy and causes a lot of code to be included at bootstrap.
- Many cron hooks don't use the Drupal Queue, so if one cron hook fails, it fails silently and prevents any that come after it from running.