Action Scheduler 2.0
Action Scheduler has been undergoing some major enhancements to bring better performance, future compatibility, and greater reliability.
Here's what you can expect from this release of Action Scheduler. For an in-depth review of the changes, you can view the differences between the 2.0.0 branch and the 1.5.3 branch.
Action Scheduler now includes a built-in WP CLI command for running scheduled actions. This command provides an important new way to run scheduled actions, especially for high-volume stores. For all of the details on what the command can do, refer to the Action Scheduler Readme, or run wp action-scheduler run --help.
One cool feature of the new WP CLI commands is that you can create queues to process only actions in a specific group, or with a specific hook or hooks. When processing large batches of actions concurrently, making each queue handle a specific action can greatly increase the rate of processing and reduce any potential for issues like database deadlocks.
As indicated by the version number, version 2.0.0 contains breaking changes. For that reason, we want developers who rely on Action Scheduler to know what changes they will need to account for when updating from Action Scheduler 1.5.3 to 2.0.0.
The abstract ActionScheduler_Store class has been updated with new abstract methods. If you have a custom data store that extends this class, then you will need to implement the new methods in your class before updating Action Scheduler. These are the new methods that must be implemented:
- Public function
save_action() - Public function
action_counts() - Public function
get_status() - Public function
get_claim_id() - Public function
find_actions_by_claim_id()
In addition to the new functions listed above, the stake_claim() function has updated parameters. For full details of what is required to implement these methods, please refer to the source code of the ActionScheduler_Store class.
The as_get_datetime_object() function will now return an ActionScheduler_DateTime object instead of DateTime object. This change was made to ensure that older versions of PHP (namely, PHP 5.2) can make use of the getTimestamp() method. The ActionScheduler_DateTime object extends the native DateTime class, so there should be no problems.
For the reasons behind why this change was made, see issue #120.
One major upcoming change of Action Scheduler is the use of custom tables to store actions and their data. This change will take the place of the Custom Post Type API provided by WordPress.
In preparation for this change, the Admin UI for the scheduled actions now uses an abstracted data store to retrieve the actions to display. This makes it easier to make the switch to a different data store abstraction without needing to change the list table code again. This also means that you can use your own data store and have the list table work properly!
The Admin UI will continue to be accessible via the Tools > Scheduled Actions administration screen. In addition, it is now accessible via a new Scheduled Actions tab included under the WooCommerce > System Status administration screen.
Action Scheduler defaults to running on WP Cron. In short, this means that its functionality must be completed within a normal web request. On shared hosting, the time that a web request is allowed to execute is often capped at 10 minutes. But for many managed hosts, the timeout is a strict 1 or 2 minutes. These restrictions make sense for high performance blog hosting, but they can cause Action Scheduler to fail when processing scheduled jobs.
In light of these restrictions, Action Scheduler will try to determine whether it is running on a host with a known limited timeout. The following hosts and timeouts currently accounted for are:
- WP Engine: 60 seconds
- Pantheon: 60 seconds
- Siteground: 120 seconds
For other hosts, Action Scheduler will attempt to use the max_execution_time setting from the PHP configuration.
This timeout handling also introduces a new filter: action_scheduler_maximum_execution_time. This filter expects an integer value which represents the number of seconds that Action Scheduler will attempt to account for when executing actions.
There are a number of new hooks available for developers to modify the behavior of Action Scheduler.
-
action_scheduler_store_action_class- Filter the name of the class used to convert a stored action into anActionScheduler_Action. The default classes are based on the action status, as follows: - Pending action:
ActionScheduler_Action - Canceled action:
ActionScheduler_CanceledAction - Completed action:
ActionScheduler_FinishedAction -
action_scheduler_stored_action_instance- The instantiated object based on the class determined by the action_scheduler_store_action_class filter. -
action_scheduler_list_table_column_args- Filter the "args" column in the admin list table for scheduled actions. This allows modification to the HTML that is generated for each action in this column. -
action_scheduler_admin_notice_html- Filter the admin notice when there is an error processing an action using the admin controls. -
action_scheduler_failed_old_action_deletion- Triggered when an old action is deleted, but the deletion fails. -
action_scheduler_maximum_execution_time- The maximum execution time that Action Scheduler needs to work within when processing actions. See explanation above for more details. -
action_scheduler_use_cpu_execution_time- Filter whether to use thegetrusage()function to more accurately calculate execution time. Defaults to true when running on Pantheon, and false everywhere else.
