Resolving WordPress ‘Critical Error’ Notice

Resolving WordPress 'Critical Error' Notices

Whether your are new to WordPress or a seasoned veteran, we have all seen this ‘A Critical Error has occurred’ notice from time to time, and it is always an annoyance when it appears. The typical response is to “Disable all plugins” and then re-enable them one by one until the notice re-appears, but that is not the only (nor the most expedient) method for resolving this type of issue.

WordPress Critical Error Screen

In this article, I will describe what most would consider the most efficient way to determine the cause of the error (and in most cases pinpoint how to fix them) using an example that we recently experienced at my full-time job.

The Situation

A production website running on a WordPress Multi-site installation reported a critical error notice when attempting to login to a sub-site via the wp-admin panel. The main site is an e-commerce site running WordPress, WooCommerce and large list of other plugins… The “Blog” is a sub-site using a completely different theme and a much smaller list of active plugins (WooCommerce not being one of them).

In this specific situation, there were a few plugins that auto-updated the night before so the error could have been caused by almost anything.

Enable Debugging and the Debug Log

In our production environment, none of the WordPress debugging features are enabled by default so in order to diagnose the issue, we had to enable debugging and debug logging.

To do this, login into your hosting account, open the file manager and locate the ‘wp-config.php’ file (typically located in the root directory of our WordPress Installation). Once you open the file (in your editor of choice), locate the following line:

define( 'WP_DEBUG', false );

We are going to change that, and insert another line directly below it…

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );

This will now create a file called ‘debug.log’ under the ‘wp-content’ directory and report any errors directly into this file.

Check the debug log

Upon examination of the debug log, we found the following fatal error

[26-Jan-2022 12:59:33 UTC] PHP Fatal error:  Uncaught Error: Call to undefined function WC() in /home/{HostingAccountName}/public_html/wp-content/plugins/woocommerce-product-feeds/src/gpf/woocommerce-gpf-admin.php:1302
Stack trace:
#0 /home/{HostingAccountName}/public_html/wp-content/plugins/woocommerce-product-feeds/src/gpf/woocommerce-gpf-admin.php(1323): WoocommerceGpfAdmin->get_google_taxonomy_locales()
#1 /home/{HostingAccountName}/public_html/wp-content/plugins/woocommerce-product-feeds/src/gpf/woocommerce-gpf-admin.php(203): WoocommerceGpfAdmin->maybe_refresh_google_taxonomy()
#2 /home/{HostingAccountName}/public_html/wp-includes/class-wp-hook.php(303): WoocommerceGpfAdmin->admin_init('')
#3 /home/{HostingAccountName}/public_html/wp-includes/class-wp-hook.php(327): WP_Hook->apply_filters(NULL, Array)
#4 /home/{HostingAccountName}/public_html/wp-includes/plugin.php(470): WP_Hook->do_action(Array)
#5 /home/{HostingAccountName}/public_html/wp-admin/admin-ajax.php(45): do_action('admin_init')
#6 {main}
  thrown in /home/{HostingAccountName}/public_html/wp-content/plugins/woocommerce-product-feeds/src/gpf/woocommerce-gpf-admin.php on line 1302

In this situation, the error states ‘Call to undefined function WC()’ and based upon the path of the file making the call, this tells me that the plugin ‘ woocommerce-product-feeds ‘ is trying to call WooCommerce (which is not enabled).

In this specific case, the offending plugin appeared to be automatically activated in the ‘blog’ subsite after it updated the previous evening and this plugin relies on WooCommerce being active as well (in our case, we do not use WooCommerce on the Blog sub-site).

Resolve the issue

To resolve this issue, we navigated to the ‘wp-content/plugins’ folder and renamed the ‘woocommerce-product-feeds’ directory temporarily to ‘xxx-woocommerce-product-feeds’. Once this was done, we were able to access the WordPress admin panel and navigate to the ‘Plugins’ tab… at this point, WordPress automatically deactivated the plugin (because the path it was looking for no longer exists) and we finally rename the plugin folder back to its original name.

Depending on the cause of the critical error, you can sometimes resolve them directly by disabling the plugin/theme or making changes to non-core files ( Child Theme functions.php, custom coded MUPlugin, etc…), otherwise it’s best to send the details from the debug.log to the developer.


After the critical error has been resolved, you should update your ‘wp-config.php’ file to disable debugging and debug logging (specifically in the production environment).

If you found this article helpful, we hope you will share it and provide feedback using the comments form below…

One comment

  1. Good info. Lucky me I discovered your site by chance (stumbleupon). I have saved as a favorite for later!

Leave a Reply

Your email address will not be published. Required fields are marked *