In November this year, it will be 3 years since I joined the Kinsta.com team, which for me is honestly an incredible milestone. Last year, I was promoted to Senior Support Engineer and Malware Specialist and this year I was moved to Malware & Abuse Engineer, a title that I am loving and that represents what I love doing: Fixing WordPress sites and Cleaning Malware.

During my time in Sears.com.mx, Site5.com, Sucuri.net, and Kinsta.com, I have learned a lot about troubleshooting WordPress and I wanted to share them here, as I always find myself coming back to some of my own old articles when memory falls short.

#1 Logs are EVERYTHING

Commonly, customers jump to live chat or ticket to request help with a problem without first even checking on the logs. I understand that people get afraid and run for help, we are all humans. My job as a Support Engineer is NOT ONLY to solve the problem, but it is also to EDUCATE the customer, developer, administrator or site owner on how to use the logs to understand what is causing the error.

WordPress is written in PHP, and PHP has a file where it outputs all the errors, this file is called error.log. It is a very important file and you will need to check with your hosting company or system administrator to check exactly where this file is located on your server.

PHP has several types of errors, the most important which usually breaks sites and generates HTTP Error 500 is the dreaded PHP Fatal error. This error can break a WordPress site or a site functionality due to a plugin giving such error. Be sure to read the error as it will usually tell you if the error is on wp-config.php, a plugin, a theme or a WordPress core file.

If the error is on a plugin, then you can disable the plugin several ways:

1. Via FTP/sFTP/SSH by simply renaming the plugin folder name to something else. I usually append the suffix -disabled. For example, if the plugin folder is /wp-content/plugins/akismet/

   I would rename it to /wp-content/plugins/akismet-disabled/


    

2. That will automatically disable the plugin and the error should go away and the site could render normally. If not check the error.log again to see the new error.
3. If your host has wp-cli installed, then you can run this from your website root directory wp plugin deactivate akismet --skip-themes --skip-plugins
   This command will deactivate the plugin Akismet and avoid conflicts with themes and plugins. You can check on your site now, and it will hopefully render fine again. If not, please check the error.log once again.
4. If the problem is a faulty theme, then you can revert to a WordPress default theme like TwentyNineTeen. You can install it and activate it via wp-cli with this command:

   wp theme install twentynineteen –activate

   If this gives an error you can try running with these two extra statements

   wp theme install twentynineteen –activate --skip-themes --skip-plugins

   This command should have set twentynineteen as the default theme of your site and it should hopefully render again. Please check it on your browser and if you still see errors, review your error.log for further information.

#2 WP DEBUG will save you

When you are troubleshooting errors on your WordPress website, you can make use of the built-in debugging mode called WP_DEBUG. This so debugging mode is quickly and easily enabled by adding this to your site wp-config.php :

define( 'WP_DEBUG', true );

You can add this either via FTP, sFTP, SSH or a web-based File Manager (like the one from cPanel, Plesk and similar). Once you added the statement, simply save the file and go to your website, you should now see all the errors on screen.

If you do not want your visitors to see the errors on-screen, luckily WordPress has you covered as well, it comes with a way to hide the errors and send them to a special file so you can read them without the users knowing the debugging mode is enabled. You will need to add these 3 statements instead of the one I shared earlier:

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

As usual after adding them, simply save the wp-config.php file. These statements will force WordPress to send all errors to a file named debug.log which is stored in the wp-content folder. You will be able to download the file to your computer via FTP/sFTP/SSH or FileManager depending on your hosting server capabilities and be able to open the file on your favorite text editor to review.

For further information about WP-DEBUG, please check out these articles:

Official WordPress Codex page about WP DEBUG
Kinsta Knowledgebase – WordPress Error logs

Next week, I will continue with Part 2 🙂