Revision as of 23:01, 14 December 2016

Cron tasks must be created to automate tasks within WHMCS.

Cron is the name given to a system daemon used to execute tasks (in the background) at designated times. WHMCS has a number of files that are required to be run on a periodic basis in this way. All these files are located in the crons directory.

Setting up the Cron Tasks

System Cron

The system cron automates tasks within WHMCS. It should be configured as follows:

Sample Cron Command

You can find a copy&paste ready command with the path specific for your setup by navigating to Setup > Automation Settings within your WHMCS installation and copying the command from the "Create the following Cron Job using PHP" field.

Domain Sync Cron

This cron task monitors for incoming domain transfers and synchronises expiry date changes made directly at a registrar. We recommend running this no more frequently than once every couple of days. Learn more...

Sample Cron Command

The above example will run every 2 days at 3am.

POP Email Import Cron

This cron task is only required if you wish to import emails to the support queue via the POP3 protocol (we recommend using Email Piping wherever possible). If required, this should be configured to run every 5 minutes.

Sample Cron Command

The above example will run the POP3 email import task every 5 minutes.

Secure The Crons Directory

The crons folder may be moved to any place above or below the docroot.

More information on moving the crons folder can be found in the Custom Crons Directory article.

System Cron

The system cron (crons/cron.php) automates tasks within WHMCS. This script can be executed with a number of optional values. This allows very specific control of the tasks performed and the output generated by the script. For most installations, a simple entry that invokes the System Cron script (crons/cron.php) is all that is needed.

Input

The system cron script has the following argument input structure:

The script also provides backwards capability for input options available prior to WHMCS v7.1:

Mixing of legacy option flags with the new argument options is not supported and will not work.

Commands

The cron.php command line script has 3 essential commands:

• all - attempt to perform all due automation tasks. If no input is provided, this command is assumed.
• skip - perform all tasks, just like the all command, but exclude those specified in the input
• do - only perform, unconditionally, the task(s) specified in the input options

There are two supporting commands:

• help - provides usage help & options for the command specified
• list - list all possible commands

Options

Each command has its own set of options which can be view with the help <command> input syntax

Additional Options

• -f, --force
  • Force the execution of tasks, regardless of "due" or "in progress" state
• -v, -vv, -vvv
  • Verbosity of command line output
• --email-report=[1|0]
  • Force send a digest report of work performed during execution. During the normal "daily" run, this is set to an implicit value of "1". In all other cases, the implicit value is "0"
• -V, --version
  • Output the WHMCS version and exits
• --no-ansi
  • Strip any non-printing command line markup (used for color output)
• -h, --help
  • Print help for a command; same as the help command itself

Output

The System Cron will not generate any success console output by default. Use the verbosity options if you require progressive completion information while attending the manual execution of System Cron invocation.

The System Cron will, by default, generate a Digest Email Report when performing the "Daily" group of tasks. This report can be forcibly generated for any particular invocation with the --email-report=1 report. The Digest Email Report will only contain information related to that execution and will not contain aggregate information from prior executions. Please visit the Automation Status page in your Admin area to get an overview of daily aggregated work.

Tasks

All routines of system cron (cron.php) are tasks. Most tasks are daily, and should only be run once a day. Some tasks benefit from running multiple times a day, such as ticket escalations or checking for WHMCS Updates. Other tasks should only run once a month, such as calculating overage usage and generating the respective invoices.

Task Options for skip & do

When performing a skip or do command, you can itemize which tasks are excluded or included respectively. Below is a table that itemizes these task options, as well as their normal frequency.

Types

There are two types of tasks:

• Application: Advances state of client data, such as orders, billing, and provisioning
• System: Provides software related functionality, such as generating backups or performing database normalization.
  • The "DatabaseBackup" task is the only task option of the System type which can be included/excluded from execution. All other System type task options will be performed explicitly as required by WHMCS and thus do not have option flags.

Tasks & --force Option

The "--force" option does exactly that...it will force execute any application tasks (respective of the command [all, skip, do]) regardless if the task is suppose to run once a day, a month, or at a time other than now.

