Allow subscriptions database upgrades on headless sites (was Cron / Action Scheduler processing disabled until manual intervention on update)

[haszari]

Description

There is no way to upgrade the database (when required) on headless sites. For previously required upgrades, they required either manually clicking a button or by a user visiting wp-admin.

Investigation

In upgrader init(), subscriptions upgrader puts a lock on WP cron if the version of subscriptions set in the database is lower than the currently installed version.

This lock is only removed once an upgrade is completed by logging in via wp-admin. This won't cause any issues if the plugin is manually updated. However automatic updates require this manual intervention of logging in before any cron actions will proceed.

https://github.com/Automattic/woocommerce-subscriptions-core/blob/9ac1ae66fc1bc90b1abbfb9791eb880a9148bdda/includes/upgrades/class-wc-subscriptions-upgrader.php#L51-L56

https://github.com/Automattic/woocommerce-subscriptions-core/blob/9ac1ae66fc1bc90b1abbfb9791eb880a9148bdda/includes/upgrades/class-wc-subscriptions-upgrader.php#L132-L141

This could impact other cron jobs and correct cron processing on larger or more complex sites.

Product impact

• [x] Does this issue affect WooCommerce Subscriptions? yes 4343-gh-woocommerce/woocommerce-subscriptions
• [x] Does this issue affect WooCommerce Payments? yes https://github.com/Automattic/woocommerce-payments/issues/4195

p81Rsd-J3-p2#comment-1026 p81Rsd-J3-p2#comment-1025

[brucealdridge]

NB: This issue originally occurred on a "headless site" - one where wp-admin will no be accessed.

[haszari]

Adding all info from duplicate/similar issue:

• 158

As I understand it this is an unusual use case – a site where wp-admin is rarely visited! That said, we want to ensure our upgrade processes are robust and work well for a variety of use cases 🚀.

Marking this as low priority as I haven't seen many reports of affected merchants. There's an easy workaround – visit wp-admin to kick off the scheduler.

Next steps (if this comes up again):

• Add reproduce steps for a new / clean site.
• The impact of the bug – i.e. specifically what breaks.
• Specific relevant details of how this impacted sites we know of – i.e. real use case for "headless".
• Workarounds for the issue - e.g. visit or automatically request an admin page after plugin update.
• Options or ideas for how to fix this - e.g. add a wp-cli command to manually run database upgrades, or make the upgrade processing more robust so it doesn't require wp-admin load.