Wordpress Dashboard not loading after updating Woocommerce

[i-belovari-autoactiva]

Prerequisites

• I have carried out troubleshooting steps and I believe I have found a bug.
• I have searched for similar bugs in both open and closed issues and cannot find a duplicate.

Describe the bug

The /wp-admin is not loading after updating Woocommerce to the newest version. Frontend works just fine until an attempt to sign in to wordpress dashbord. My team has found this issue on 3 different websites.

Expected behavior

The Wordpress dashboard should open after logging in.

Actual behavior

The Wordpress dashboard keeps loading indefinitely until a 504 Error occurs (after 3 mins of loading).

Steps to reproduce

1. Go to /wp-admin
2. Log in
3. Wordpress never loads

WordPress Environment

Unable to get, because the Wordpress dashboard won't load.

Woocommerce Version: Newest (Updated Yesterday)
Theme: Flatsome (Newest Version)
Wordpress Version: Newest

Isolating the problem

• I have deactivated other plugins and confirmed this bug occurs when only WooCommerce plugin is active.
• This bug happens with a default WordPress theme active, or Storefront.
• I can reproduce this bug consistently using the steps above.

[ObliviousHarmony]

Hello @i-belovari-autoactiva,

Could you please confirm the version that you are experiencing this problem with? We released a new version (6.5.1) yesterday that resolved a fatal error.

[i-belovari-autoactiva]

The update to the version 6.5.1 has fixed the issues.

[i-belovari-autoactiva]

The same issue occured again. Version 6.5.1

[ObliviousHarmony]

Hello @i-belovari-autoactiva,

Just to confirm, you checked the box that indicates you can reproduce this bug with all plugins except for WooCommerce disabled and the Storefront theme activated. This is accurate, yes? Could you see if there are any logs that could help developers diagnose this issue?

[lucasRolff]

We experience this for some customers as well. Trying to strace the processes, we see it does the brk syscall forever, until eventually timing out. We tried increasing the timeout limits to 1 hour, and the same issue occurs - it simply hangs for 1 hour.

