CubeCart Scheduled Tasks and the CLI Cron Runner

CubeCart gained a proper scheduled task system in 6.6.0, a dedicated command line runner in 6.7.4, and the ability for plugins to register their own tasks in 6.7.6. If any feature on your store seems to fire erratically or not at all, this article is almost certainly the explanation.

The problem this solves

Plenty of things a shop needs to do are not triggered by a customer: updating exchange rates, rebuilding the sitemap, sending abandoned cart reminders, sending queued email, batching out a newsletter, clearing caches.

Historically CubeCart had no real answer, so scheduled work was driven by web requests. That has three problems. It runs when a visitor arrives rather than when you want it to. It competes with real customer traffic for resources. And on a quiet store it may not run at all, which is precisely when features like abandoned cart recovery matter most.

The task system

6.6.0 introduced managed tasks with per-task frequency, configurable from the back office. The defaults are:

• Update Exchange Rates, enabled, every 24 hours
• Rebuild Sitemap, enabled, every 24 hours
• Clear Cache, disabled, every 6 hours
• Run Code Snippets / Hooks, disabled, hourly
• Send Cart Abandonment Emails, disabled, hourly

6.7.0 added processNewsletters for batched, throttled newsletter sending, and the same release moved transactional email onto the queue.

Note how many of the useful ones ship disabled. That is a reasonable default (nobody wants a fresh install emailing customers) but it does mean that “CubeCart has abandoned cart recovery” and “your store is sending abandoned cart emails” are two different statements.

The CLI runner, and why you want it

6.7.4 added cli/cron.php, a dedicated command line entry point, with a cli/.htaccess denying direct web access to the directory. The cron dispatcher logic was hardened at the same time and session and cron timing was tightened to a one hour window.

This is the correct way to run scheduled work, and the difference is not subtle:

• It runs on time, on the schedule you set, whether or not anybody visits your site.
• It does not compete with customer traffic. A long-running task no longer makes somebody’s page load slow.
• It runs under the CLI PHP binary, which typically has a much higher (often unlimited) execution time limit than your web PHP. Web timeouts are a common cause of a task that starts and never finishes, which is worse than one that never starts because it can leave things half done.
• Output and errors go somewhere you can see, rather than into a discarded HTTP response.

Setting it up

You need to add a cron entry at server or hosting control panel level. In cPanel that is under Cron Jobs. The shape is a scheduled call to the CLI PHP binary against cli/cron.php in your store directory.

Two things to get right, and both are easy to get wrong:

Use the correct PHP binary. Your hosting may have several PHP versions installed, and the default php on the command line is often not the same version your website runs. Running CubeCart’s cron under a different PHP version than the site can produce failures that make no sense. Check which version your store uses and call that binary explicitly.

Pick a sensible frequency. Every five minutes is a reasonable general default: frequent enough that queued email goes out promptly, infrequent enough that you are not hammering the server. The individual tasks have their own frequencies, so the cron entry is just a heartbeat, not a schedule for each task.

If you host with us, ask and we will set the entry up correctly, with the right binary, and confirm it is firing.

Plugins can register tasks (6.7.6)

Until 6.7.6, a plugin that needed scheduled work had to share the single Run Code Snippets task with everything else. That meant no separate frequency, no independent enable toggle, and no way to tell which plugin’s work failed when the shared task errored.

6.7.6 added a class.cron.tasks hook. A plugin can now register its own task, which then appears in Scheduled Tasks with its own enable toggle, frequency, last run time and last result.

For anyone running several extensions this is a real operational improvement: you can see at a glance which scheduled work is configured, whether it ran, and whether it succeeded. For extension developers it removes an awkward workaround. Our own plugins benefit from this too.

Diagnosing a task that is not running

1. Is the task enabled? Check Scheduled Tasks. Several useful ones default to off.
2. Is there a cron entry at all? Check your control panel. If there is not, your tasks are running on web traffic, if at all.
3. Is the cron entry using the right PHP binary and the right path? A cron job that errors immediately still looks like a configured cron job.
4. Check last run and last result in Scheduled Tasks. From 6.7.6 this is per task rather than lumped together.
5. Check the error log, sorted by first seen, for anything that started when you expected the task to run.

The short version

If you have upgraded to a recent CubeCart and enabled anything that depends on scheduled work (abandoned cart emails, async email, newsletters, sitemap rebuilds), set up a real cron entry calling cli/cron.php. Without it you have configured features that may not be running.

If you host your CubeCart store with us, get in touch and we will set it up and verify it.