Learn to debug a WordPress error

A blank screen or a 500 response does not identify the cause on its own: the failure may come from PHP, WordPress, the web server or a dependency. Start with the log associated with the request and the exact time of the error, without attributing it yet to a plugin or a recent change.

Preferably run the test on a staging copy. If you have to reproduce it in production, keep display_errors disabled and send errors to a private log outside public_html, following the guide to debug errors in WordPress.

If WordPress shows the critical error message, first check the administrator account's email. Since WordPress 5.2, the Recovery Mode link lets you log in with the problematic plugin or theme paused for that session.

Reproduce only the failing operation and check the log straight away. In this example, the following fatal error appears:

Fatal error: require(): Failed opening required 
'/home/user/public_html/wp-content/plugins/woocommerce/src/Packages.php' 
(include_path='.:/opt/alt/php74/usr/share/pear') 
in /home/user/public_html/wp-content/plugins/woocommerce/woocommerce.php on line 25

The message proves that require could not open this file:

public_html/wp-content/plugins/woocommerce/src/Packages.php

and that the call was made from line 25 of:

public_html/wp-content/plugins/woocommerce/woocommerce.php

This places the failure while WooCommerce was loading, but does not by itself prove that the plugin is damaged or why the file could not be opened. Also check the warning before Failed opening required, which usually says whether the file does not exist, is not readable or is blocked by a path restriction. Check that it exists, its upper and lower case, permissions, owner and whether it matches the installed version.

If the file really is missing and the error appeared during an update, an incomplete installation is a hypothesis consistent with the evidence. To regain access temporarily, first use Recovery Mode or rename wp-content/plugins/woocommerce; do not delete the directory before keeping a copy for analysis.

You can then reinstall the same version or a compatible one from an official source. Restore the directory from a backup only if the backup predates the failure, is considered clean and is compatible with the current state of the database.

Recover the shop and check the full order flow

The trace is a historical example: the php74 path is not a recommendation to use PHP 7.4. Use the maintained, compatible version that matches your current WooCommerce.

While WooCommerce is paused, the shop may lose purchasing features. Keep recent orders and avoid restoring an old database just to recover a plugin file. After repairing the files, check the catalogue, cart, checkout and payment notification in a test environment. If you install a version that migrates the database, also plan how a rollback would stay compatible; copying an old folder afterwards does not undo that migration.