Since WordPress 5.2 introduced the built-in fatal error recovery mode, unhandled PHP fatal errors (such as E_ERROR, E_PARSE, or E_COMPILE_ERROR) halt script execution and render the generic “There has been a critical error on this website” screen instead of displaying a completely blank white screen. Resolving this error in a live production environment without guessing requires capturing the exact PHP stack trace via WP_DEBUG_LOG and systematically isolating the failing hook, theme template, or memory ceiling.
1. Enabling Safe Error Logging in wp-config.php Without Exposing Errors Publicly
To diagnose the underlying cause of a fatal crash on a live website without exposing sensitive backtrace data to external visitors, you must edit the wp-config.php file located in your WordPress root directory via SFTP or SSH. Place the following configuration directives directly above the /* That's all, stop editing! Happy publishing. */ comment line:
define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );
@ini_set( 'display_errors', 0 );Keeping WP_DEBUG_DISPLAY explicitly set to false and overriding PHP’s display_errors directive ensures that sensitive PHP stack traces, database credentials, server directory paths, and function parameters are written privately to the file located at /wp-content/debug.log rather than being rendered on frontend pages where malicious actors could inspect them.
2. Reading the PHP Fatal Error Stack Trace in debug.log
Once error logging is active, trigger the critical error by reloading the failing page, then inspect the last entries added to the log using the command tail -f wp-content/debug.log over SSH or downloading the file via SFTP. When analyzing the log, you will typically encounter three main root causes:
Uncaught Error: Call to undefined function
This usually occurs when upgrading server PHP versions (such as moving from PHP 7.4 to PHP 8.2 or 8.3) while required PHP extensions like gd, mbstring, curl, or xml are missing from the server environment, or when a function belonging to a deactivated or uninstalled plugin is invoked by active theme code.
Allowed memory size of X bytes exhausted
This fatal error indicates that script execution hit the configured PHP memory limit during heavy operations such as WooCommerce cron jobs, background image regeneration, large database query loops, or bulk data imports.
Uncaught TypeError / ArgumentCountError in PHP 8.2+
PHP 8.0+ enforces strict type checks and deprecated parameter handling. Legacy functions in custom theme functions.php files or unmaintained plugins that pass null values into strict internal string or array functions frequently trigger unhandled TypeErrors.
3. Isolating Faulty Plugins or Themes via WP-CLI and SFTP
When the critical error prevents access to the WordPress admin dashboard (wp-admin), you can isolate the responsible component directly from the command line using WP-CLI:
# Deactivate all plugins without executing their code
wp plugin deactivate --all --skip-plugins
# Activate a default fallback theme safely
wp theme activate twentytwentyfour --skip-themesIf WP-CLI is unavailable on your hosting provider, connect via SFTP, navigate to the /wp-content/plugins/ directory, and rename the suspected plugin directory (for example, renaming /wp-content/plugins/faulty-plugin to /wp-content/plugins/faulty-plugin.disabled). WordPress will automatically detect that the plugin file is missing and mark it as deactivated, allowing you to regain admin dashboard access immediately.
4. Resolving PHP Memory Exhaustion and OPcache Collisions
If the stack trace identifies memory limits as the bottleneck, increase the memory allocated to WordPress single-script execution by defining higher ceilings inside wp-config.php:
define( 'WP_MEMORY_LIMIT', '256M' );
define( 'WP_MAX_MEMORY_LIMIT', '512M' );Verify that your underlying server configuration in php.ini or .user.ini allows these allocations by ensuring memory_limit = 512M. If changes do not immediately take effect, flush the PHP-FPM OPcache service or reload PHP-FPM (systemctl reload php8.2-fpm) to eliminate stale bytecode cache collisions.
5. Production Cleanup Checklist
After pinpointing and repairing the faulty plugin or code error, perform the following essential security cleanup steps before exiting:
1. Open wp-config.php and reset debugging flags back to off:define( 'WP_DEBUG', false );define( 'WP_DEBUG_LOG', false );
2. Delete the generated log file located at /wp-content/debug.log via SFTP or SSH so sensitive file structure details and backtraces are permanently erased.