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.
    Codit: Crons plays nicely with Elysia Cron
  • 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.