An Elementor PHP fatal error can lock you out of WordPress, leave the editor blank, or display “There has been a critical error on this website.” The quickest safe response is to deactivate the component named in the error, regain access, and inspect the fatal-error message before updating or reinstalling anything.
Back up the site first if your host still gives you access to backups, files, or the database. Avoid running several updates at once because that makes the original conflict harder to identify.
Regain access to WordPress
WordPress may email the site administrator a recovery link when a plugin causes a fatal error. Check the message for a link containing:
/wp-login.php?action=enter_recovery_modeWordPress Recovery Mode pauses the faulty component for your administrator session. Once logged in, open Plugins > Installed Plugins and deactivate the plugin identified by WordPress.
If no email arrives, use WP-CLI, your hosting file manager, or SFTP.
Deactivate Elementor with WP-CLI
If the error mentions Elementor Pro, deactivate Pro first:
wp plugin deactivate elementor-proIf the error points to Elementor Core, or the site remains unavailable, deactivate it too:
wp plugin deactivate elementorThese commands only deactivate the plugins; they do not delete Elementor content or settings. The syntax is documented in the official wp plugin deactivate command reference.
An Elementor add-on may be responsible even when “Elementor” appears elsewhere in the stack trace. A plugin path is a diagnostic lead, not proof that the plugin caused the failure. If the trace points to an add-on, deactivate that plugin first and check whether the site recovers before disabling Elementor itself.
Deactivate the plugin through the filesystem
Open wp-content/plugins using SFTP or your host’s file manager. Rename the affected directory, for example:
elementor-proto:
elementor-pro-disabledWordPress will treat the plugin as deactivated. If necessary, do the same with the elementor directory.
Rename only the plugin implicated by the error. Renaming the entire plugins directory disables every standard plugin and can interrupt checkout, membership, caching, and security features.
Find the actual fatal error
Do not choose a fix from the critical-error screen alone. You need the PHP error text, particularly:
- The error type, such as
Allowed memory size exhaustedorUncaught Error - File paths named in the error and stack trace
- Any plugin, theme, or custom-code directories in those paths
- The line number
- What changed immediately before the failure
A stack trace shows the sequence of calls that led to the error. Its first plugin path can help narrow the investigation, but the component listed there is not necessarily at fault. Another plugin, the active theme, custom code, or incompatible data may have triggered the failure.
Check the WordPress recovery email and your hosting account’s PHP error log first.
On a staging site, you can also enable private error logging in wp-config.php:
define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );Add these definitions before the line that says That's all, stop editing!. Revisit the failing page once, then inspect wp-content/debug.log.
WordPress recommends using debugging tools on staging rather than leaving them enabled on a live site. Its debugging documentation also explains why errors should be logged instead of displayed to visitors.
Remove the temporary definitions, or set WP_DEBUG to false, after collecting the error. Do not post an unedited debug log publicly because it may contain private paths, URLs, or request data.
Apply the fix that matches the error
Elementor Core and Pro versions do not match
Elementor Core and Elementor Pro must be compatible. A partial update can leave Pro calling a method that no longer exists in Core, or the reverse.
Deactivate Elementor Pro, then install a current compatible Pro release from your Elementor account. Confirm that Elementor Core is also on a stable release before reactivating Pro.
Do not activate both plugins simultaneously after a failed update. Activate Elementor Core first, confirm that the site loads, and then activate Elementor Pro.
Elementor’s own fatal-error guidance identifies mismatched Core and Pro updates as a cause of method-related fatal errors.
The update left incomplete or corrupted files
Errors such as Failed opening required or namespace errors can appear when an update did not replace every plugin file correctly.
Create a current backup of the site’s files and database before deleting anything. Confirm that you have a complete replacement ZIP from a trustworthy source: WordPress.org for Elementor Core or your Elementor account for Elementor Pro.
Deactivate the affected plugin, delete only its plugin directory, and install the verified replacement package. Do not delete Elementor data from the database.
If this happened during an automatic update, check available disk space and file permissions before reinstalling. Otherwise, the replacement may fail in the same way. Keep the backup until the site and Elementor editor have both been tested.
PHP ran out of memory
A message containing this text identifies memory exhaustion:
Allowed memory size of ... bytes exhaustedSend the complete line to your host and ask whether the PHP memory limit can be increased. Also check whether the failure began after enabling another Elementor add-on, importing a large template, or adding a resource-heavy widget.
Increasing memory may restore the request, but repeated exhaustion can indicate a plugin conflict or runaway code. Test again with nonessential Elementor add-ons disabled rather than treating a higher limit as the only fix.
Another plugin conflicts with Elementor
Create or restore a staging copy of the site. Leave Elementor active, then deactivate other plugins in small groups. Test the same action after each group:
- Opening the affected page
- Loading the Elementor editor
- Updating the page
- Viewing the frontend while logged out
When the error stops, reactivate plugins from the last group one at a time. The plugin that brings the fatal error back is the likely conflict.
An error can surface inside Elementor after another plugin passes invalid data or loads an incompatible class. Use the complete stack trace and the results of controlled plugin testing together rather than attributing the failure from one file path alone.
The active theme or custom code is involved
Temporarily switch to a current default WordPress theme on staging. If the fatal error disappears, inspect the original theme’s recent updates, Elementor integrations, and code in functions.php.
Also disable recent PHP snippets, custom Elementor widgets, and must-use plugins. Do not edit the reported line inside Elementor as a permanent fix. Plugin updates will overwrite that change, and the line may only be where a separate compatibility problem became visible.
Only one Elementor page fails
When the editor and most pages work, the problem may be limited to a widget, template, shortcode, or section on one page.
Duplicate the page on staging and remove the most recently added section first. Then test embedded shortcodes, HTML widgets, dynamic tags, global widgets, and third-party Elementor widgets individually.
If removing one section restores the page, rebuild that section instead of replacing the entire page. A frontend blank page is not always a PHP fatal error, so confirm that a corresponding fatal entry appears in the PHP log before applying server-level fixes.
Roll back when the error began after an update
Restore the pre-update backup when the site is business-critical or the compatible release is uncertain. A complete backup is safer than replacing plugin files alone because an update may also change stored data.
If no backup is available, deactivate the affected plugin and install the last stable version that worked on the site. Keep Elementor Core and Pro on a known compatible pair, and test the rollback on staging before applying it to production.
Treat rollback as temporary. Disable automatic updates for the affected component while you confirm the cause, but plan a tested upgrade rather than leaving an old release installed indefinitely.
After the site is stable, reactivate plugins one at a time, clear all WordPress and server caches, and repeat the exact action that originally caused the failure.