The Solution to the 5 Most Common Problems of WordPress

In addition, a lot of advice and solutions that we will see are applicable to other types of errors you might encounter (something like “generic solutions”). Thus, if you haven’t had any of the problems that I’m sharing today, I recommend you save this entry on your favorites history—one day it may save your life!

1. The White Screen of Death (WSOD)

The white screen of death (WSOD) is one of the most common errors. Most people have encountered it at some point in their life as WordPress users. Imagine the cold sweat of seeing your website reduced to nothing!

The main causes of this error are the following:

• Exhausted memory
• A plugin
• A theme

Let’s see how you can solve WSOD yourself:

Exhausted Memory

Reaching the limit of memory is usually one of the most common explanations for this error and, if this is the case, increasing the limit is very easy. To do so, access the file  wp-config.php using your client FTP (or cPanel, or whatever you have to see the files of your WordPress installation) and add the following instruction in the label <?php to increase the limit up to 64 Mb:

define( 'WP_MEMORY_LIMIT', '64M' );

Obviously, you can establish any value you want as limit (for instance, 128 Mb or 256 Mb…), but I don’t recommend you put a much higher value—WordPress should properly work with this amount of memory and, if it doesn’t, it’s very possible there is another problem. If so, then we have to analyze other potential causes.

Plugins

If you continue to have access to the WordPress dashboard, then solving this problem is quite simple. Just go to the section of plugins and deactivate the last plugin you have installed. If this doesn’t solve the problem, it is possible that the error is being generated by another plugin, so we have to figure out which one it is. To do so, deactivate all the plugins at once (you can use the selection box on top of the plugin table to mark them all and then select the action Deactivate). Following, you can activate the plugins one by one until you find which on is failing.

If you don’t have access to the desktop, we’ll have to deactivate the plugins via FTP. Using your preferred FTP client (or, as before, the tool you have to manipulate the files of your WordPress server), go to the directory wp-content and change the name of the folder plugins to plugins-debug. After changing the name, go to your site to verify that everything is working fine. To activate the plugins one by one, go back to the directory plugins (remember that we just changed the name to plugins-debug and therefore the directory plugins doesn’t exist) and move the plugins from plugins-debug to plugins, so that you can find which one is not working. Once you finish, you can get rid of the directory plugins-debug, which should now be empty.

Once you have identified what plugin that is causing the problems, you have several options:

1. Install a previous version that you know doesn’t fail (and avoid updating it).
2. Contact the developer, explain your problem and ask them to correct their plugin. 
3. Replace the plugin with another one with the same feature… but without blank screens, of course ? 

Themes

If we haven’t managed to get rid of the white screen by deactivating the plugins, it’s very possible that the theme is what is failing. Just as in the case of the plugins, if your website stopped working overnight because of a theme, it’s either because your theme has been updated and the update has an error, or because you’ve edited something manually and you’ve made a mistake.

To analyze whether the white screen is generated by a theme, we’ll follow the same steps we did for the plugins. Access the directory wp-content/themes and change the name of the directory of your theme (for example, from my-theme to my-theme-debug) so that WordPress thinks you have uninstallated the theme, and so is obliged to use the default theme (like Twenty Seventeen).

Once you know the problem is caused by the theme, you can take the following actions to correct it:

1. If you have edited the theme manually (usually by adding or modifying it from the file functions.php), I recommend you get rid of the changes. If you’re not sure of what you’ve done or how to go back to the previous state, then reinstall the theme from scratch. And remember that before touching anything of your WordPress (especially if we’re talking about code) it’s very important to make a backup; if something goes wrong, the backup will allow us to go back to the previous state in just a few minutes.
2. Contact the author of the theme and ask for help. 
3. Use another theme. 

If All of this Fails… Activate PHP’s DEBUG Mode!

The best thing that can happen is that none of the previous actions corrects your solution. But it can also happen that they allow you to identify what’s wrong, but you don’t know how to correct it. In these cases, what should we do? Well, the only thing we can do is trying to get more information about the problem. To do so, open the file wp-config.php and search the following line:

define( 'WP_DEBUG', false );

Once you’ve located it, add // at the beginning:

// define( 'WP_DEBUG', false );

so that it becomes a comment. Next, add the following statements:

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );

which will activate the information of PHP’s DEBUG. Thanks to this, when you access your website you won’t see a white screen anymore, but you’ll be able to see the errors in the PHP code that are keeping your website from properly working, as well as the files and lines where the errors are.

