There are situations where, when updating a plugin, theme, or WordPress itself, we re-enter our site and a blank screen appears, with or without a visible error... In rare cases, it happens without any action on our part. But the conclusion is the same: our website has been inaccessible. And perhaps not only for our visitors, but also for the administrators. But let's not despair, in this guide we are going to explain how to fix the famous white screen or WSoD ("White Screen of Death" WordPress).
How to fix WordPress white screen
The infamous WSoD is the most common WordPress error and we absolutely all go through it at least once. The screen and the information it gives us is generally analogous to white: nothingness itself. To top it off, if you get to read an error, Edge, Chrome and Firefox may present different messages (which only confuses us).
Fixing the blank screen usually involves undoing our steps, disabling plugins (or even the Theme) until we find the problematic factor or other alternatives that we are going to analyze below. If we do not want to walk blindly, we can be guided by the PHP error file, error_log. It is located at the root of our site, accessible via FTP or cPanel File Manager. However, this step may be advanced (or unnecessary!), so We are going to go through the trial and error journey together, baby steps. Patience.
PHP is the programming language used in WordPress, so if an error occurs, it should be logged in the file error_log.
We explore the alternative of verifying error_log later in this guide.
The “good news” is that, WordPress blank screen is almost always caused by a PHP conflict. The other alternative is an out of memory issue: our site, for some reason (usually a plugin), exceeded the allowed RAM capacity. Note that in PHP there is a memory usage limit for safety, which prevents a crashing plugin from flooding the resources of an entire server. This limit also exists for malicious users who, through a malicious plugin, try to take control. If we just installed a new plugin, that's the problem. Otherwise, we will have to deactivate plugins one at a time (as long as we can access the Desktop).
We will see how to increase the RAM of our WordPress later in the note. It is highly recommended to try the most immediate solutions that we propose beforehand.
I can't access the Desktop, what do I do?
In this case, the solution is, as we mentioned a few paragraphs back, to access the site's files via FTP using a client such as filezilla. If our hosting plan has cPanel, then it is better to use your native tool. Remember that to enter cPanel we must write the URL cpanel.mysite.com (replacing "mysite" with the real name of our website). If the site is hosted on duplika, we have secure cPanel.
Plugins are stored in the path /wp-content/plugins/
Then, if we change the name “plugins” to something else (for example, "test"), all plugins will be temporarily disabled. It is the fastest way to verify that one of the components has caused a conflict. It is enough to try a new entry to our Desktop, or directly verify if our site is now online.
If we manage to enter the Desktop and/or recover the online status of our website, then we must rename the plugins folder to its original name again. But, after this step, we have to change the names of the plugins folders, one by one. It is simply trial and error until we find the one that brings the site down.
If after renaming the plugins folder the WordPress white screen is still there, then the problem may be with the Theme. Entering the Desktop, let's change the Theme to any other of those that come with WordPress (Desktop » Appearance » Themes). If we cannot enter the Desktop, there is no choice but to repeat the operation mentioned via FTP. So, entering the site files, we have to look for the folder /wp-content/themes/ and rename "themes" to something else. Thus, WordPress will be forced to activate the latest theme by default (almost always twenty twenty).
Attention: if we have deleted the default WordPress Themes, we must previously download some and upload it to our Themes folder. In other words, we can't rename the active Theme if there isn't at least one other one available. WordPress doesn't work without Themes.
Locate the “error_log” on our site
We anticipate the existence of error_log. It's about a Text file, mainly available in 2 locations:
- Root directory of our WordPress (usually public_html) either…
- …directory wp-admin of our WordPess for when the error occurs in the login screen either management.
Note: We have already mentioned in this guide that, in order to read or manipulate files on the site, we need access via cPanel or FTP. If you have missed it, please read the full note.
At the end of this text file we will find the most recent errors. If a plugin is mentioned, then we will change the name of its directory in the folder /wp-content/plugins/ as we have described a few paragraphs ago.
This forces WordPress to disable said plugin; as we have already described, we must retry the login to the Desktop, or check if our site is online again. Otherwise, we must continue looking for other alternatives.
What if we clear the cache?
Have we tried entering our site from another device? For example, do we discover that our cell phone works fine but our laptop doesn't? Then we must clear the browser cache of the device where the web appears down. If we do not know how to do it, it is better to consult the browser's documentation or search Google for something like "how to clear the safari cache?" (replace 'safari' with the name of the browser we use).
Another alternative is to clear the cache of our website, as long as we use a cache builder component. Typical caching plugins are WordPress Rocket, W3 Total Cache, WP Super Cache either LiteSpeed. Typically, to clear the cache we must enter through the Desktop, and, using the WP Super Cache example, just access Settings » WP Super Cache » Delete Cache. In the links provided we will find guides for each of these components.
If we have the suspicion (or the certainty, as a result of an accurate error) that we are running out of RAM, it is possible to increase your limit. For this we must enter our cPanel control panel by writing the route:
Once you have entered cPanel with your credentials, scroll the screen until you see the login area. software. In it you will find the icon indicated in the screenshot below. Click.
By clicking on the tab Options You will see a screen where you can choose the version of PHP that your CMS needs. You can also modify variables or add rules. For example, changing the memory limit which is exactly what we want.
After designating a higher number as we show in the screenshot above, the changes will automatically be applied.
If the out-of-memory error persists, we have a big development problem, something that will require an expert WordPress web developer. It is almost impossible for a WordPress site, updated, running with a professional Theme and some popular plugins, to require a memory adjustment. The alternative to this is that our hosting provider is not providing us with the necessary resources for WordPress to function correctly.
Verify a failed update
There are cases where the WordPress update server goes down or gets very slow. While this scenario usually resolves itself, this is not always the case. Thus, it is one more alternative that explains the WordPress White Screen of Death.
Because? Because when WordPress is updated, or even a plugin is updated, our site briefly goes into “maintenance mode”. For technical purposes, a file is generated in the root of our site called '.maintenance'. As long as this file exists, our site will be down (under "maintenance").
Concluding, we must enter to see the root files of our website and find that this one called does not exist .maintenance. If it appears, we must delete it. Then, check that our site is back online. For now and regardless of whether the problem was summed up in this or not, as long as .maintenance exists, the site will always be offline.
None of this resolved the blank screen
If unfortunately we have not found the cause after having tried all these steps, it is best to ask our hosting provider to recover our site from a backup. Decent hosting services usually do permanent backups. In Duplika, for example, backup copies are generated every day.
Once our site has been recovered, and if it has been left blank due to any change we have made, then it is best to take advantage of the staging or cloning capacity of our site. This allows you to update a copy of it, modify it, without altering the real online version. We have touched on the topic of staging in a guide that we recommend taking into account.
Sincerely wishing that this guide has succeeded in reversing the WordPress white screen, we appreciate reading and encourage you to leave your impressions in the comments section.
We are Duplika
Give your site the hosting it deserves
Leave a Reply