How to Fix a WordPress Critical Error: Safe Diagnosis and Recovery

The message "There has been a critical error on this website" means that the execution of PHP has stopped before completing the request. If the message appears right after a plugin installation, theme change, or update, that change is the prime suspect; But lack of memory, incompatibility of PHP version and file corruption also produce a similar result. The safe way is to first find the actual error from the log and then disable or modify only the same component.

Quick answer: Backup the files and database, check the administrator's Recovery Mode email, read the PHP log and wp-content/debug.log and temporarily disable the plugin or theme whose name appears in the stack trace do Blindly restoring all files or increasing memory too much will make detection more difficult.

Define the scope of the crash first

Test the home page, a post, store, REST API, and wp-admin separately. If only one URL is broken, it's more likely a data or code error in the same path. If all pages are down, even admin login, it's more likely a WordPress bootstrap, global plugin, or theme error. See also HTTP response; The apparent message may be delivered with a status of 500, 503, or even 200.

• Record the exact time the error started and the last change.
• Check disk space and access to the host or SSH panels.
• In the store, keep the status of new orders before rollback.
• A snapshot of the broken state is also valuable for later analysis.

Where to find the actual error?

Recovery Mode and Administrator Email

WordPress sends an email with a recovery mode link in some fatal errors. Check the Spam folder and the correctness of the administrator's email. Logging in from this link allows you to disable the stopped component without manipulating the files. Absence of email does not mean absence of error; The site itself may have problems sending email or an error occurred before that step.

PHP log and debug.log

PHP-FPM, Apache, or hosting panel logs are usually the most reliable sources. To temporarily record the error in WordPress, after the backup, put these values ​​before the "stop editing" line in wp-config.php:

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

Now repeat the broken request once and check the end of wp-content/debug.log. The file name, line number, exception type and the first relevant part of the stack trace are important. Do not enable error display on production; File path and internal information may be exposed. After detection, return the debug to normal status.

Step by step recovery with the least risk

1. Suspect plugin: If the management does not open, rename the folder of the same plugin in wp-content/plugins. Renaming the entire plugins folder is just a short test; Then activate the plugins one by one.
2. Format: If trace refers to a template, ensure there is a healthy default template and temporarily discard the active template. Removing a theme without a replacement is not a safe way.
3. PHP version: Compare versions supported by WordPress, theme and plugin. Change the PHP first in staging and check the required extensions for the project. Increasing the cap is only true when the workload is valid; Don't hide memory leak or bad query.
4. Memory:messageAllowed memory size exhaustedFollow up with consumption measurements. Increasing the cap is only true when the workload is valid; Don't hide memory leak or faulty query.
5. kernel: checksum of kernel files. Do not replace the wp-content and wp-config.php files with the core package.

wp core verify-checksums
wp plugin list --status=active
wp theme list

WP-CLI must be run from the correct site root and with the correct user. The kernel checksum output does not judge the plugin and upload; Interpret the result carefully.

If the site returns, the work is not finished

Returning the page after disabling the plugin only makes the causal relationship possible. Reproduce versions, changelog, PHP requirement and detailed error in staging. Then install the compatible version or the valid patch and make important routes such as login, form, search, checkout and cron according to the role of the smoke test component. The core, theme, and plugins must stay up to date, but the change propagation must be visible and reversible. Register the version of PHP and extensions in the site's assets list, keep the staging as similar to production as possible, and read the manufacturer's declared incompatibilities before any changes. Perform a test restore periodically.

How to prevent the repetition of Critical Error?

Prevention does not mean stopping all updates. The core, theme, and plugins must stay up to date, but the change propagation must be visible and reversible. Register the PHP version and extensions in the site's assets directory, keep staging as close to production as possible, and read the manufacturer's declared incompatibilities before making any changes.

• Scheduled backup is not enough without restore test; Periodically perform a test restore.
• Make changes in a certain interval so that the connection of the error with the release can be detected.
• Monitor PHP error, status code and disk space; Home page uptime alone is not enough.
• Remove unmaintained or overlapping plugins after evaluation, rather than just disable and forget them.

Tasks that usually make things worse

• Installing multiple "debug" plugins on a site with no known cause.
• give access 777; This does not solve the ownership problem and creates a security risk.
• Complete restoration of the store database and loss of orders after backup.
• Edit the vendor file that will be removed in the next update.
• Disable WAF or security tools without witnesses.

When is expert review necessary?

If the crash starts after the upgrade, guide WordPress Recovery After updating the plugin, see also. If the server response is 500, WordPress 500 error detection path explains the details of the web server layer.

If the error returns frequently, goes to PHP-FPM or MySQL, or the site has a live order, further testing on production is risky. In this situation, a coordinated check of the WordPress log, web server, PHP and database can determine the root of the error before extensive changes. Details WordPress Technical Troubleshooting Service is available for this type of troubleshooting.

Frequently Asked Questions

Does Critical Error mean the site has been hacked?

No. This message is the result of a fatal error in PHP and does not indicate the cause by itself. The security event should be proven by logging and integrity checking.

Should we keep WP_DEBUG on?

Temporary logging is useful, but displaying the error on the public site is not appropriate. After fixing the problem, return the debug settings.

What if debug.log is not created?

Check the write permission, content path and main PHP log. Some errors occur before the WordPress logger.

Is a full restore the fastest way?

For a simple content site maybe, but in a store it can delete new data. The restore domain must match the RPO and data type.