alexcpaige

FURTHER UPDATE: the site host has reinstalled an earlier version of the WordPress database from prior to the site migration. This appears to have fixed the errors with regard to login, shopping cart and checkout functionality, etc.

I obviously am concerned about a possible recurrence and would like some advice as to how militate against this happening again. When I asked the site host the likely cause, they simply responded that all logs pointed to the database post the site migration being corrupted. This seems to me to suggest the error occurred during the site migration or as a result of it, but clearly the site host doesn’t want to take responsibility.

Any advice would be appreciated.

Also there is one concern which is lingering for me and that is an issue which has persisted for months. Sometimes (not always) when I click on WooCommerce → Home the setup wizard begins activating. Surely this should not be the case, as Woocommerce is already set up?

On other occasions this does not happen and I get the Woocommerce Home screen, although I am getting an “There was an error getting your inbox. Please try again” and RELOAD clickbox.

This is still occuring even after yesterday’s complete deletion and reinstallation of Woocommerce.

Is this something which points to an issue which needs to be resolved?

• This reply was modified 5 months, 3 weeks ago by alexcpaige.

Hi @lovingbro, thanks for your response.

The escalation of this issue is very concerning. We had three admin user logins to the site and two of them ceased to function. In each case, we were able to log in once via each login, but once logged out, were unable to log back in again. There is now only one admin user login functioning and that is the one set in the Installatron control panel.

Attempts to create new users to the site are not working in WordPress and when added directly via the database they do not appear in the WordPress backend of the site.

According to our web developer, the errors seem to suggest that there is another database being written to. I am wondering whether this is somehow related to the site migration which was done a month or two ago. There appears to be an extant C Panel related to the site’s former server, perhaps that is the issue (if the site migration was not handled correctly?)

Our web developer has copied the database and all site files and will attempt to run a copy of the site on his own server and monitor at server level what is happening with the attempts to create users.

Ironically, the shopping cart functionality appears to now be restored (at least when logged in as admin).

I have also asked the site host if they can disable server side security layers and check the various other areas you advised.

Thank you Sai.

I have reinstalled WooCommerce and the action scheduler logs table has been recreated as advised.

However, when I go to WooCommerce → Status → Tools there is no “Clear scheduled actions” option to run.

Update: I got in touch with the site host and they responded as follows:

“We have identified the issue causing users to be unable to log in to the website. The problem is related to a database error in the WordPress Action Scheduler table (wp_actionscheduler_logs), where the primary key is not functioning correctly. As a result, database insert operations fail during background processes triggered when a user attempts to log in, which prevents the login process from completing successfully.

Please refer to the error logs below for reference:
—
[27-Jan-2026 04:36:04 UTC] WordPress database error Duplicate entry ‘0’ for key ‘PRIMARY’ for query INSERT INTO wp_actionscheduler_logs (action_id, message, log_date_gmt, log_date_local) VALUES (5274, ‘action ignored via WP Cron’, ‘2026-01-27 04:36:04’, ‘2026-01-27 15:36:04’) made by do_action_ref_array(‘action_scheduler_run_queue’), WP_Hook->do_action, WP_Hook->apply_filters, ActionScheduler_QueueRunner->run, ActionScheduler_QueueRunner->do_batch, ActionScheduler_Abstract_QueueRunner->process_action, do_action(‘action_scheduler_execution_ignored’), WP_Hook->do_action, WP_Hook->apply_filters, ActionScheduler_Logger->log_ignored_action, ActionScheduler_DBLogger->log
[27-Jan-2026 04:36:04 UTC] WordPress database error Duplicate entry ‘0’ for key ‘PRIMARY’ for query INSERT INTO wp_actionscheduler_logs (action_id, message, log_date_gmt, log_date_local) VALUES (5275, ‘action ignored via WP Cron’, ‘2026-01-27 04:36:04’, ‘2026-01-27 15:36:04’) made by do_action_ref_array(‘action_scheduler_run_queue’), WP_Hook->do_action, WP_Hook->apply_filters, ActionScheduler_QueueRunner->run, ActionScheduler_QueueRunner->do_batch, ActionScheduler_Abstract_QueueRunner->process_action, do_action(‘action_scheduler_execution_ignored’), WP_Hook->do_action, WP_Hook->apply_filters, ActionScheduler_Logger->log_ignored_action, ActionScheduler_DBLogger->log
—“

Assuming that is the issue, how do I go about fixing it?

And what is likely to have caused it? Everything was working properly until Jan 14th when WordPress advised of a critical memory allocation error, as follows:

“Error Details
=============
An error of type E_ERROR was caused in line 667 of the file /home/w9783498/public_html/wp-content/plugins/woocommerce/includes/abstracts/abstract-wc-data.php. Error message: Allowed memory size of 536870912 bytes exhausted (tried to allocate 20480 bytes)

“The site utilises the following:
WordPress version 6.9
Active theme: Astra (version 4.12.0)
Current plugin: WooCommerce (version 10.4.3)
PHP version 8.2.11″

It seems to me that the site running out of PHP memory/server disk space has interrupted database operations and caused data to be written incorrectly. ie the host database server was overloaded or otherwise became unresponsive, and this is what resulted in the corruption of the data.

However, the website host says the issue “is not related to server memory, caching, or server-level configuration not related to server memory”, which strikes me as disingenuous, especially as they have offered no alternative explanation.

The only explanation they offered for the memory allocation error was the fact that the site is on a shared hosting platform.

• This reply was modified 5 months, 3 weeks ago by alexcpaige.

Thanks so much for your very helpful and comprehensive response.

EDIT: As per your advice I have reactivated WP Super Cache but set it not to cache homepage.

This appears to have resolved the issue and load time for site is much faster.

• This reply was modified 7 months ago by alexcpaige.
• This reply was modified 7 months ago by alexcpaige.
• This reply was modified 7 months ago by alexcpaige.