WordPress displays its generic critical-error message when PHP stops on an uncaught fatal. The visible text does not identify whether the cause is a plugin, theme, custom snippet, PHP version, missing file or exhausted resource.
Preserve the first error and recent change history before switching components off. The fastest reliable repair starts with the failing file and call path, not a random deactivation sequence.
Record the failure boundary
Note the exact URL, time, action and whether the public site, administrator, login, cron or only one page fails. Test once in a private browser.
Check whether an update, deployment, PHP change or restore occurred immediately beforehand. Record versions and operator without assigning blame.
Do not repeat a write action such as import or form submission until you know whether it completed before the fatal.
Take a recoverable backup
Back up files and database before editing. If storage is nearly full, download or use an external destination rather than creating another large archive on the same account.
Confirm you have working cPanel, Plesk, SFTP or SSH access and know the active document root. A backup you cannot locate or restore is not a rollback.
Avoid overwriting the only known copy with an untested restore.
Read the PHP fatal
Use the hosting PHP error log and match the timestamp and request. The fatal normally names a file and line, plus a message such as undefined function, type error or memory exhaustion.
Capture safely:
fatal type and message
file/plugin/theme path
line and call stack
PHP version
request/timeRedact filesystem account names, secrets and customer data before sharing.
Enable protected WordPress logging if needed
When host logs are insufficient, add temporary logging above the “stop editing” line in wp-config.php:
define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );
@ini_set( 'display_errors', 0 );Do not leave duplicate constants or display errors to visitors. Remove or disable debug mode after evidence is collected and protect/delete the log according to retention policy.
Isolate the named component
If the fatal points to a plugin, rename only that plugin directory through the file manager or SFTP. If it points to the active theme, ensure a compatible default theme exists before changing the active theme.
For a custom snippet plugin, disable the implicated snippet through its documented safe mode or database only after backup.
Do not rename the whole plugins directory unless evidence is unavailable and you have a controlled reactivation plan.
Check PHP and missing dependencies
An undefined function may mean a dependency plugin did not load or an update left incomplete files. A type error can expose incompatibility with the current PHP version.
Compare WordPress, plugin/theme and PHP requirements. Reinstall the exact trusted package when checksums or file counts show an incomplete deployment.
Do not download replacement code from unofficial mirrors or downgrade a security fix without a forward plan.
Apply the narrow repair
Update or roll back one component, correct the custom code, restore a missing dependency or choose a supported PHP version based on evidence. Keep the change reversible and document it.
Clear relevant OPcache and generated assets through supported hosting controls. A stale bytecode cache can keep the old fatal active.
Avoid editing WordPress core to suppress the error.
Verify beyond the failed page
Test public pages, login, administrator, editor, media, scheduled tasks and the exact original action. Check logs for new fatals and confirm email or external integrations affected by the action.
Recurring care should monitor PHP fatals and stage updates. An urgent repair is complete when the cause is understood, the site path works and rollback evidence remains—not when the generic message merely disappears.