Weave Code
Cron Laravel Package
ibexa/cron
Exposes cron/cron for Ibexa and Symfony through the simple ibexa:cron:run command. Tag existing Symfony commands as cron jobs with schedules, optional categories, and custom options, then run them from system cron. A lightweight alternative to cron-bundle.
At a glance
Frequently asked questions about Cron
- What is ibexa/cron and how does it differ from cron/cron-bundle?
- ibexa/cron is a thin adapter that exposes the cron/cron expression library inside an Ibexa DXP or Symfony console application behind a single ibexa:cron:run command. It lets you declare schedules as a service tag (ibexa.cron.job) so job definitions travel with your code instead of living in an ops-managed crontab. Unlike cron/cron-bundle it adds no administration UI, no persistence, and no run history - just tag-based schedule matching. The README presents it as a simpler alternative that may later grow cluster-aware behaviour.
- How do I install ibexa/cron and set up the system cron entry?
- Run composer require ibexa/cron, make sure the package is registered in your Ibexa kernel or DI setup, then add one crontab line that calls bin/console ibexa:cron:run every minute. Optionally pass --category=default or another category name to run a subset of jobs. No schema, daemon, or extra infrastructure is required because the package stores nothing. The command is designed to be polled per minute rather than run as a long-lived process.
- Does ibexa/cron work with Laravel or plain Symfony apps?
- No, not really. It only fits where an Ibexa DXP kernel boots; the README's 'or just plain Symfony' wording means a Symfony console app wired with Ibexa DI conventions, not a drop-in for any Symfony or Laravel project. For Laravel, use the framework's built-in scheduler, and for generic PHP use cron/cron directly. Treat ibexa/cron as an internal Ibexa component published for consumption inside the DXP distribution.
- How do I tag an existing Symfony command as a cron job with a schedule?
- Add the tag ibexa.cron.job to a service that already has the console.command tag and give it a schedule, for example { name: ibexa.cron.job, schedule: '* * * * *' }. The schedule accepts any crontab-style expression supported by cron/cron, such as '0 3 * * *' for nightly work or '*/5 * * * *' for every five minutes. You can set category and options on the same tag. The job fires only when ibexa:cron:run happens to execute during a matching minute.
- What does the category option in ibexa/cron do?
- Category groups tagged jobs so a single crontab entry can invoke a subset of them, for example separating infrequent maintenance from per-minute work. It defaults to 'default' and is selected with --category on ibexa:cron:run. Every category you define needs its own crontab line, otherwise those jobs never execute. Category controls cadence, not topology, so it does not make a job run on only one node of a cluster.
- How do I pass custom options to a command run by ibexa:cron:run?
- Use the options argument on the tag to append extra flags and values to the underlying command, for example options: '--keep=0 --status=draft'. The whole string is passed through to the Symfony command, so the syntax must match exactly what that command expects. Leave it at the default empty string for commands that take no arguments.
- How do I log the output of cron jobs run by ibexa:cron:run?
- Add a monolog channel named cronjob with a handler writing to a channel-scoped file such as %kernel.logs_dir%/cronjob.log at level info, and the run command will log what the executed commands output. The README's crontab example redirects to /dev/null 2>&1, which discards exactly the output you need when a job silently stops running, so drop that redirect or log to file. Without logging you have almost no evidence of failures.
- Does ibexa/cron support locking, clusters, or preventing overlapping runs?
- No. There is no lock, no overlap guard, and no coordination between application nodes, and the README lists cluster support (all-nodes versus one-node jobs plus a lock system) as future work. If two invocations of ibexa:cron:run overlap, the same job can start twice. Use an infrastructure-level mutex such as a single designated cron node, flock, or a Kubernetes CronJob with concurrencyPolicy: Forbid.
- Does ibexa/cron support retries, run history, or failure alerting?
- No. It is stateless polling: a job runs only if the command executes during a matching minute, and there is no persistence, retry, catch-up, or alerting. If the host is down, a deploy is in progress, or a previous run is slow, that window is lost with no record. Teams that need retries, run history, or alerts should plan for symfony/scheduler or a dedicated job runner instead.
- What license is ibexa/cron under and is the package actively maintained?
- Composer metadata reports NOASSERTION, so automated compliance tooling cannot clear it, and Ibexa's copyleft history means legal sign-off is needed before distribution or OEM use. Check the repository composer.json and get written confirmation from Ibexa. Adoption signals are thin - a few stars, no dependents, and a typo in the README - so expect health to track Ibexa's release cadence rather than a community roadmap. Verify the reported last-release date on Packagist before treating it as a trust signal.
Weaver
How can I help you explore Laravel packages today?