woocommerce/action-scheduler

A scalable, traceable job queue for background processing large queues of tasks in WordPress. Specifically designed for distribution in WordPress plugins (and themes) - no server access required.

WooCommerce Monorepo

Welcome to the WooCommerce Monorepo on GitHub. Here you can find all of the plugins, packages, and tools used in the development of the core WooCommerce plugin as well as WooCommerce extensions. You can browse the source, look at open issues, contribute code, and keep tracking of ongoing development.

We recommend all developers to follow the WooCommerce development blog to stay up to date about everything happening in the project. You can also follow @DevelopWC on Twitter for the latest development updates.

Getting Started

To get up and running within the WooCommerce Monorepo, you will need to make sure that you have installed all of the prerequisites.

Prerequisites

• NVM: While you can always install Node through other means, we recommend using NVM to ensure you're aligned with the version used by our development teams. Our repository contains an .nvmrc file which helps ensure you are using the correct version of Node.
• PNPM: Our repository utilizes PNPM to manage project dependencies and run various scripts involved in building and testing projects.
• PHP 7.4+: WooCommerce Core currently features a minimum PHP version of 7.4. It is also needed to run Composer and various project build scripts. See troubleshooting for troubleshooting problems installing PHP.
• Composer: We use Composer to manage all of the dependencies for PHP packages and plugins.

Once you've installed all of the prerequisites, you can run the following commands to get everything working.

# Ensure that you're using the correct version of Node
nvm use
# Install the PHP and Composer dependencies for all of the plugins, packages, and tools
pnpm install
# Build all of the plugins, packages, and tools in the monorepo
pnpm build

At this point you are now ready to begin developing and testing. All of the build outputs are cached running pnpm build again will only build the plugins, packages, and tools that have changed since the last time you ran the command.

Check out our development guide if you would like a more comprehensive look at working in our repository.

Repository Structure

• Plugins: Our repository contains plugins that relate to or otherwise aid in the development of WooCommerce.
  • WooCommerce Core: The core WooCommerce plugin is available in the plugins directory.
• Packages: Contained within the packages directory are all of the PHP and JavaScript provided for the community. Some of these are internal dependencies and are marked with an internal- prefix.
• Tools: We also have a growing number of tools within our repository. Many of these are intended to be utilities and scripts for use in the monorepo, but, this directory may also contain external tools.

Reporting Security Issues

To disclose a security issue to our team, please submit a report via HackerOne here.

Support

This repository is not suitable for support. Please don't use our issue tracker for support requests, but for core WooCommerce issues only. Support can take place through the appropriate channels:

• If you have a problem, you may want to start with the self help guide.
• The WooCommerce.com premium support portal for customers who have purchased themes or extensions.
• Our community forum on wp.org which is available for all WooCommerce users.
• The Official WooCommerce Facebook Group.
• For customizations, you may want to check our list of WooExperts or Codeable.

NOTE: Unfortunately, we are unable to honor support requests in issues on this repository; as a result, any requests submitted in this manner will be closed.

Community

For peer to peer support, real-time announcements, and office hours, please join our slack community!

Contributing to WooCommerce

As an open source project, we rely on community contributions to continue to improve WooCommerce. To contribute, please follow the pre-requisites above and visit our Contributing to Woo doc for more links and contribution guidelines.

action-scheduler's Issues

Add API for querying multiple scheduled tasks

Add a new method, named something like next_scheduled_tasks() or perhaps get_scheduled_tasks(), to find multiple tasks and allow for advanced queries, like “page 3 of jobs with hook x”.

It should accept an $args param that works similar to that of the get_posts() function.

<?php
$args = array(
    'hook'              => '',              // optional hook to filter the results on
    'args'              => array(),         // optional args to filter by
    'group'             => '',              // optional group to filter the results on
    'post_status'       => 'publish',       // optional status to filter the results on
    'tasks_per_page'    => 5,               // tasks to include
    'offset'            => 0,               // number of tasks to pass over
    'orderby'           => 'scheduled_date',// the field to order by, defaults to the date the task is scheduled to run (but could also be the date is was created, or the date is *was* run for completed tasks)
    'order'             => 'DESC',
?>

To add this API function will likely require the addition of a new TaskScheduler_JobStore::find_jobs() function underneath.

Add composer support

see #72 -- just add a composer.json in your root

Issues with using a CPT for the claim

A claim is created every time the scheduler is run (i.e. every minute) regardless of whether any actions need to run or not.

With the new claim system introduced with SHA: ada818f, that means even if no actions are scheduled on a site, the new system will still use > 500,000 post IDs per year.

I already anticipate customers asking me why their post IDs are increasing so quickly because of scheduled action's using up IDs, I'd hate to add this to the mix!

There is also a bug in ActionScheduler_wpPostStore::release_claim() - it only deletes the claim if actions were actually claimed. That means if there is a period of 5 minutes or more in which no actions are scheduled, the scheduler locks up completely and stops processing queues. This is a simple bug rather than a larger issue with using a CPT though.

You mentioned in #17 the performance advantages in using post_parent instead of post_password, but I'm not sure those improvements justify the downside of this new system (i.e. ravenous consumption of post IDs).

I will be submitting Subscriptions 1.5 for release this week but won't be including SHA: ada818f or SHA: 05f2871 in the code for this reason.

On that note, Subs 1.5 is the first version to go public with the new Action Scheduler, meaning it will be rolled out to thousands of sites over the next couple of weeks - the true test! :)

Update admin view to use data stores

When introducing the admin view with SHA: cbe65a2, I leveraged WordPress's code for creating a list table for a custom post type. That was the quickest way to make an admin view available. However, that meant the admin view was tightly coupled to the built-in data store. One of the great design decisions of Action Scheduler was to abstract the data store.

Now that highly scalable custom tables are coming to Action Scheduler, the core admin view needs to be updated to use the data store.

To this will require:

