The site stopped opening and shows a blank white screen, or the line «There has been a critical error on this website». They are two faces of the same problem, something inside WordPress broke, and they are solved the same way.
|
The white screen is the old version. Up to WordPress 5.2, a fatal error left the page blank with no explanation. From 5.2 onwards it shows the critical error message, which is the same fault with better manners. If you still see blank white, you are probably on an old version, and that alone is a security problem.
|
|
Before touching anything, have a way back. Every step below changes site files. Take a backup first: how to restore your data with JetBackup. Without one, a wrong move turns a broken site into a lost site.
|
Start with the e-mail: Recovery Mode
This saves you the rest of the article more often than not, and almost nobody knows it exists. When there is a critical error, WordPress e-mails the administrator a special link. That link opens the dashboard with the broken plugin paused, and tells you which one it is.
| 1 |
Check the mailbox of the WordPress administration address. Look for «Your site is experiencing a technical issue». Check the bin and the spam folder too.
|
|
| 2 |
Open the link in the e-mail. It signs you into the dashboard and WordPress names the culprit.
|
|
| 3 |
Disable or update that plugin, then exit Recovery Mode.
|
|
Which address gets that e-mail? Not your user’s. It is the one in Settings › General › Administration Email Address. On older sites that field is very often still the address of whoever built the site five years ago. While the dashboard will not open you cannot change it there, but you can force it in wp-config.php by adding define( 'RECOVERY_MODE_EMAIL', 'you@asuaempresa.ao' ); above the line telling you to stop editing. Reload the failing page and WordPress sends a fresh e-mail, this time to you.
|
The link in the e-mail expires. If yours no longer works, do not keep clicking it: open the failing page again and WordPress issues another. As long as the error is there, the e-mail keeps coming.
|
|
If the site cannot send mail, the warning never arrives. It is the commonest reason for «I got nothing». That e-mail leaves the site itself, and a site that sends badly cannot warn itself: why your e-mail is not sending or receiving. In that case, carry on down the page.
|
See the error without showing it to the world
The next step is making WordPress say what is wrong. There is a right way and a wrong way to do that.
|
Do not put errors on your visitors’ screens. Many guides say to set WP_DEBUG to true and leave it there. That writes error messages onto the public page, with file paths and database names on show for everyone. On a live site that is a security problem stacked on the one you already had.
|
The right way sends the error to a file. In cPanel open File Manager, go into public_html, edit wp-config.php and set all three lines:
| 1 |
define( 'WP_DEBUG', true ); turns diagnostics on
|
|
| 2 |
define( 'WP_DEBUG_LOG', true ); writes to a file
|
|
| 3 |
define( 'WP_DEBUG_DISPLAY', false ); and shows it to nobody
|
|
Reload the page with the error, then open wp-content/debug.log. The last line nearly always names the guilty file, and the path tells you whether it is a plugin or the theme.
|
And if debug.log never appears? Then the error happened before WordPress started, and the record is somewhere else: the error_log of the folder itself. Turn on hidden files in File Manager and see where the PHP error log is and how to read it.
|
|
Turn it back off when you are done. Leaving diagnostics on fills the disk and keeps information that should not sit around. Set WP_DEBUG back to false and delete debug.log.
|
When the critical error page hides the error
From WordPress 5.2 there is a fatal error handler that catches the fault and shows the polite page. Good for the visitor, unhelpful for whoever is diagnosing, because the real message stays hidden. To see it raw, and only while diagnosing, add this to wp-config.php:
define( 'WP_DISABLE_FATAL_ERROR_HANDLER', true );
With WP_DEBUG_LOG on and WP_DEBUG_DISPLAY off, the whole error goes to debug.log without crossing anybody’s screen. Remove this line as soon as you understand the fault: without the handler, visitors are back to the blank screen.
The three causes, in order
| Cause |
How to confirm |
| A plugin |
By far the most common. An outdated plugin, or two that stopped getting along after an update. |
| The theme |
Usually turns up right after changing or updating the theme, or after a WordPress update. |
| Out of memory |
The log shows Allowed memory size exhausted. Not broken code: the site simply does not fit in what it has. |
Turning plugins off when you cannot reach the dashboard
If wp-admin will not open either, you can still switch everything off through the cPanel File Manager, or over FTP:
| 1 |
Go into public_html/wp-content.
|
|
| 2 |
Rename the plugins folder to plugins-off. WordPress stops finding them and disables the lot at once.
|
|
| 3 |
Open the site. If it came back, a plugin is the culprit: rename the folder back to plugins and then disable them one by one in the dashboard until the error returns.
|
|
|
Same trick for the theme. Rename the active theme’s folder in wp-content/themes. WordPress falls back to a default theme, ugly but working, which is all you need to diagnose.
|
Out of memory
If the log talks about exhausted memory, add this line to wp-config.php, above the line that says That’s all, stop editing:
define( 'WP_MEMORY_LIMIT', '256M' );
If that is not enough, the ceiling may be PHP’s or the plan’s. The three ceilings and the order they apply in are in PHP limits: memory, time and upload size.
The site is stuck in «maintenance»
A different symptom with a dull cause: the page says «Briefly unavailable for scheduled maintenance» and never moves on. An update was interrupted halfway. WordPress creates a file called .maintenance in the site root when it starts updating and deletes it when it finishes. If the update died on the way, the file stays.
| 1 |
In File Manager, turn on Settings › Show Hidden Files. The name starts with a dot, so it is hidden.
|
|
| 2 |
In the site folder, usually public_html, delete the .maintenance file.
|
|
| 3 |
Open the site. Then run the failed update again, one at a time, checking the result of each before moving to the next.
|
|
When none of this works
Restore a backup from before the day it started: how to restore your data. It is the fastest route once an afternoon has already gone.
And if the error you see has a number, 500, 403, 404, 508, the diagnosis is different: website errors explained. If the site opens but the dashboard does not, see cannot get into the WordPress dashboard. If the site has never opened since you registered the domain, see registered the domain and it still does not open. And if the site opens but drags, that is another matter: the site is slow. If you see Error establishing a database connection, the route is error establishing a database connection: the causes, in order. And if you do not know where to begin, the map of every symptom is in something has gone wrong with WordPress: where to start.
|
How far we go. The server, PHP, the limits and the backups are ours. What lives inside WordPress, plugins, theme and whatever code was put there, is yours or your developer’s. We help work out which side the fault is on: how far our support goes.
|
Português
English