In some cases, the request will end up using an excessive amount of memory - even increasing memory_limit to 64GB (Yes, it's insane), will result in the page using 64GB, and eventually crash due to memory limit exceeded.

I'll tell the customer to try to switch to Storefront and disable all other plugins on a test site - I'll be back with my findings.

[willemb2]

+1 but to be precise not 504 but 500 internal server error when trying to load /wp-admin/. The front end of the website and WooCommerce keep functioning normally, although possibly a bit slower. The issue emerged when upgrading from 6.4.1 to 6.5.0 which was later withdrawn. It also occurs with 6.5.1. We do not run WC Admin.
We also got the “Your website has a technical problem” email. The error (translated from Dutch):
An error type E_ERROR occurred on line 337 of the file /home/lvbhb/public_html/wp-content/plugins/woocommerce/src/Admin/API/Reports/TimeInterval.php. Error: Maximum execution time of 90 seconds exceeded
90 is already high and increasing it to 300 does not help.
Disabling all other plugins is something I'll have to do on a weekend night, because it breaks member functionality. WP 5.9.3 and Avada theme v7.7.1.

[nic0711]

Same here. Any updates?
(Foundry (Child) Theme)

[i-belovari-autoactiva]

Yes, I have deactivated all plugins. I can not access Wordpress backend dashboard with woocommerce plugin active. No logs available

[larsenlarsson]

Same problem here.
We run a multisite with almost 57,000 total orders and over 26,000 users.
After updating from WooCommerce 6.4.1 to 6.5.1, it is no longer possible to access the backend. We then get the error message 503 Service temporarily unavailable.
After the rollback to version 6.4.1, the backend works again as usual. We then see in the logs the error messages CRITICAL Maximum execution time of 3000 seconds exceeded in ../wp-includes/class-wp-object-cache.php in line 296 and CRITICAL Maximum execution time of 3000 seconds exceeded in ../woocommerce/src/Admin/API/Reports/TimeInterval.php in Zeile 337 which occurred shortly after the time when we performed the update.
Is there a scheduled action regarding WooCommerce Admin which can lead to this problem if there are a lot of orders / users? If yes: is it possible to prevent this?

Could this proposal solve the problem?
woocommerce/woocommerce-admin#3904 (comment)

[psealock]

Here is the beta for the next release to test if that works https://github.com/woocommerce/woocommerce/releases/tag/6.6.0-beta.1

[psealock]

@larsenlarsson

If yes: is it possible to prevent this?

You can try turning off Analytics by going to WooCommerce > Settings > Advanced > Features and toggling off Analytics.

Did changing the timezone affect it any way?

[larsenlarsson]

On our test environments, the problem was not present, as there is probably not the mass of orders here. On the live environment, unfortunately, we can't retest it at this time because we can't take a chance on outages. We would like to test a version then when someone has identified the cause of the problem and a fix is included that addresses the cause of the problem.

You can try turning off Analytics by going to WooCommerce > Settings > Advanced > Features and toggling off Analytics.

Can't do it because management and accounting need the settings.

Did changing the timezone affect it any way?

As said, we cannot test this. In the linked ticket, the "trick" seems to lead to success.

[ilyasfoo]

As said, we cannot test this. In the linked ticket, the "trick" seems to lead to success.

Hi @larsenlarsson, thanks for letting us know. May I know the exact country the timezone config was set prior for the affected store?

[larsenlarsson]

Hi @ilyasfoo
The setting is: "Berlin" (Europe/Berlin).

[nic0711]

For us, only the WP Dashboard is unaccessible.
If we "ignore" the Dashboard, all other pages seems to work fine.

Test logging in with e.g. "/wp-admin/themes/" or navigate to themes/plugins/... from the admin bar - maybe it is a workaround.

Timezone: Berlin

[i-belovari-autoactiva]

On our test environments, the problem was not present, as there is probably not the mass of orders here. On the live environment, unfortunately, we can't retest it at this time because we can't take a chance on outages. We would like to test a version then when someone has identified the cause of the problem and a fix is included that addresses the cause of the problem.

You can try turning off Analytics by going to WooCommerce > Settings > Advanced > Features and toggling off Analytics.

Can't do it because management and accounting need the settings.

Did changing the timezone affect it any way?

As said, we cannot test this. In the linked ticket, the "trick" seems to lead to success.

This will help anybody with this issue.
Dont use "/wp-admin" to log in. Use "/wp-admin/admin.php?page=wc-settings&tab=advanced&section=features" and uncheck the first checkbox. This fixed the problem on multiple websites for my team.

[larsenlarsson]

@i-belovari-autoactiva

Dont use "/wp-admin" to log in. Use "/wp-admin/admin.php?page=wc-settings&tab=advanced&section=features" and uncheck the first checkbox. This fixed the problem on multiple websites for my team.

For our management and accounting, this setting would need to remain enabled.

[ilyasfoo]

I'm glad you've found a workaround for this! Unfortunately, I'm unable to reproduce the problem with my local test sites so far.

If there is anyone who could reproduce it reliably on a testing site (without real customer or sensitive data etc.) and could share it with us, that would be a great help for us to debug.

[defive]

I am having the same issue. I can log in, but WooCommerce analytics and the WooCommerce dashboard cause PHP to crash. Here's some detail from my logs. These lines appear every time one of those pages is accessed:

CRITICAL Uncaught Error: Xdebug has detected a possible infinite loop, and aborted your script with a stack depth of '100' frames in /srv/www/public_html/wp-content/plugins/woocommerce/src/Admin/DeprecatedClassFacade.php:82
Stack trace:
#0 [internal function]: Automattic\WooCommerce\Admin\DeprecatedClassFacade::__callStatic()
#1 /srv/www/public_html/wp-content/plugins/woocommerce/src/Admin/DeprecatedClassFacade.php(87): call_user_func_array()
#2 [internal function]: Automattic\WooCommerce\Admin\DeprecatedClassFacade::__callStatic()
#3 /srv/www/public_html/wp-content/plugins/woocommerce/src/Admin/DeprecatedClassFacade.php(87): call_user_func_array()
#4 [internal function]: Automattic\WooCommerce\Admin\DeprecatedClassFacade::__callStatic()
#5 /srv/www/public_html/wp-content/plugins/woocommerce/src/Admin/DeprecatedClassFacade.php(87): call_user_func_array()
#6 [internal function]: Automattic\WooCommerce\Admin\DeprecatedClassFacade::__callStatic()
#7 /srv/www in /srv/www/public_html/wp-content/plugins/woocommerce/src/Admin/DeprecatedClassFacade.php on line 82

[ilyasfoo]

We've been able to reproduce this issue (thanks to @moon0326 for the excellent sleuthing) by changing the value of PHP timezone date_default_timezone_set in wp-settings.php and the Timezone configuration in Settings > General.

Note that it is not recommended for your site to change date_default_timezone_set value in wp-settings.php since this may break things. It's recommended to leave the setting to its default value, which is date_default_timezone_set( 'UTC' );

We're working on a fix at the moment and will update once it's ready

[ilyasfoo]

Fix PR is ready

Edit: removed build link since it requires WooCommerce organization access. Will notify when the PR is merged and a nightly build is ready

[willemb2]

@ilyasfoo Thanks for nailing this down. On /wp-admin/site-health.php we indeed found a warning that something changed the default timezone after WordPress was loaded. This appeared to be caused by a plugin that was custom build for us. After fixing that we could update Woocommerce from 6.4.1 to 6.5.1 without loosing access to /wp-admin/.

[hpuxadmin]

I have this exact problem by merely installing woocommerce fresh on a standalone website though I hav anotrher fully working woocommerce version on another domain on the same webhost. rhel 8
httpd-tools-2.4.37-47.module+el8.6.0+14529+083145da.1.x86_64
redhat-logos-httpd-84.5-1.el8.noarch
httpd-2.4.37-47.module+el8.6.0+14529+083145da.1.x86_64
httpd-devel-2.4.37-47.module+el8.6.0+14529+083145da.1.x86_64
httpd-filesystem-2.4.37-47.module+el8.6.0+14529+083145da.1.noarch

The other wp sites on this host still work normally. The workarpund linkd admin.php?page=wc-settings&tab=advanced&section=features" indicates "Sorry, you are not allowed to access this page.

The only fix right now is rm -rf woocommerce in the wp-content directory

$wp_version = '6.1.1';

/**

• Holds the WordPress DB revision, increments when changes are made to the WordPress DB schema.
• @global int $wp_db_version
  */
  $wp_db_version = 53496;

I also have some issues with word press due to the fact I use a high availability database server using galera and mariadb.

My issue here is I very much want to use woo commerce on all my sites that process revenue or donations.

I am in the process up making php 7.4 on the web server:

PHP 7.4.30 (cli) (built: Jun 7 2022 08:38:19) ( NTS )
Copyright (c) The PHP Group
Zend Engine v3.4.0, Copyright (c) Zend Technologies
with Zend OPcache v7.4.30, Copyright (c), by Zend Technologies