• Create new list table for scheduled actions which sources data from the data store/public APIs
• Implement feature parity with the existing list table, including:
  • Display the same columns and content
  • Filter actions by status
  • View log entries (the UI for this could be changed to provide a better UX, specifically by avoiding an additional page load just for a few rows of data. A JS popup opening the log in a lightbox like dialog would be better.)
  • Display claim ID for actions with a claim (like in-progress or completed actions
  • Search for scheduled actions by: hook name or arguments (like a subscription ID)
  • Sort scheduled actions by hook name, scheduled, start or completed date, claim ID or number of log entries
  • Allow actions to be Run or _Trash_ed via the inline actions, e.g. https://cl.ly/0k011i0N1f3H
• Move table to new tab under WooCommerce > System Status page rather than Tools menu, this wasn't previously possible with the way WC requires tabs to be setup, but it should be possible once we have our own list table. S#29 for background.

Scaling

Ran my first scaling test last night. The outline:

Environment: OS X 10.9, Apache 2.2.24, PHP 5.4.17, 196M memory limit

1. Created approximately 1M actions in the queue. 20K were already due, with another 100 coming due every minute.
2. Started one WP Cron process, waited five minutes, then started another.

Observations:

• Action Scheduler processes the queue in batches of 10. Running the queries to prepare each batch (i.e., locking the actions to avoid collisions) would take about 4s per batch.
• Each batch was typically 10-12s from start to finish, with most of the time spent waiting for MySQL.
• With each batch, the memory footprint increased about 50K. Eventually, the process reaches the memory limit and dies. (The code does account for this and other fatal errors. The actions will be run by the next process that comes along.)
• After about 10 hours, the original 20K actions, plus about 10K more, had been processed. A rate of about 50 / minute. Since another 100 were coming due every minute, the backlog had increased to about 50K actions.

Conclusions:

• Most of the memory usage is likely coming from WordPress's cache. It would make sense to flush it (or certain parts of it) regularly while processing the queue.
• SQL queries are too slow. I should see what can be done to make better use of pre-existing indexes for more efficient queries (e.g., using post_date instead of post_date_gmt).
• Overall, the system works at scale, though it could benefit from the above optimizations. For any given server, there is a threshold where it is unable to process its workload quickly enough to keep up with incoming jobs.

Invalid `post_content` causes all jobs to fail

I came across a situation where there was an invalid entry in the post_content of a scheduled action caused the entire do_batch process to quit.

I have not been able to recreate what caused the issue in the first place in my dev environment, but somehow the post_content field (which is a serialized array) ended up being improperly encoded and the trailing quote to close the array ended up as a " instead of a ". Ex:

["This is an invalid value "]

Regardless, it would seem to be better if the scheduler reaches an invalid entry it is able to continue processing the remaining events rather than stopping all processing.

Fatal error if timestamp passed to datetime is accidentally a float and not an integer

This is not really a bug in Action Scheduler but it's an interesting one, you might want to evaluate whether to introduce some type casting to help preventing it.

I had a case where the timestamp was calculated as a median between two timestamps (a + b) / 2. This resulted in a timestamp ending in a .5 which generated the error DateTime::__construct(): Failed to parse time string (@1497950844.5) at position 12 (5): Unexpected character

Full stack below:

 DateTime::__construct(): Failed to parse time string (@1497950844.5) at position 12 (5): Unexpected character - /srv/www/skyverge/htdocs/wp-content/plugins/woocommerce-memberships/lib/prospress/action-scheduler/functions.php:183 
#13 /srv/www/skyverge/htdocs/wp-content/plugins/woocommerce-memberships/lib/prospress/action-scheduler/classes/ActionScheduler_ActionFactory.php:16 - as_get_datetime_object(1497950844.5)
#12 /srv/www/skyverge/htdocs/wp-content/plugins/woocommerce-memberships/lib/prospress/action-scheduler/functions.php:18 - ActionScheduler_ActionFactory->single('wc_memberships...', Array[1], 1497950844.5, 'woocommerce-me...')
#11 /srv/www/skyverge/htdocs/wp-content/plugins/woocommerce-memberships/includes/class-wc-memberships-user-membership.php:730 - wc_schedule_single_action(1497950844.5, 'wc_memberships...', Array[1], 'woocommerce-me...')
#10 /srv/www/skyverge/htdocs/wp-content/plugins/woocommerce-memberships/includes/class-wc-memberships-user-membership.php:335 - WC_Memberships_User_Membership->schedule_expiration_events(1497974400)
#9 /srv/www/skyverge/htdocs/wp-content/plugins/woocommerce-memberships/include…dmin/meta-boxes/class-wc-memberships-meta-box-user-membership-data.php:581 - WC_Memberships_User_Membership->set_end_date('2017-06-20 16:...')
#8 /srv/www/skyverge/htdocs/wp-content/plugins/woocommerce-memberships/includes/admin/meta-boxes/abstract-wc-memberships-meta-box.php:658 - WC_Memberships_Meta_Box_User_Membership_Data->update_data(6312, WP_Post)
#7 /srv/www/skyverge/htdocs/wp-includes/class-wp-hook.php:300 - WC_Memberships_Meta_Box->save_post(6312, WP_Post)
#6 /srv/www/skyverge/htdocs/wp-includes/class-wp-hook.php:323 - WP_Hook->apply_filters(NULL, Array[3])
#5 /srv/www/skyverge/htdocs/wp-includes/plugin.php:453 - WP_Hook->do_action(Array[3])
#4 /srv/www/skyverge/htdocs/wp-includes/post.php:3510 - do_action('save_post', 6312, WP_Post, true)
#3 /srv/www/skyverge/htdocs/wp-includes/post.php:3583 - wp_insert_post(Array[67], false)
#2 /srv/www/skyverge/htdocs/wp-admin/includes/post.php:378 - wp_update_post(Array[65])
#1 /srv/www/skyverge/htdocs/wp-admin/post.php:193 - edit_post()

I can easily rectify this by casting the float resulting from the median into an integer. I was wondering if you'd prefer to harden Action Scheduler as well to prevent these cases from ever showing. Feel free to close as well.

Cheers!

MYSQL Unsafe Statement Warning.

Hi there,

Getting the following warning msg from MYSQL when running wp-cron every 30 seconds.
Here's the out output from /var/log/syslog:

Oct 5 13:27:01 mysite CRON[7843]: (root) CMD (curl https://mysite.example.com/wp-cron.php > /dev/null 2>&1) Oct 5 13:27:01 mysite CRON[7844]: (root) CMD (( sleep 30; curl https://mysite.example.com/wp-cron.php > /dev/null 2>&1 )) Oct 5 13:27:31 mysite mysqld: 2016-10-05 13:27:31 140383028554496 [Warning] Unsafe statement written to the binary log using statement format since BINLOG_FORMAT = STATEMENT. The statement is unsafe because it uses a LIMIT clause. This is unsafe because the set of rows included cannot be predicted. Statement: UPDATE wp_posts SET post_password = '5b7d94922c5f856fe2a1', post_modified_gmt = '2016-10-05 13:27:31', post_modified = '2016-10-05 13:27:31' WHERE post_type = 'scheduled-action' AND post_status = 'pending' AND post_password = '' AND post_date <= '2016-10-05 13:27:31' ORDER BY menu_order ASC, post_date ASC LIMIT 25

Querying for subscription key and user id is not good enough

There are a number of really vexing issues with it. Consider this function call:

$actions = wc_get_scheduled_actions( array(
    'args' => array(
        'user_id' => '3',
        'subscription_key' => '202_200'
    ),
    'hook' => 'scheduled_subscription_expiration'
) );

The resulting SQL query here: https://github.com/Prospress/action-scheduler/blob/master/classes/ActionScheduler_wpPostStore.php#L296 will be the following:

SELECT p.ID
FROM wp_posts p
WHERE post_type='scheduled-action'
    AND p.post_title='scheduled_subscription_expiration'
    AND p.post_content='{\"subscription_key\":\"202_200\",\"user_id\":\"3\"}'
ORDER BY p.post_date ASC LIMIT 0, 5;

The problem? It's the wrong way around! This is stored in the database:

But okay, let's switch it, so now the function call is:

$actions = wc_get_scheduled_actions( array(
    'args' => array(
        'user_id' => '3',
        'subscription_key' => '202_200',
    ),
    'hook' => 'scheduled_subscription_expiration'
) );

The resulting query is:

SELECT p.ID
FROM wp_posts p
WHERE post_type='scheduled-action'
    AND p.post_title='scheduled_subscription_expiration'
    AND p.post_content='{\"user_id\":\"3\",\"subscription_key\":\"202_200\"}'
ORDER BY p.post_date ASC LIMIT 0, 5;

Still not good.

The user ID is stored as a number, but json_encode here: https://github.com/Prospress/action-scheduler/blob/master/classes/ActionScheduler_wpPostStore.php#L227 turns user_id into a string. It will never match it.

Issues with ununsanitized data creating invalid serialized data.

The action scheduler does not seem to handle unsanitized data very gracefully.

Example:

wc_schedule_single_action( time(), 'test_schedule_out', array( 'test <3' ) );

This will create an entry with a post title of:

["test <3"]

So it replaces the final quote with a sanitized value, and makes the serialized array invalid.

Switching to calling sanitize_text_field beforehand works:

wc_schedule_single_action( time(), 'test_schedule_out', array( sanitize_text_field('test <3') );

["test <3"]

Duplicate action scheduled after processing an action that was originally scheduled when PHP's timezone was being incorrectly changed to be in the past

When scheduling a single action:

1. wc_schedule_single_action() calls
2. ActionScheduler_ActionFactory::single(), which
3. creates an instance of ActionScheduler_SimpleSchedule, then sends that to
4. new ActionScheduler_Action() as the action's schedule
5. ActionScheduler_ActionFactory::store() then calls
6. ActionScheduler_wpPostStore::save_action() which calls
7. ActionScheduler_wpPostStore::save_post_schedule() which stores a serialized version of this schedule object in post meta with the meta key '_action_manager_schedule'
8. because the ActionScheduler_SimpleSchedule uses a timestamp to store its date value, when the timezone has changed, the timestamp's value is effectively corrupted (FWIW, based on the comments on ActionScheduler_SimpleSchedule::__sleep(), it looks like this issue could be simply because of PHP 5.2 compatibility… because otherwise ActionScheduler_SimpleSchedule::$date would be serialised, which includes the timezone, instead of saving/loading a timestamp, which doesn't)
9. Later on, when ActionScheduler_QueueRunner runs the action via ActionScheduler_QueueRunner::process_action(), it calls
10. ActionScheduler_QueueRunner::schedule_next_instance(), which checks for a next scheduled time using $action->get_schedule()->next( as_get_datetime_object() ); however,
11. ActionScheduler_SimpleSchedule::next( $after ) will return the _action_manager_schedule value if it’s < the $after param, and because ActionScheduler_QueueRunner::schedule_next_instance() passes the current (UTC) time as the $after param, whenever the _action_manager_schedule value is < the current time, a new action will be rescheduled, which means
12. If the timezone has been changed to result in a UTC timestamps being less, a duplicate action will always be scheduled

Example _action_manager_schedule Value

O:30:"ActionScheduler_SimpleSchedule":1{s:41:"ActionScheduler_SimpleScheduletimestamp";s:10:"1480682770";}

Possible Fixes

1. change the $next = $action->get_schedule()->next( as_get_datetime_object() ) call to check against the scheduled time with something like: $next = $action->get_schedule()->next( $action->get_schedule()->next() ) (the issue is that we're currently checking against the current time, which causes problems when the timezone has been changed. It feels redundant, but it looks like the only way to have “control” over the comparisons used, anything else, and we’re comparing to a date/time in a different timezone if the timezone is changed). This will likely break actions which actually having a recurring schedule.
2. just don’t give single actions a schedule (the next() function feels meaningless on a single action), but I’m 99% sure this will break other things

Update 7 December: I realised @mattallan identified this exact issue during the initial timezone PR review: #43 (comment)

Disable cron after continew execute action schedule.

define( 'DISABLE_WP_CRON', true );
I have applied this setting in wp-config.php (localhost - xampp ) But action schedule working continue for recurring schedule.

WP 4.3 changed row actions, and thus extra actions show up

Moved from https://github.com/Prospress/woocommerce-subscriptions/issues/619

Additional hooks

Any specific hooks you'd like to see in the system?

There are a few right now for the logging system, but if you want to hook in elsewhere, let us know.

Scope of sheduled actions

Hey, I'm testing out using action-scheduler to schedule actions that depend on certain WooCommerce classes (e.g. mails). The actions fail with unexpected shutdown: PHP Fatal error Class ‘WC_Email’ ... type errors.

What is the scope of actions executed? If I want to access WooCommerce functions (like get products and get orders etc) do I need to manually import all of WooCommerce within the action that I hook into?

Thanks!

scheduler create four pending schedule action when i run single time.

hello

i have just installed action scheduler plugin and simply run the following code but my problem is that , i can see database post table there are four entry for same action ?

$action_hook="next_payment_membership"; $action_args = array( 'post_id' => "123" ); $next_payment_date = date( 'Y-m-d H:i:s',strtotime('+1 year')); wc_schedule_single_action( $next_payement_date,$action_hook, $action_args );

please suggest me ?

Fatal error: Call to undefined function wc_next_scheduled_action()

I am using action_scheduler_initialize_1_dot_4_dev from the bleeding branch. In fact, I even tried the action-scheduler directory from the Subscriptions 2.0 beta as well, but I still got the Fatal error: Call to undefined function wc_next_scheduled_action() error. I reviewed the following issues:

#35
#37

I did try using $this->versions[$version_string] = call_user_func( $initialization_callback ); rather than $this->versions[$version_string] = $initialization_callback;, as that made sense, however, the fatal error persisted.

https://github.com/Prospress/action-scheduler/blob/master/classes/ActionScheduler_Versions.php#L18

Then I went back into action-scheduler.php thinking perhaps it was just a hook timing issue.

https://github.com/Prospress/action-scheduler/blob/master/action-scheduler.php#L25

I changed:

    function action_scheduler_initialize_1_dot_4_dev() {
        require_once('classes/ActionScheduler.php');
        ActionScheduler::init( __FILE__ );
    }

to

    require_once('classes/ActionScheduler.php');
    ActionScheduler::init( __FILE__ );

This allowed the required ActionScheduler.php file to load, despite whatever issue exists along the chain, and the fatal error disappeared. If I get a chance, I will do some additional troubleshooting to find the exact issue, but the fact action_scheduler_initialize_1_dot_4_dev() is not being called is the issue. I tested the above on PHP version 5.3.29, 5.4.42, and 5.5.26, and the results were always the same. This issue should not be closed until it is resolved.

Earlier than expected timeout on hhvm

My setup:
Nginx -> HHVM via fastcgi socket
DISABLE_WP_CRON set to true and a real cron job using wget to get wp-cron.php every 5 minutes.

In the code I see two timeouts; an internal five_minutes (by default) timeout and an actual process limit of 10 minutes (by default) passed to set_time_limit for the entire process. So I assume jobs still running after 5 minutes that are marked as timed-out internally may still complete within another 5 minutes.

I have a lot of actions scheduled for the same time every night (3am... typically all are completed by around 5 am) But I see various scheduled actions fail. When checking back in the logs I see the following message immediately after a slow query log related to the action:

Fatal error: entire web request took longer than 120 seconds and timed out

I have googled around whether HHVM respects the set_time_limit defined by the process and I can see no one saying it doesn't but I cannot work out where the 120 second timeout would be coming from. HHVM docs say hhvm.server.request_timeout_seconds default is to not timeout... but who knows... I also haven't looked at fastcgi or nginx config changes as I am assuming the wp-cron ignore_user_abort(true) setting would mean any termination of the connection from a fastcgi timeout or nginx setting would get ignored by the process anyway - but perhaps I'm wrong on that assumption

Admin UI for Interacting with Scheduled Tasks

It would be tremendously helpful to provide an admin interface for viewing and testing scheduled tasks. Something like the one used by the WP Crontrol plugin for WP-Cron.

It should be hidden unless WP_DEBUG is set to avoid adding unnecessary menu item.

Todos:

• fix restoring trashed action
• add comments/log notes for each row

Failure Handling

In ActionScheduler::runner()->process_action(), even if an exception occurs when executing the action ($action->execute()), the action is marked as complete (i.e. post_status = 'publish'). I think it should actually receive a new status of 'failed'. This is a more accurate indication of what happened when it was executed. The exception should also be logged on the action.

Going further, if a fatal error occurs while processing callbacks on an action, it should be caught and logged on the action. This can be done using the 'shutdown' hook in WordPress (and some hackery attaching a function to 'shutdown' on the 'action_scheduler_before_execute' hook then removing that function with the 'action_scheduler_after_execute' hook).

Custom Action Scheduler database tables

For scalability, we need to move Action Scheduler away from using a Custom Post Type datastore, to a highly scalable new schema in custom tables. To do this at a high level requires:

• determine a new, highly scalable database schema
• implement a new data store to interact with that new schema
• include database migration paths for both WP CLI and standard WordPress
• create a feature plugin for testing prior to merge/release in Action Scheduler core: https://github.com/Prospress/action-scheduler-custom-tables/ (requires PHP 5.6)
• merge code into Action Scheduler v3.0 for release

---

For current progress, see the this repo: https://github.com/Prospress/action-scheduler-custom-tables/

Move the Admin Screen to WooCommerce System Status section

Under a new "Scheduled Actions" tab that always displays, regardless of whether WP_DEBUG or WCS_DEBUG are set.

`wp_unique_post_slug()` overhead on large sites

Keeping this short and sweet, more as a note / for documentation.

wp_unique_post_slug() is called on some action scheduler related wp-cron.php calls when actions are marked complete etc.

On sites with a large number of items in the posts table this adds a substantial overhead e.g.

Looks like its bit of a known bottleneck for large sites http://wordpress.stackexchange.com/questions/119738/can-we-have-a-post-without-a-slug

As the actions aren't really public, calculating a slug/name is not really necessary.

Unfortunately there is no easy way to get around it as it is used within wp_update_post() e.g. https://github.com/Prospress/action-scheduler/blob/master/classes/ActionScheduler_wpPostStore.php#L563 and the only filters within in are at the end

An action or filter at the beginning around here would potentially allow us to hijack and ignore what happens after.

This trak ticket may or may not be useful/interesting. Its certainly related.

For more discussion see https://github.com/Prospress/woocommerce-subscriptions/issues/1355

Post Author

When an action is scheduled via a request with an authenticated user (which will happen quite a bit), the post author is set to that user’s ID.

When an action is created by a non-authenticated request (like an aysnc request triggered by WP-Cron), the post’s author ID is set to 0.

I think it should probably always be 0 to both be consistent and ensure there aren't capabilities issues down the line.

Recurring Action Status

After a recurring action has been executed, it is rescheduled with the status future rather than the pending status used for other scheduled actions: http://cl.ly/image/2e3B3I3S1N0Y

Merge Bleeding Branch into Master

At the moment, Subscriptions and other plugins using Action Scheduler use the bleeding_branch. THis has diverged from master.

Specifically:

• the bleeding_branch includes the important Admin UI while
• the master branch includes an improvement to the way actions are claimed/locked

We want to take advantage of both of these improvements, but the new claiming system needs extremely thorough testing before it can be released into the wild (otherwise we may end up with duplicate payments in Subscriptions). I did hope to do this as part of Subscriptions v2.0 dev cycle, but after it went way over schedule, it was tentatively pushed back (most likely to be part of Subscriptions v2.1 dev cycle).

A changeset close to what we want can be found here: https://github.com/Prospress/action-scheduler/tree/bleeding_merge_master

That merges the new claiming system from master with the admin UI and other minor tweaks in bleeding_branch.

That branch isn't something we'll push out in a minor release (which is why there is no PR for it yet). It's something that will likely be merged just before v2.1 hits beta, and then tested for weeks before it is released.

Catchable fatal error

I'm not sure exactly what is going on with this. I'm leaning towards some data issues at this point since I've been as this issue for a little bit now. This is all in a local dev environment obviously, but curious on any thoughts.

@thenbrent requested me to put this into this repo.

Error:
Catchable fatal error: Argument 3 passed to ActionScheduler_Action::__construct() must be an instance of ActionScheduler_Schedule, instance of __PHP_Incomplete_Class given, called in /code/wp-content/plugins/woocommerce-subscriptions/includes/libraries/action-scheduler/classes/ActionScheduler_wpPostStore.php on line 123 and defined in /code/wp-content/plugins/woocommerce-subscriptions/includes/libraries/action-scheduler/classes/ActionScheduler_Action.php on line 13 Call Stack: 0.0022 269840 1. {main}() /code/wp-admin/edit.php:0 0.6517 52877488 2. WP_List_Table->display() /code/wp-admin/edit.php:357 0.6554 52912816 3. WP_List_Table->display_rows_or_placeholder() /code/wp-admin/includes/class-wp-list-table.php:1141 0.6554 52912920 4. WP_Posts_List_Table->display_rows() /code/wp-admin/includes/class-wp-list-table.php:1213 0.6554 52915832 5. WP_Posts_List_Table->_display_rows() /code/wp-admin/includes/class-wp-posts-list-table.php:644 0.6557 52925224 6. WP_Posts_List_Table->single_row() /code/wp-admin/includes/class-wp-posts-list-table.php:662 0.6569 52929680 7. WP_List_Table->single_row_columns() /code/wp-admin/includes/class-wp-posts-list-table.php:1185 0.6577 52933184 8. WP_Posts_List_Table->column_default() /code/wp-admin/includes/class-wp-list-table.php:1305 0.6577 52933512 9. do_action() /code/wp-admin/includes/class-wp-posts-list-table.php:1152 0.6577 52934272 10. WP_Hook->do_action() /code/wp-includes/plugin.php:453 0.6577 52934368 11. WP_Hook->apply_filters() /code/wp-includes/class-wp-hook.php:323 0.6577 52935656 12. call_user_func_array:{/code/wp-includes/class-wp-hook.php:298}() /code/wp-includes/class-wp-hook.php:298 0.6577 52936432 13. ActionScheduler_AdminView->list_table_column_content() /code/wp-includes/class-wp-hook.php:298 0.6577 52936624 14. ActionScheduler_wpPostStore->fetch_action() /code/wp-content/plugins/woocommerce-subscriptions/includes/libraries/action-scheduler/classes/ActionScheduler_AdminView.php:165 0.6578 52937304 15. ActionScheduler_wpPostStore->make_action_from_post() /code/wp-content/plugins/woocommerce-subscriptions/includes/libraries/action-scheduler/classes/ActionScheduler_wpPostStore.php:99 0.6605 53165656 16. ActionScheduler_Action->__construct() /code/wp-content/plugins/woocommerce-subscriptions/includes/libraries/action-scheduler/classes/ActionScheduler_wpPostStore.php:123

Here's the System Status Report
`

WordPress Environment

Home URL: https://counter-culture-grow.kbox.site
Site URL: https://counter-culture-grow.kbox.site
WC Version: 2.6.14
Log Directory Writable: ✔
WP Version: 4.7.5
WP Multisite: –
WP Memory Limit: 512 MB
WP Debug Mode: ✔
WP Cron: ✔
Language: en_US

Server Environment

Server Info: nginx/1.8.1
PHP Version: 5.6.30
PHP Post Max Size: 100 MB
PHP Time Limit: 90
PHP Max Input Vars: 10000
cURL Version: 7.38.0
OpenSSL/1.0.1t

SUHOSIN Installed: –
Max Upload Size: 100 MB
Default Timezone is UTC: ✔
fsockopen/cURL: ✔
SoapClient: ✔
DOMDocument: ✔
GZip: ✔
Multibyte String: ✔
Remote Post: ✔
Remote Get: ✔

Database

WC Database Version: 2.6.14
:
woocommerce_sessions: ✔
woocommerce_api_keys: ✔
woocommerce_attribute_taxonomies: ✔
woocommerce_downloadable_product_permissions: ✔
woocommerce_order_items: ✔
woocommerce_order_itemmeta: ✔
woocommerce_tax_rates: ✔
woocommerce_tax_rate_locations: ✔
woocommerce_shipping_zones: ✔
woocommerce_shipping_zone_locations: ✔
woocommerce_shipping_zone_methods: ✔
woocommerce_payment_tokens: ✔
woocommerce_payment_tokenmeta: ✔
MaxMind GeoIP Database: ✔

Active Plugins (60)

Gravity Forms: by rocketgenius – 2.2.3
Native PHP Sessions for WordPress: by Pantheon – 0.6.1
404page - your smart custom 404 error page: by Peter Raschendorfer – 2.5
Advanced Custom Fields PRO: by Elliot Condon – 5.5.14
Better User Search: by Dale Higgs – 1.1.1
CCC Credit Memos: by Julie Spragg - Counter Culture Coffee – 0.1
CCC Shop Manager & Subscription Options: by Julie Spragg – 1.1.0
CCC Disable WP Email: by Kurt Schlatzer - Counter Culture Coffee – 0.1
CCC Disable WP Login Autocomplete: by Kurt Schlatzer - Counter Culture Coffee – 0.1
Kill WP Emojis: by Kurt Schlatzer - Counter Culture Coffee – 0.1
CCC Magento Order History: by – 1.0.0
CCC Order History: by Julie Spragg - Counter Culture Coffee – 0.1
CCC Trimark URL Checkout change: by Julie Spragg - Counter Culture Coffee – 0.1
CCC UPS Settings for West: by Julie Spragg - Counter Culture Coffee – 0.1
Admin Columns: by AdminColumns.com – 3.0
CCC Wholesale Functionality: by Grow Development – 0.0.3
Custom Post Type UI: by WebDevStudios – 1.5.3
Disable Comments: by Samir Shah – 1.6
CCC Eventbrite Plugin: by Julie Spragg – 2.0
Flight by Canto: by Canto Inc – 1.3.2
Gravity Forms MailChimp Add-On: by rocketgenius – 4.2
Heartbeat Control: by Jeff Matson – 1.0.3
HTTP header improved security: by Carl Conrad – 2.0.1
In8Sync Customers: by In8 – 2.1.14
In8Sync Inventory: by In8 – 2.1.14
In8Sync Products: by In8 – 2.1.14
In8Sync Sales Orders: by In8 – 2.1.14
In8Sync - NetSuite WooCommerce Integration: by In8Sync – 2.1.14
Jazzapi: by Julie Spragg – 1.0
Members: by Justin Tadlock – 1.1.3
Pantheon Advanced Page Cache: by Pantheon – 0.1.5
Postman SMTP: by Jason Hendriks – 1.7.2
Relevanssi: by Mikko Saari – 3.5.10
UPS WooCommerce Shipping: by WooForce – 3.7.1
User Switching: by John Blackbourn – 1.0.9
Username Changer: by Daniel J Griffiths – 3.1.0
WooCommerce Subscriptions Remove Deprecation Handlers: by Prospress Inc. – 1.0
PO Field for Orders: by Julie Spragg – 1.0
WooChimp: by RightPress – 2.2.2
WooCommerce Advanced Pricing: by Jeroen Sormani – 1.0.5
WooCommerce AvaTax: by SkyVerge – 1.4.2
WooCommerce Catalog Visibility Options: by Lucas Stark – 3.0.1
WooCommerce Composite Products: by SomewhereWarm – 3.9.4
WooCommerce Conditional Shipping and Payments: by WooThemes – 1.2.5
WooCommerce Authorize.Net CIM Gateway: by SkyVerge – 2.6.3
WooCommerce Grid / List toggle: by jameskoster – 1.1.0
WooCommerce Multiple Customer Addresses: by Lagudi Domenico – 5.2
WooCommerce Shipment Tracking: by WooCommerce – 1.6.6
WooCommerce USPS Shipping: by WooCommerce – 4.4.6
WooCommerce Subscribe All the Things: by Prospress Inc. – 2.0.0-alpha
Subscription Reports for WooCommerce: by StoreApps – 1.8
WooCommerce Subscriptions CSV Importer and Exporter: by Prospress Inc – 2.0-beta
WooCommerce Subscriptions: by Prospress Inc. – 2.2.11
WooCommerce: by WooThemes – 2.6.14
WooCommerce Helper: by WooCommerce – 1.7.2
Yoast SEO Premium: by Team Yoast – 4.8
WP Crontrol: by John Blackbourn & contributors – 1.5
WP-Sweep: by Lester 'GaMerZ' Chan – 1.0.10
Yoast SEO: WooCommerce: by Team Yoast – 4.8
YITH WooCommerce Category Accordion Premium: by YITHEMES – 1.0.16

Settings

Force SSL: ✔
Currency: USD ($)
Currency Position: left
Thousand Separator: ,
Decimal Separator: .
Number of Decimals: 2

API

API Enabled: ✔

WC Pages

Shop Base: #4 - /shop
Cart: #5 - /cart
Checkout: #6 - /checkout
My Account: #7 - /my-account

Taxonomies

Product Types: composite (composite)
grouped (grouped)
simple (simple)

Theme

Name: CCC Theme
Version: 1.0
Author URL: http://counterculturecoffee.com/
Child Theme: ❌ – If you're modifying WooCommerce on a parent theme you didn't build personally
then we recommend using a child theme. See: How to create a child theme

WooCommerce Support: ✔

Templates

Overrides: Your theme has a woocommerce.php file
you will not be able to override the woocommerce/archive-product.php custom template since woocommerce.php has priority over archive-product.php. This is intended to prevent display issues.

Overrides: ccc-theme/woocommerce/archive-product.php
ccc-theme/woocommerce/cart/cart-empty.php
ccc-theme/woocommerce/cart/cart.php
ccc-theme/woocommerce/checkout/form-checkout.php
ccc-theme/woocommerce/checkout/form-shipping.php
ccc-theme/woocommerce/checkout/terms.php
ccc-theme/woocommerce/checkout/thankyou.php
ccc-theme/woocommerce/content-product.php
ccc-theme/woocommerce/content-single-product.php
ccc-theme/woocommerce/emails/admin-cancelled-order.php
ccc-theme/woocommerce/emails/admin-failed-order.php
ccc-theme/woocommerce/emails/admin-new-order.php
ccc-theme/woocommerce/emails/customer-completed-order.php
ccc-theme/woocommerce/emails/customer-invoice.php
ccc-theme/woocommerce/emails/customer-new-account.php
ccc-theme/woocommerce/emails/customer-note.php
ccc-theme/woocommerce/emails/customer-on-hold-order.php
ccc-theme/woocommerce/emails/customer-processing-order.php
ccc-theme/woocommerce/emails/customer-refunded-order.php
ccc-theme/woocommerce/emails/customer-reset-password.php
ccc-theme/woocommerce/emails/email-addresses.php
ccc-theme/woocommerce/emails/email-customer-details.php
ccc-theme/woocommerce/emails/email-footer.php
ccc-theme/woocommerce/emails/email-header.php
ccc-theme/woocommerce/emails/email-order-details.php
ccc-theme/woocommerce/emails/email-order-items.php
ccc-theme/woocommerce/emails/email-styles.php
ccc-theme/woocommerce/emails/plain/admin-cancelled-order.php
ccc-theme/woocommerce/emails/plain/admin-failed-order.php
ccc-theme/woocommerce/emails/plain/admin-new-order.php
ccc-theme/woocommerce/emails/plain/customer-completed-order.php
ccc-theme/woocommerce/emails/plain/customer-invoice.php
ccc-theme/woocommerce/emails/plain/customer-new-account.php
ccc-theme/woocommerce/emails/plain/customer-note.php
ccc-theme/woocommerce/emails/plain/customer-on-hold-order.php
ccc-theme/woocommerce/emails/plain/customer-processing-order.php
ccc-theme/woocommerce/emails/plain/customer-refunded-order.php
ccc-theme/woocommerce/emails/plain/customer-reset-password.php
ccc-theme/woocommerce/emails/plain/email-addresses.php
ccc-theme/woocommerce/emails/plain/email-customer-details.php
ccc-theme/woocommerce/emails/plain/email-order-details.php
ccc-theme/woocommerce/emails/plain/email-order-items.php
ccc-theme/woocommerce/global/quantity-input.php
ccc-theme/woocommerce/loop/loop-start.php
ccc-theme/woocommerce/loop/no-products-found.php
ccc-theme/woocommerce/myaccount/dashboard.php
ccc-theme/woocommerce/myaccount/form-login.php
ccc-theme/woocommerce/myaccount/navigation.php
ccc-theme/woocommerce/single-product/add-to-cart/grouped.php
ccc-theme/woocommerce/single-product/product-image.php
ccc-theme/woocommerce/single-product/product-thumbnails.php
ccc-theme/woocommerce/single-product/short-description.php
ccc-theme/woocommerce/single-product/up-sells.php

subscriptions

WCS_DEBUG: ✔ No
Subscriptions Mode: ✔ Live

Authorize.Net CIM

Environment: Test
Tokenization Enabled: ✔
Debug Mode: Off
`

Action Scheduler comment filtering never caches

According to query debugging, the caching implemented for comments-0 never kicks in.

• https://github.com/Prospress/action-scheduler/blob/master/classes/ActionScheduler_wpCommentLogger.php#L123

This may be due to non-strict comparison of the cached value. I'll provide feedback if/when I look into this further.

Resetting Timeouts

@jbrinley correct me if I'm wrong, but this is how I think part the queue handling works:

1. The 'action_scheduler_run_queue' hook is trigger
2. ActionScheduler_QueueRunner->run() is called
3. ActionScheduler_QueueRunner->run_cleanup() is called
4. As part of the cleanup, ActionScheduler_QueueCleaner->reset_timeouts() is called
5. All the actions which were claimed more than 5 minutes ago but still have a pending status are then unclaimed (i.e. meaning the post_password is restored to '')

If that's the case, then there is potential for duplication.

An action's status is not marked as complete (i.e. publish) until the action has completed processing all the callbacks associated with it. Meaning the action could be both executing in one request and unclaimed then queued in another request before it has finished executing in the other request.

A fairly simple possible solution is to use some sort of 'in-progress' status and set that status before executing the action. That will prevent the query in ActionScheduler_QueueCleaner->reset_timeouts() from including the action in the $actions_to_reset. There will still be potential for a race condition with this solution, but it would be miniscule.

Rename repository

If there are no objections, I would like to rename this repository in github to match the actual project name. After the rename, it will live at https://github.com/flightless/action-scheduler.

Proposed date for the change: March 3.

Foreign key constraint fails: InnoDB & post_author foreign key

Nothing to do here, this is simply to record an issue I encountered.

When attempting to upgrade to Subscriptions 1.5, a customer encountered the following error message:

PHP message: WordPress database error Cannot add or update a child row: a foreign key constraint fails (`wp_posts`, CONSTRAINT `wp_posts_fk` FOREIGN KEY (`post_author`) REFERENCES `wp_users` (`ID`) ON DELETE NO ACTION ON UPDATE NO ACTION)

Specifically, a custom constraint was creating a FOREIGN KEY relationship between the post_author column of wp_posts and the ID column of wp_users.

The issue here is that schedules are published by WordPress, not a user, so the post_author column is set to 0. However, there is no row in wp_users which has ID of 0, and there never can be, meaning that constraint will always fail.

We could do a work around for this issue by creating a dummy user, but 0 is a valid value for the post_author column based on the WordPress database schema. It is also the default value for that column. So I feel the error is in the constraint statement not in Action Scheduler.

The QueueRunner can be bricked because failed actions sometimes aren't unclaimed

So far I have no idea why that happens, but occasionally there are failed actions, irrespective of the post store used, that still have their claim ids intact.

Because the Q runner checks how many distinct claim ids are in the store, and compares that to a predefined number, we can run into a situation where if there are 5 different failed actions from 5 different times with their claim ids still in, the Q runner will not start a new batch.

I think this piece of code is missing an unclaim_action call...

Dublicate Payment generated (2 times).

Your code used in woocommerce_subscription. (I have checked with your latest code action-scheduler)

I have purchase 2 subscription 1191,1993 now recurring payment execute after 1 month.
Issue occurred "1993" number order in created 2 times payment.

http://imgur.com/a/TVjic

This issue occurred when any user 2 subscriptions recurring same time generated.

WooCommerce Authorize.net CIM Gateway 2.0.2
WooCommerce Subscriptions 2.0.18
WooCommerce 2.4.6

how to pass argument

i have a file.php in root wordpress installation it works ok without arguments with your plugin

i have a file2.php in root wordpress installation it requieres argument "device=3000" to work

ex file2.php?device=333333

i have tried with argument device=333333 in argument box but not lucky

please help

luis

PHP7 compatibility, and clone keyword

Moved from https://github.com/Prospress/woocommerce-subscriptions/issues/1510

WPEngine released the php compatibility checker plugin: https://wordpress.org/plugins/php-compatibility-checker/

Running it on Subs produces this:

The 10 errors that the compat plugin picked up:

FILE: /Users/javorszky/Sites/hue/wp-content/plugins/woocommerce-subscriptions/includes/libraries/action-scheduler/classes/ActionScheduler_CronSchedule.php
----------------------------------------------------------------------------------------------------------------------------------------------------------
FOUND 2 ERRORS AFFECTING 1 LINE
----------------------------------------------------------------------------------------------------------------------------------------------------------
 23 | ERROR | 'clone' is a reserved keyword introduced in PHP version 5.0 and cannot be invoked as a function (T_CLONE)
 23 | ERROR | 'clone' is a reserved keyword introduced in PHP version 5.0 and cannot be invoked as a function (T_CLONE)
----------------------------------------------------------------------------------------------------------------------------------------------------------


FILE: /Users/javorszky/Sites/hue/wp-content/plugins/woocommerce-subscriptions/includes/libraries/action-scheduler/classes/ActionScheduler_IntervalSchedule.php
--------------------------------------------------------------------------------------------------------------------------------------------------------------
FOUND 2 ERRORS AFFECTING 2 LINES
--------------------------------------------------------------------------------------------------------------------------------------------------------------
 23 | ERROR | 'clone' is a reserved keyword introduced in PHP version 5.0 and cannot be invoked as a function (T_CLONE)
 28 | ERROR | 'clone' is a reserved keyword introduced in PHP version 5.0 and cannot be invoked as a function (T_CLONE)
--------------------------------------------------------------------------------------------------------------------------------------------------------------


FILE: /Users/javorszky/Sites/hue/wp-content/plugins/woocommerce-subscriptions/includes/libraries/action-scheduler/classes/ActionScheduler_SimpleSchedule.php
------------------------------------------------------------------------------------------------------------------------------------------------------------
FOUND 2 ERRORS AFFECTING 2 LINES
------------------------------------------------------------------------------------------------------------------------------------------------------------
 10 | ERROR | 'clone' is a reserved keyword introduced in PHP version 5.0 and cannot be invoked as a function (T_CLONE)
 20 | ERROR | 'clone' is a reserved keyword introduced in PHP version 5.0 and cannot be invoked as a function (T_CLONE)
------------------------------------------------------------------------------------------------------------------------------------------------------------


FILE: /Users/javorszky/Sites/hue/wp-content/plugins/woocommerce-subscriptions/includes/libraries/action-scheduler/classes/ActionScheduler_wpCommentLogger.php
-------------------------------------------------------------------------------------------------------------------------------------------------------------
FOUND 1 ERROR AFFECTING 1 LINE
-------------------------------------------------------------------------------------------------------------------------------------------------------------
 21 | ERROR | 'clone' is a reserved keyword introduced in PHP version 5.0 and cannot be invoked as a function (T_CLONE)
-------------------------------------------------------------------------------------------------------------------------------------------------------------


FILE: /Users/javorszky/Sites/hue/wp-content/plugins/woocommerce-subscriptions/includes/libraries/action-scheduler/classes/ActionScheduler_wpPostStore.php
---------------------------------------------------------------------------------------------------------------------------------------------------------
FOUND 3 ERRORS AFFECTING 3 LINES
---------------------------------------------------------------------------------------------------------------------------------------------------------
 242 | ERROR | 'clone' is a reserved keyword introduced in PHP version 5.0 and cannot be invoked as a function (T_CLONE)
 251 | ERROR | 'clone' is a reserved keyword introduced in PHP version 5.0 and cannot be invoked as a function (T_CLONE)
 391 | ERROR | 'clone' is a reserved keyword introduced in PHP version 5.0 and cannot be invoked as a function (T_CLONE)
---------------------------------------------------------------------------------------------------------------------------------------------------------

Because clone is a keyword, not a function, therefore:

clone( $date ) ❌
clone $date 💚

Simultaneous Queues & 504 Timeouts

I've managed to get the Action Scheduler to take down all the WordPress sites running on my VPS a few times this week - something I'm quite happy about. :)

If a large enough number of actions are scheduled close enough together, and each batch takes a sufficiently long time to complete, Action Scheduler can fill up all the server's available processes so that any additional requests receive a 504 error.

My test site has batches of 2,000 actions to process roughly at the same time. That means the actions will be processed in a minimum of 20 queues with the default batch size. As each queue starts 1 minute apart, it only takes 10 minutes before 10 independent queues are running. Each action takes just under 2 minutes to process, so that batch isn't cleared for up to 2 minutes after the queue cleaner runs. I allow PHP 10 processes so after 10 minutes, PHP effectively locks up on my server meaning all WP sites go down.

Restricting the number of concurrent batches should fix this. Each batch has a unique claim ID, so it's possible to identify the number of batches and only trigger when that number doesn't exceed a maximum allowed batches.

To patch this, I would:

1. add a new method in ActionScheduler_Store & ActionScheduler_wpPostStore to find the number of claims in effect, named something like get_claim_count()
2. add logic to ActionScheduler_QueueRunner::run() after $this->run_cleanup() to check if $this->store->get_claim_count() is more than apply_filters( 'action_scheduler_queue_runner_concurrent_batches', 5 ) and bail if it is
3. make sure that completed actions do not have a claim ID still set. At the moment, some do, because ActionScheduler_QueueCleaner::reset_timeouts() only resets actions with the ActionScheduler_Store::STATUS_PENDING status. This could be done by either changing ActionScheduler_QueueCleaner::reset_timeouts() to also unclaim actions with the status of ActionScheduler_Store::STATUS_COMPLETE or by calling $this->store->unclaim_action( $action_id ) after each action is successfully processed with the $this->process_action( $action_id ) call in ActionScheduler_QueueRunner::do_batch()

@jbrinley sound OK? If so, I can add the patch as I imagine your time is running thin.

Consider storing schedules in own tables

Ref #45 (comment) and https://prospress.slack.com/archives/wc-subscriptions/p1449870110000096

(screenshot for those without access)

Fatal error

Fatal error: Call to undefined function wc_next_scheduled_action() in ....classes\class-wc-subscriptions-manager.php on line 2256.I am getting this error can you please give me some idea, how I can fix it.

    add_action( 'plugins_loaded', 'action_scheduler_register_1_dot_2_dev', 0, 0 );

    function action_scheduler_register_1_dot_2_dev() {
        echo "test";
        exit;
        $versions = ActionScheduler_Versions::instance();
        $versions->register( '1.2-dev', 'action_scheduler_initialize_1_dot_2_dev' );
    }

This is where the problem is exist .

okay to bundle into a plugin?

Hey there,

This plugin is beautiful! I came across it after reading through some of the WooCommerce Subscriptions codebase (which looks like it was developed by some of the main contributors of this plugin).

I'd like to use the library in LifterLMS but I wanted to ensure this would be acceptable usage according to the developers. I don't see anything in the readme or any existing issues and there's no license.

Thanks,

Migrate existing scheduled actions to custom tables

Figure out how to migrate to the new data stores from #77, taking existing scheduled actions in the old custom post type schema into account.

This could involve either a database migration, and/or running the two data stores side-by-side indefinitely, both of which have pros and cons, so also open to other ideas.

We're also aiming to migrate Subscriptions data to custom tables within 12 months, so it probably makes sense to align that migration. WooCommerce core will also be migrating to custom tables, so there's a few balls to juggle on this item.

Action status gets lost

Actions currently can have 4 (5) statuses:

• pending
• completed
• in-progress
• failed
• (trashed)

When you try to fetch and then resave the actions, it will be either of these two:

• pending
• completed

This is because the ActionScheduler_Action base class has no concept of status, and it's either just not finished, or finished, if the class is extended and overwritten, as is the case with ActionScheduler_FinishedAction. That's all handy, but from a migration point of view absolutely useless, as failed actions would be marked completed.

The question is whether this needs to be amended in the base class, or whether it should be handled in a new compatibility layer on top of the wpPostStore class when saving / fetching actions.

Nomenclature

We need to determine the naming conventions used (both through-out code and in referring to the library).

Pre-amble discussion via email:

From Jonathan:

I still don't know what to call this. Right now the code has a bit
of a jumble, calling things Jobs, Tasks, Events. Thoughts?

From me:

I've been pondering this for a while. My thoughts:

• Job/Task are the most commonly used names, but this system isn't really scheduling a job/task (we're not using the function/object dependency injection used by some systems, like DJJob), it's just scheduling a hook.
• Therefore "Hook" is probably the most correct, but it might not be the most obvious name and is very generic. Something like "schedule_job()" sounds much more obvious than "schedule_hook()". "Action" is similar - we're actually scheduling an action, but "schedule_action()" doesn't feel as obvious as "schedule_task()".
• "Event" is a good compromise, but is taken by WP-Cron already so I think it's out.

Hide scheduler comments on dashboard / comments area

I noticed when testing that comments from the scheduler are showing up on the default WordPress dashboard under the 'Activity' section, and on the Comments admin page. I do not think this is really desirable, and should be hidden from the dashboard view.

Todos

Assorted outstanding todos:

• Purging old jobs from the database
• Retrying failed jobs
• Handling fatal errors from failed jobs
• Tests for scaling

Task Scheduler Frequency

Currently, the frequency of 'task_scheduler_run_jobs' is 'hourly', meaning it will check to see what jobs/tasks are due to run once each hour.

For Subscriptions use case, a much more frequent check is needed, ideally every few seconds. A more practical frequency, without losing too much reliability, would be 2-5 minutes (meaning a subscription payment could be up-to 5 minutes late, which compared to PayPal "any-time within 24 hours" isn't too bad).

This issue is for others extensions to add input to the frequency required by their ideal use case before we decide on a final number (obviously it can also be customised with 'task_scheduler_run_schedule').

Recurring Action Next Date

For any an action of the type ActionScheduler_IntervalSchedule that has been executed once, calling $action->get_schedule()->next() will return the same start date (regardless of the actual next scheduled date and number of successive times the action has been run).

This doesn't really make sense for the 2 ...n iterations of the action. I think the next scheduled date for those actions should be calculated automatically from the last occasion the action was run.

This became quite apparent when creating the Admin Screen and seeing a lot of pending actions with a scheduled date in the past: http://cl.ly/image/2S2h080y2w2a

Action scheduler needs to clean up trashed posts

Related to the work I was doing on Prospress/woocommerce-subscriptions#2246, I noticed that posts with a type of scheduled-action are not deleted when their parent order is deleted. They are marked correctly as trashed. I don't know if these will be cleaned up by the action scheduler or if some code adjustments need to be made.

The screen monitoring in Tool no longer exist

I set the WP_DEBUG and it doesn't display the submenu under tools.

Issues with `timezone_name_from_abbr()`

The timezone_name_from_abbr() function has a bad habit of returning an empty string.

At the moment, timezone_name_from_abbr() has the final say in ActionScheduler_TimezoneHelper::get_local_timezone() so for a number of timezones, this empty string issue will lead to the exception: DateTimeZone::__construct(): Unknown or bad timezone (), which will take down Action Scheduler completely.

To reproduce, just set the site's timezone to -6.

SHA: db6ef9a includes a patch based on this excellent post (you can cherry-pick it or I can make a pull request if you'll merge it as is).

Edit: fix SHA reference

Run scheduler via WP-CLI

Would be great to be able to run the scheduler via WP-CLI and get some better messaging as it processes each task, letting you go through all the tasks in the queue, and telling you how many tasks are left (using progress bar).

For the interim, I've been trying something like:
wp eval "do_action( 'action_scheduler_run_queue' );"

Though I'm not 100% sure if that works.