associationsplus

Agreed. The odd thing is we ran into this and we ONLY use WPForms-Lite, we do NOT use WooCommerce or anything else that may require this ActionScheduler thing, so the suggested wp-options config file fix did not apply in our case. Also, installing the ActionScheduler standalone plugin after downloading it from GitHub did not fix it either, the tables had to be manually created.

So I think I was able to eventually fix this by going to https://github.com/woocommerce/action-scheduler and downloading Action Scheduler, then looking in the files /classes/schema/ActionScheduler_StoreSchema.php
and /classes/schema/ActionScheduler_LoggerSchema.php and deriving the create table commands to create the proper tables.

The SQL queries look like this, but be sure to rename the tables to match whatever your WP install prefix is (default is “wp_”):

CREATE TABLE wp_actionscheduler_actions (
action_id bigint(20) unsigned NOT NULL auto_increment,
hook varchar(191) NOT NULL,
status varchar(20) NOT NULL,
scheduled_date_gmt datetime NOT NULL default ‘0000-00-00 00:00:00’,
scheduled_date_local datetime NOT NULL default ‘0000-00-00 00:00:00’,
args varchar(191),
schedule longtext,
group_id bigint(20) unsigned NOT NULL default ‘0’,
attempts int(11) NOT NULL default ‘0’,
last_attempt_gmt datetime NOT NULL default ‘0000-00-00 00:00:00’,
last_attempt_local datetime NOT NULL default ‘0000-00-00 00:00:00’,
claim_id bigint(20) unsigned NOT NULL default ‘0’,
extended_args varchar(8000) DEFAULT NULL,
PRIMARY KEY (action_id),
KEY hook (hook(191)),
KEY status (status),
KEY scheduled_date_gmt (scheduled_date_gmt),
KEY args (args(191)),
KEY group_id (group_id),
KEY last_attempt_gmt (last_attempt_gmt),
KEY claim_id (claim_id)
)

CREATE TABLE wp_actionscheduler_claims (
claim_id bigint(20) unsigned NOT NULL auto_increment,
date_created_gmt datetime NOT NULL default ‘0000-00-00 00:00:00’,
PRIMARY KEY (claim_id),
KEY date_created_gmt (date_created_gmt)
)

CREATE TABLE wp_actionscheduler_groups (
group_id bigint(20) unsigned NOT NULL auto_increment,
slug varchar(255) NOT NULL,
PRIMARY KEY (group_id),
KEY slug (slug(191))
)

CREATE TABLE wp_actionscheduler_logs (
log_id bigint(20) unsigned NOT NULL auto_increment,
action_id bigint(20) unsigned NOT NULL,
message text NOT NULL,
log_date_gmt datetime NOT NULL default ‘0000-00-00 00:00:00’,
log_date_local datetime NOT NULL default ‘0000-00-00 00:00:00’,
PRIMARY KEY (log_id),
KEY action_id (action_id),
KEY log_date_gmt (log_date_gmt)
)

Same issue happened to a site we maintain, and the /wp-admin/options.php file also did not contain these strings. Essentially the tables being referenced do not exist, and the plugin does not create them, so it simply takes down large swaths of the website down and fills the error logs with tons of warnings and non-fatal errors. It seems to be specific to WooCommerce, yet this functionality apparently cannot be disabled whether or not one uses WooCommerce, which would seem like the simple way to mitigate the issue if it were possible. Our approach at mitigating the issue was to try and create the table based on the content of the error messages, but this only reduces the number of fatal errors, though there are still plenty of non-fatal errors and warnings.