Cron Command Laravel Package

Technical Evaluation

Architecture fit

• wp-cli/cron-command is a WP-CLI command package, not a Laravel/Composer library. It registers wp cron event and wp cron schedule subcommands and depends on a bootstrapped WordPress runtime (wp-load.php, _get_cron_array(), wp_schedule_event(), etc.).
• It ships no Laravel service provider, facade, config publish, or framework-agnostic API. There is no path to composer require it into a Laravel app and call it as a library.
• Fit is therefore conditional and narrow: viable only where the PHP estate already contains a WordPress installation (headless CMS backend, marketing site alongside a Laravel product, or a legacy WP app being maintained). For a pure Laravel service, architecture fit is poor.

Integration feasibility

• Realistic integration is out-of-process: Laravel invokes the wp binary via Symfony Process (wp cron event run --due-now --path=/var/www/wp), parses --format=json output, and surfaces results in logs/health checks. This is workable but adds a hard runtime dependency on shell access, WP-CLI version, and filesystem paths on every environment including CI.
• In-process reuse would require bootstrapping WordPress inside a Laravel process — heavy, global-state-polluting, and not recommended.
• Installation is via wp package install wp-cli/cron-command (or a Composer path/VCS entry consumed by WP-CLI's package manager), not a standard app dependency.

Technical risk

• Ecosystem mismatch is the dominant risk: effort spent wiring this in is largely non-reusable if the WordPress component is ever retired.
• Low adoption signal: 32 stars, no vendor SLA, community-only support. Maintenance sits under the WP-CLI org, which is a positive trust signal, but the bus factor on this specific command set is small.
• Metadata anomaly: the stated last release of 2026-08-04 is in the future relative to normal release cadence; treat the version/date data as unverified and confirm against the actual repository tags before committing.
• WP-Cron semantics: WP-Cron is a pseudo-cron triggered by page loads; correctness depends on DISABLE_WP_CRON, real system cron, and object-cache behavior. The CLI does not remove those constraints, it only gives you a manual trigger.
• Silent failure surface: WP-Cron swallows callback errors; exit codes from wp cron event run are not a reliable success signal for the underlying job.

Key questions

1. Is there a WordPress installation in scope at all, or is this being evaluated for a Laravel-only stack? (If the latter: stop — use Laravel's scheduler.)
2. Are we trying to operate existing WP-Cron events, or migrate off WP-Cron? The package is useful for the former, a stopgap for the latter.
3. Who owns the WordPress runtime — same team, or a separate CMS team? Cross-team operational ownership is the usual failure point.
4. Do all target environments (prod, staging, CI, local) have wp on PATH and shell access, or is this a containerless/managed host?
5. Is there an existing inventory of scheduled events, and are any long-running or business-critical?
6. What is the verified release/version history and PHP/WordPress compatibility matrix?

Integration Approach

Stack fit

• Fits: PHP 7.4/8.x + WordPress 5.x+ + WP-CLI present, with Laravel as a sibling service or a WP-backed frontend.
• Does not fit: Laravel-only apps. The correct native equivalent is Illuminate\Console\Scheduling\Schedule with withoutOverlapping(), onOneServer(), runInBackground(), and Schedule::command() — no external package required.

Migration path (the primary TPM use case)

• Use the package as a discovery and decommissioning tool, not a permanent dependency:
  1. Inventory: wp cron event list --fields=hook,next_run_relative,recurrence --format=json.
  2. Map each hook to a Laravel scheduled task or an explicit deprecation decision.
  3. Reimplement business logic natively in Laravel; do not shell out to WP for new work.
  4. Set DISABLE_WP_CRON=true and drive remaining WP events from system cron via wp cron event run --due-now.
  5. Retire the package once the event list is empty.

Compatibility

• Constrain by WP-CLI core version rather than the package alone; WP-CLI minor releases have changed package APIs before.
• PHP version must satisfy both WP-CLI and the host WordPress — pin explicitly and verify in CI.
• Composer autoloading will not expose these commands to Laravel; do not expect PSR-4 discovery.

Sequencing

1. Confirm WordPress scope and ownership (week 0 gate — kill the initiative here if no WP).
2. Verify package provenance, tags, and compatibility against the target WP/PHP versions.
3. Build a thin Laravel wrapper (Process + timeout + JSON parse + structured logging) rather than scattering exec() calls.
4. Dry-run in staging against a snapshot of the production cron array.
5. Cut over events one at a time; keep the wrapper read-only (event list) until each write operation is proven.
6. Add a dashboard/alert on "events due but not run in N minutes" before enabling any event delete.

Operational Impact

Maintenance

• Low code churn expected, but unowned dependencies rot. Assign an explicit owner; review on each WP-CLI major release.
• Track three moving parts simultaneously: WP-CLI version, WordPress core version, and this package. Version skew across these is the most common breakage.
• If the Laravel wrapper exists, it becomes internal code you now own and test — budget for it.

Support

• Community-only: GitHub issues, no SLA, no security advisory process specific to this package (it inherits WordPress/WP-CLI advisories).
• Requires a written runbook covering: how to list due events, how to force-run one, how to safely delete, and how to recover a deleted recurring event.

Scaling

• WP-Cron is not built for concurrency. There is no distributed lock equivalent to Laravel's onOneServer(); the transient-based doing_cron lock is unreliable under misconfigured or eventually-consistent object caches.
• wp cron event run is serial and blocks on long callbacks; a single slow event delays all subsequent ones.
• Running both page-load WP-Cron and system-cron WP-Cron causes duplicate execution. Pick exactly one trigger mechanism.

Failure modes

• Duplicate runs — both trigger paths active, or lock expiry during a long job. Mitigate by disabling one path and using idempotent handlers.
• Missed runs — system cron misconfigured or host migration dropped the crontab entry; no built-in alerting.
• Silent job failure — callback throws, WP-Cron logs nothing, CLI exits 0. Requires application-level heartbeat checks, not exit codes.
• Data loss — wp cron event delete is immediate and irreversible; a deleted recurring event is gone until code re-registers it.
• Environment drift — --path differs between local/staging/prod, causing the wrapper to operate on the wrong install.
• PHP fatal / memory exhaustion on long events kills the CLI process mid-run, leaving the cron lock in place until transient expiry.
• Timezone mismatch between the Laravel host, the WP install, and the cron schedule producing off-by-hours execution.

Ramp-up

• For engineers with WordPress/WP-CLI experience: low — a few hours to productive use.
• For a Laravel-only team: high — requires learning WP-Cron internals, WP-CLI package management, WordPress bootstrap, and host-level cron. This asymmetry is the strongest argument for keeping the WordPress boundary owned by a WordPress-fluent team and exposing only a narrow contract to Laravel.

Recommendation Do not adopt into the Laravel dependency graph. If a WordPress installation is genuinely in scope, treat wp-cli/cron-command as a short-lived operational bridge for inventorying and decommissioning WP-Cron events during a migration to Laravel's native scheduler, with a defined sunset date and a named owner. If no WordPress exists, close the evaluation.