• The all command with the "–force" flag will execute all application tasks, as if each one were due exactly now.
• The skip command with the "--force" will first exclude the specified tasks (i.e., the ones provided as task option flags) and then operate on all other tasks as if each were due exactly now, similar to the all command.
• The do command is designed to only run the tasks specified (i.e., the ones provided as task option flags) and to run them immediately, thus the "-–force" option is always implied and is not a valid option.
• The "--force" option has no effect on System type tasks (except "DatabaseBackup")
• The "--force" option has no effect on whether the Daily Digest Email Report is sent, that is controlled via the --email-report option.

Advanced Task Scheduling

In some environments or use-cases, having fine-grained control of one or more tasks is important. This is possible through a combination of multiple do and skip crontab entries. Tasks performed as part of a do command will not have their internal scheduling tracking modified. This is to ensure the integrity of a normal invocation of the System Cron. If you want a particular task to only execute on a particular schedule, create a do command for that task and alter your main System Cron invocation to skip that task (all other non-itemized task will be performed on the WHMCS schedule in this skip). Likewise, if you never wish to have a particular task executed, alter your System Cron entry to be a skip command with the option for that particular task.

Hook Points

The System Cron has six hook events:

• PreCronJob
  • Fires only during the daily cron run
  • Is invoked before any tasks are executed
  • Registered hooks receive no parameter arguments
• PreAutomationTask
  • Is invoked before each Application task
  • Registered hooks receive one parameter argument:
    • The task object that is about to be executed, which adheres to WHMCS\Scheduling\Task\TaskInterface
    • The return value of this hook is not inspected. However, if an exception is thrown, the task will not be executed, be marked as incomplete, and iteration to the next task will commence
• PostAutomationTask
  • Is invoked after each Application task
  • Registered hooks receive two parameter arguments:
    • The task object that was just executed, which adheres to WHMCS\Scheduling\Task\TaskInterface
    • The boolean state if the task executed without throwing an Exception
    • The return value of this hook is not inspected. Any Exception thrown will be discarded
• DailyCronJobEmail
  • Fires during the daily cron run or when --email-report=1 is specified
  • Is invoked after all Application tasks are executed, immediate prior to the DailyCronJob hook
  • If a registered hook returns true, the digest email report will not be sent
  • Registered hooks receive no parameter arguments
• DailyCronJob
  • Fires only during the daily cron run
  • Is invoked after all Application tasks are executed, immediate proceeding the DailyCronJobEmail hook
  • Register hooks receive no parameter arguments
• AfterCronJob
  • Fires only during the daily cron run
  • Is invoked after all Application & System tasks are executed, just prior to script termination
  • Registered hooks receive no parameter arguments

Example Crontab Entries

Below are examples that demonstrate the flexibility of the System Cron input options and how you could craft your crontab entry. For most WHMCS installation, you should just have one entry (Ex. 1). If you wish to disable certain tasks entirely, consider looking at the related functionality's documentation first to understand how your may be able optimize your WHMCS settings from the administration area and potential avoid unnecessary crontab entries.

Ex 1. Standard System Cron entry:

Ex 2. Explicit entry to perform all scheduled task if they are due (will behave the same as Ex. 1):

Ex 3. Always skip sending domain renewal notices, but perform all other tasks as normal if they are due:

Ex 4. Always skip ticket escalations and auto suspensions. Process ticket escalations Monday-Friday during business hours, at the top of the hour, and auto suspension Monday-Friday at the start of business:

Ex 5. In some hosting environments, direct crontab entries are not permitted. The System Cron can be invoked through an HTTP request (provided the script is accessible within the docroot) The follow demonstrates performing all tasks except DomainRenewalNotices and TicketEscalations

Legacy Cron File Locations

Prior to WHMCS Version 6, the automated task files were located across various directories. Please refer to the top of this page for the new locations of the cron files.

To aide in the transition process to their new locations, Version 6.0 of WHMCS includes proxy files in the old locations that will allow all existing configured cron and piping commands to continue operating without any changes post upgrade to 6.0.

However, we encourage you to update your cron and piping commands to use the new locations at your earliest convenience.

The old locations are deprecated as of Version 6.0, and the proxy functionality will be removed in a future release. The proxy files and their proxy locations are:

• /admin/cron.php
• /pipe/pipe.php
• /pipe/pop.php