Crash after updated to v1.5.9.1

I have the impression that the update is looking for tables in the database that it cannot find

I tried to delete then reinstall the plugin but it did not solve anything

thank you for helping me

Hey @hurikhan,

Sorry to hear you ran into trouble. We definitely want to investigate this for you.

When you get a chance, please head over to https://wpforms.com/contact/, click “Complete a Form”, and submit.

In your message, reference this thread/URL, we’ll be on the look out for it!

This way we’ll be able to get more information from you and work towards resolving this.

Thanks!

Thank you Jared, I have send it. Regards, Pierre

We are having the same issue. Please help resolve this.

@customcheckout Please try these steps:

1. Open /wp-admin/options.php page on your site.
2. On this page find options schema-ActionScheduler_LoggerSchema, schema-ActionScheduler_StoreSchema, and action_scheduler_migration_status and remove their values (leave them empty), save options changes.
3. Activate WPForms plugin again.

This will trigger an internal library upgrade routine and that should fix the issue.

Hello,
doing these steps I couldn’t find “schema-ActionScheduler_LoggerSchema, schema-ActionScheduler_StoreSchema” in /wp-admin/options.php

@epiphanius1 That means you have a different situation than a topic starter and customcheckout.

Please provide more details of what’s going on on your site. And it might be a good idea to start a new topic.

Sorry, as a first aid I deleted the newest plugin and reinstalled the last one. So I am unable to recollect the exact error message … it was quite long and in addition to it the plugin ?Jump Menu Option“ did not start working.

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.

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)
)

Hi @associationsplus,

Glad to hear you’ve got that resolved, and thanks for letting us know ??

I am also having this issue:

[14-Mar-2020 00:15:37 UTC] PHP Fatal error:  Uncaught Error: Call to undefined method ActionScheduler_DBLogger::unhook_stored_action() in /home/ahbc/public_html/wp-content/plugins/wpforms-lite/vendor/woocommerce/action-scheduler/classes/migration/Runner.php:99
Stack trace:
#0 /home/ahbc/public_html/wp-content/plugins/wpforms-lite/vendor/woocommerce/action-scheduler/classes/data-stores/ActionScheduler_HybridStore.php(215): Action_Scheduler\Migration\Runner->migrate_actions(Array)
#1 /home/ahbc/public_html/wp-content/plugins/wpforms-lite/vendor/woocommerce/action-scheduler/classes/data-stores/ActionScheduler_HybridStore.php(150): ActionScheduler_HybridStore->migrate(Array)
#2 /home/ahbc/public_html/wp-content/plugins/wpforms-lite/vendor/woocommerce/action-scheduler/classes/abstracts/ActionScheduler_Store.php(318): ActionScheduler_HybridStore->query_actions(Array)
#3 /home/ahbc/public_html/wp-content/plugins/wpforms-lite/vendor/woocommerce/action-scheduler/classes/ActionScheduler_AsyncRequest_QueueRunner.php(82): ActionScheduler_Store->has_pending_actions_ in /home/ahbc/public_html/wp-content/plugins/wpforms-lite/vendor/woocommerce/action-scheduler/classes/migration/Runner.php on line 99

I don’t think coorecting sql tables is a very accessible fix however. Should there not be a more graceful error recovery than WSOD for the above error? I’m assuming this is actually an issue with Woocommerce’s action scheduler but it’s completely unhelpful for an issue with it to take down a site due to WPForms throwing a critical error over it ??

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.

Unfortunately, this is a known bug inside Action Scheduler library, and its maintainers are working on a fix to at least allow more easily recreate tables.
The next minor WPForms version will have own additional precautions implemented, so we will not rely solely on Action Scheduler successful migration.