If you don’t want this information to appear on your website, you can avoid it showing on the browser and make it appear in a log file by adding these two additional lines:

define(  'WP_DEBUG_DISPLAY', false );
@ini_set( 'display_errors', 0 );

With them, all the log information will appear in a file called error.log, which you will find in the directory wp-content.

2. INTERNAL SERVER ERROR

Sometimes, your server responds with an error 500, Internal Server Error. In those cases, the best thing you can do is get up, go get a coffee and come back with a lot of patience because it could be anything.

Again, Blame One of the Plugins, a Theme, or Exhausted Memory

Yes, sometimes errors introduced by plugins or themes don’t end up in a white screen, but show the feared error 500 instead. In these cases, the only thing you can do is repeat the steps we have described in the previous actions…

Correct the File .htaccess

It’s not a plugin’s fault? Nor a theme’s? Well, don’t despair—maybe what failed was your .htaccess file. In these cases it’s better to start from scratch. Access the system of your WordPress files via FTP and change its name to, for instance, .htaccess_backup. If you can’t find it, it’s probably hidden; make sure you select the option “Show hidden files” on your FTP program.

Once you’ve “deleted” the file (in reality, we’ve just changed its name ?), go the dashboard of WordPress » Settings » Permalinks and press Save changes. The change in settings automatically regenerates the file .htaccess, and so this way you can validate that the new version works correctly.

3. ERROR ESTABLISHING DATABASE CONNECTION

Another typical error we may find. This is usually an error of the server, but sometimes it’s something as stupid as not having changed the user and/or the password of the database, and so WordPress cannot access it.

Review the file wp-config.php

The first thing you have to do is check if the error appears only on the public part of your website or also on the dashboard (wp-admin).

A) If it only comes up on the public side, and in addition you see a text like “the database needs to be repaired“, then you just need to add the following line to your file wp-config.php:

define(  'WP_ALLOW_REPAIR', true );

Next, visit this page of your website http://yoursite.com/wp-admin/maint/repair.php and follow the steps to repair the database. Once you’ve finished, don’t forget to eliminate the line we just added to wp-config.php.

B) If you’ve changed the user name or the password of your database, make sure the information in wp-config.php on the database is correct:

define( 'DB_NAME', 'database-name' );
define( 'DB_USER', 'database-username' );
define( 'DB_PASSWORD', 'database-password' );
define( 'DB_HOST', 'localhost' );

In the previous example, I took it for granted that the server with the database is the one executing WordPress (hence, the use of localhost), but this is not always true.

Contact Your Hosting Provider

If nothing solves the problem, or the error appeared after a peak in traffic, then it’s very possible that it is your hosting provider that’s stopping the access to the database. Contact them and ask them for help—it’ll be quicker and easier!

4. Error with Automatic Updates

WordPress 3.7 introduced the automatic updates with the aim of promoting better safety and facilitating the implementation of new versions. By default, only minor updates (those of maintenance or safety) are automatically done. Sometimes, these updates fail. Keep in mind that they’re carried out without any human interaction. So how can we know if there’s been a problem in them? Well, because of the following reasons:

1. A PHP error appears
2. Your website has gone blank (again, the dreadful WSOD, about which we’ve already talked)
3. There is a notice informing you of the error

There are several reasons why the automatic update may fail, but the most common ones are a weak internet connection, or that the permissions of the files and directories are not the suitable ones, and so they cannot be overwritten with the new version.

Manual Update

Like everything in life, if it doesn’t work automatically, try doing it manually ?. I guess you’ve already manually installed a WordPress before, but if you haven’t, on the Codex you’ll see how to update WordPress manually.

5. WordPress Posts with Error 404

One of the most frustrating errors comes up when we try to access the posts of our blog or a page on our website and we obtain the error 404. This type of errors appear when the server doesn’t find the source we’re asking for, either because it doesn’t exist or because it doesn’t know where to look for it. In the case of WordPress, the most probable cause is that the file .htaccess is corrupt. Let’s see what we can do to repair this!

Correcting Our Permalinks

We have already seen how to make WordPress automatically regenerate the file .htaccess. If this doesn’t solve our problem (to be honest, I’d be surprised if it didn’t), we can try to create it manually and add the following content:

# BEGIN WordPress
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>
# END WordPress