Cron, Action Scheduler and staging

Module 7: Being found and hosting · Reading time: 10 minutes

Learning objective: After this lesson you can explain how WooCommerce runs tasks in the background, check the scheduled actions and fix them when there are problems, and set up a staging environment for a shop so that no real customers, payments or orders get caught up in it.

Key concepts: WP-Cron, real cron, DISABLE_WP_CRON, Action Scheduler, scheduled actions, pending, complete, failed, clean-up, staging for a shop, test mode of the payment provider, mail off, webhooks, integrations, never restoring the database over production

What happens when nobody is looking

A shop does a lot of work that is not directly tied to a visitor's click:

• cancelling unpaid orders once the time to hold stock has passed (lesson 3.4);
• sending emails after a status change, and webhooks to integrations;
• updating reports and statistics in the admin;
• cleaning up expired sessions and temporary data;
• applying the retention periods from Accounts Privacy (lesson 2.3);
• with subscriptions or accounting integrations: collecting payments and passing on data.

For this, WordPress uses WP-Cron, and WooCommerce adds the Action Scheduler on top. If they do not run properly, you will not notice straight away. You notice it when unpaid orders keep holding stock, reports stay empty or an integration falls days behind.

WP-Cron and real cron

How WP-Cron works and why a real cron job is better is covered in the WordPress course, lesson 6.3: WP-Cron runs on visits, not on a clock, which makes it unreliable with few visitors and a burden with many. The solution: DISABLE_WP_CRON in wp-config.php and a cron job in your hosting panel that runs wp-cron.php every few minutes.

For a shop, this is not an optimisation but a requirement:

• At night, when there are few visitors, unpaid orders still need to be cancelled on time.
• During a busy promotion, you really do not want a heavy background task piggybacking on the page request of a customer who is trying to check out.

At WebOké you create such a task in DirectAdmin under Cron Jobs (DA 15.1, KB 48), with /usr/local/bin/php as the path to PHP; other hosts have a similar cron screen. For a shop, choose an interval of one to five minutes rather than ten. A task that runs every minute and has nothing to do costs almost nothing.

Action Scheduler: the WooCommerce queue

The Action Scheduler is a queue for background tasks that ships with WooCommerce and is also used by many other plugins (subscriptions, accounting integrations, email marketing). Each task is an action with a time and a status. The queue is processed by a WP-Cron task (action_scheduler_run_queue), so the same applies here: without reliable cron, the queue falls behind.

You can see everything under WooCommerce > Status > Scheduled Actions. There is a tab for each status:

According to the source code, the Action Scheduler cleans up complete and canceled actions after one month by default, and failed ones after three months. If the table still grows quickly, there are probably many actions that keep failing or keep being created; find out which plugin creates them (the Group column and the name of the hook help) instead of just emptying the table.

A real-life example at Theehuis Example: after a password change, the integration with the accounting software put every order in the queue as a failed action. After a week there were 400 failed actions and 60 invoices were missing (lesson 5.6). After fixing the integration, the administrator could run the actions again one by one with Run.

Staging for a shop

What staging is, how to create a staging site and how to shield it (password, noindex) is covered in the WordPress course, lesson 8.3. At WebOké you can do this by cloning in Installatron (DA 13.7, KB 232) and with a password-protected directory (DA 15.9); other hosts have similar tools. For a shop, a few things come on top of that, because a copy of a shop contains real customer data and can carry out real actions.

Straight after cloning, before you do anything else:

1. Payment provider in test mode, with test keys. A staging site with live keys can receive real payments or issue refunds.
2. Mail off or redirected. Otherwise a copy sends confirmations, reminders and abandoned cart emails to real customers. Use a plugin that blocks all mail or sends it to a single test address.
3. Integrations and webhooks off. Accounting, stock synchronisation, shipping labels, email marketing: otherwise staging books invoices or ships parcels. Also check WooCommerce > Settings > Advanced > Webhooks and the API keys.
4. Review scheduled actions. The queue was copied too. Otherwise pending actions (a reminder email, a subscription payment) will run a second time on staging.
5. Limit personal data. If you do not need real customer data for testing, delete or anonymise it on staging. A staging site falls under the GDPR and is often less well secured (lesson 5.5).

And the most important rule when restoring: never put the staging database over a live shop. Between cloning and restoring, orders, customers, stock changes and payments have been added; you would lose them. Repeat your changes on production (you now know they work), or synchronise only the files. If it really has to include the database, do it only with the shop in maintenance mode, straight after a fresh backup, and with a tool that skips orders and customers.

Testing an update on staging

A typical route for a major update of WooCommerce or a payment plugin:

1. Create a fresh staging site (a clone of production) and sort out the five points above.
2. Update on staging and run the database update if WooCommerce asks for it.
3. Place a test order in test mode: payment, failure, refund (lesson 4.5).
4. Check Scheduled Actions and the error log for new errors.
5. Then update production at a quiet moment, with a backup just before (lesson 6.2).

Summary

• WooCommerce does a lot of work in the background; this runs through WP-Cron and the Action Scheduler.
• For a shop, always use a real cron job (every one to five minutes) instead of WP-Cron on visits.
• Check WooCommerce > Status > Scheduled Actions: lots of overdue pending or failed actions are a sign that cron or an integration is not working.
• On staging: payment provider in test mode, mail and integrations off, review scheduled actions, limit personal data.
• Never put a staging database over a live shop; repeat your changes on production.

Quiz

Exercise

Exercise A7.3: Is your staging site shielded? This is the same check as exercise A8.3 of the WordPress course. First you need proof of ownership for your domain (a TXT record _weboke-cursus.<domein> or a file /.well-known/weboke-cursus-<code>.txt containing the code you are given). Then enter the address of your shop and the address of your staging site (a host under the same domain). The program requests the home page of the staging site, without login details, and that of production. Green if the staging site asks for a password (401), or if it has noindex and uses its own address (the REST entry point points to the staging host), while production has no noindex. Orange if the staging site does have noindex but no password, or no valid certificate. Red if the staging site is open and indexable, if the staging site still points to the production address, or if production has noindex by mistake.

Questions for yourself (not checked): is the payment provider on your staging site in test mode? Is mail off or redirected? Have integrations and webhooks been switched off? How many pending and failed actions are there right now under Scheduled Actions on production?

Further reading

These articles describe the steps in the WebOké panels; other panels work in a similar way.

• DirectAdmin guide 15.1: Cron Jobs: running tasks automatically
• Creating a cron job or task (and what to do if it isn't running)
• Creating a WordPress staging environment
• DirectAdmin guide 13.7: Cloning and creating a staging environment
• DirectAdmin guide 15.9: Password Protected Directories
• Free WordPress course 8.3: Staging: testing safely
• Free WordPress course 6.3: Images, PHP and other speed gains
• Action Scheduler (actionscheduler.org): https://actionscheduler.org/