WordPress has a lot of moving parts and sometimes the gears just don’t mesh quite right.
There are a few things you can try before calling in the big guns (paying someone to help).
Most errors are caused by plugin updates.
So, the first step toward identifying whether a plugin is at fault is to deactivate all plugins.
“But I can’t deactivate my plugins to fix my site. Help!!!”
If you can’t deactivate your plugins from the WordPress dashboard because it seems your site has literally disappeared, then try renaming your plugins directory via your hosting company’s File Manager app or via FTP.
After renaming your plugins directory, check your home page to see whether it loads nicely (or not).
Side note. Not shown in the video above, you may have a directory named mu-plugins. This mu-plugins directory is a secondary directory for plugins, which may have been added by your host or a web designer. If the above does not resolve the error, try renaming the mu-plugins directory as well.
“Eureka! It was a plugin that broke my website. Now what?”
Troubleshooting is easy enough. Create a new directory named plugins.broke, move all of your plugins into the plugins.broke directory, then move a few plugins at a time back into plugins until you identify the culprit.*
* You may find my plugin, The Hack Repair Guy’s Plugin Archiver helpful in testing various plugins as well.
“What if it’s not a plugin that broke my site?”
Plugins are not the only breaking point in an otherwise smooth sailing WordPress site. Older WordPress themes may cause your site to fail as well.
Theme failures are a rare event. More often than not, you’ll only see a theme cause failure following a major WordPress version update, or after a site has been compromised by an enterprising but not so clever hacker.
With theme failures, you’ll nearly always see a reference to the theme directory name appearing as text on your homepage or dashboard. And when errors do not appear as expected, activating a default WordPress theme may help to verify whether the original theme is to blame or not.
Fixing theme errors can be a challenge. Replacing the theme with a clean backup copy would be my first recommendation.
If recovering from backup is not an option, you may need to hire a WordPress developer to assist, since it’s likely some coding may need to be corrected for the theme to function properly.
The Dreaded “Warning: Cannot modify header information – headers already sent” Error
The “Warning: Cannot modify header information – headers already sent by (output started at” error nearly always relates to spaces either in your wp-config.php or one of your theme’s files.
If you have recently made a change to one of your theme’s files I recommend checking the top line and bottom line for extra line breaks or spaces. If you’ve made no changes recently, then check the top and bottom line of your wp-config.php file for extra lines or spaces. Remove the extra spaces or lines, save the file, then review your home page or WordPress dashboard login page once again. Hopefully that solved that.
The Irritating #*%!
Disappearing coding errors.
Some errors in WordPress are simply warnings. The errors “… is deprecated” or “WP_Widget is deprecated” are relatively easy to resolve. Deprecation Errors are simply coding errors associated with outdated PHP coding.
To prevent these types of errors from appearing on your pages or dashboard, log into your hosting company’s File Manager app, or via FTP. Once there, make a just-in-case backup of the WordPress configuration file wp-config.php , then edit wp-config.php.
Near the bottom of the wp-config.php text file you’ll see the line:
define( 'WP_DEBUG', false );
Change this line to read false, like the example above, save the file, then check to see whether the errors have disappeared from top of your page.
If after ensuring WP_Debug setting within wp-config.php is set to false and the errors remain, try suppressing error display.
To suppress error display, just add a couple of lines below define( ‘WP_DEBUG’, false ); like this:
// Disable display of errors and warnings define('WP_DEBUG_DISPLAY', false); @ini_set('display_errors',0);
Side note about error logging:
If, on the other hand, you wish to log errors for future review, then set WP_DEBUG to true.*
define( 'WP_DEBUG', true);
and add this additional line for logging errors:
/ Enable Debug logging to the /wp-content/debug.log file define('WP_DEBUG_LOG', true);
* Now be careful with this one, as it may create a large log file if you forget to disable this setting.
A word about caching.
By all accounts caching is a good thing. Plugins like W3 Total Cache, and external services like Cloudflare are great for pepping up an occasionally sluggish website. When troubleshooting, it’s best to disable all caching. With Cloudflare for example, you can purge the cache or temporarily disable Cloudflare caching.
Worst case options?
- Recover your entire website and database from an earlier backup.
- Overwrite just the core WordPress files and directories.
- Hire an expert to ride in on his/her white horse and save the day.
I’ve posted a few related article links below. If you have questions just pick up the phone and call anytime, Jim Walker, The Hack Repair Guy, (619) 479-6637
- How do I reset my WordPress password?
- How can I improve the performance of my WordPress website?
- Protecting WordPress Against Brute Force and Denial of Service Attacks
*This review is 100% affiliate link free. Plugin authors were not asked to contribute to this review. No monies were paid to write this article. And a Thank You out to a few folks who helped me in proofreading and editing: Leslie Surel, Joyce Walker, Elizabeth Pampalone. Testing and verification of the settings presented above were graciously provided by Lovingfit.com