A WordPress “critical error” message is a symptom, not a diagnosis. A plugin update may be involved, but the underlying cause could also be a PHP compatibility problem, a missing dependency, or exhausted memory. The useful question is: what failed, and what changed immediately before it failed?
Here is a practical workflow for narrowing the problem without making several uncontrolled changes to a live site.
1. Preserve the current state
Before changing files, take a backup of both the database and site files, or ask your hosting provider for a snapshot. Confirm the date of your last working backup. A backup of the broken state can still preserve recent orders, uploads, and other changes.
For a shop or membership site, avoid restoring an old database without considering transactions created since that backup. Prefer a staging copy for investigation whenever possible.
Write down the approximate failure time and recent changes: plugin updates, theme updates, PHP version changes, custom code, or hosting configuration changes.
2. Check the recovery email and server logs
WordPress may send the site administrator a recovery-mode email after detecting a fatal error. Check the administrator mailbox and spam folder. Treat the recovery link as private: do not publish it or forward it to an untrusted person.
If the email is unavailable, look for the PHP error log in your hosting control panel. Find entries around the failure time. A useful entry often includes an error type, file path, and line number.
For example, a path inside a plugin directory tells you where the failure surfaced. It does not automatically prove that the plugin alone caused it; another component may have supplied unexpected data or removed a dependency.
3. Isolate the suspected plugin
If the dashboard works, deactivate the suspected plugin and retest the affected page.
If the dashboard is unavailable, use your hosting file manager or SFTP to rename that plugin’s folder under wp-content/plugins/. For example, rename example-plugin to example-plugin.disabled. Record the original name so the change is reversible.
Change one component at a time. Do not delete the plugin or its database tables during diagnosis. Disabling a payment, security, or form plugin can remove important functionality, so check what depends on it and coordinate the interruption.
If the site recovers, leave the suspected plugin disabled while investigating compatibility and the update. Restoring its folder name makes it available again; confirm its activation state in the dashboard rather than assuming it is active.
4. Use temporary logging when necessary
If hosting logs do not provide enough information, temporary WordPress debug logging may help. Back up wp-config.php first and edit existing definitions rather than adding duplicates. Place these settings before the line that loads wp-settings.php:
define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );
Reproduce the error once, then inspect wp-content/debug.log if it was created. Logging depends on the server configuration and file permissions, so an empty or missing log is not proof that no error occurred.
Keep error display off on a public site. Logs may contain file paths or sensitive details; restrict access and do not post the entire file publicly. Turn debugging off after diagnosis and remove or securely archive the temporary log.
5. Fix the cause and test the recovery
Compare the plugin’s supported WordPress and PHP versions with your environment. Test an update, vendor-provided fix, or trusted previous version on staging. Avoid random download sites and do not downgrade PHP blindly.
If the log reports memory exhaustion, investigate the request and component using the memory. Raising a limit may relieve the symptom, but it does not explain why usage increased.
After the repair, test more than the homepage: dashboard login, the affected feature, forms, and relevant shop flows. Check logs again for fresh errors and keep a short record of the cause and fix.
When to ask for help
Escalate when you cannot obtain a backup, the error involves several components, or an active store risks losing orders. Provide the failure time, recent changes, and a redacted error excerpt through a secure support channel.
Disclosure: this article is published by DevTechi, which provides website technical support. If you need hands-on assistance, our WordPress Emergency Fix service starts at $39 for one focused repair issue.
The goal is a confirmed cause and a tested recovery, not simply making the error message disappear.
Top comments (0)