Top 8 Common WordPress Errors and How to Fix Them
Common WordPress Errors and their Solutions.
1. “Just another WordPress blog”
This is the default tagline in WordPress that’s set during installation.
First of all, leaving it visible on the blog is probably the most basic beginner error ever, but you should also check out the source view.
Various theme frameworks display the tagline in the source even if it is hidden on the front-end design.
The best way of fixing this is to simply set a personalized and meaningful tag line (it is under the settings menu in WP admin), therefore even if it gets shown somewhere eventually, it will not hurt your brand by any means.
2. Default encryption keys
In a nutshell, the encryption keys safeguard your session from becoming hijacked by hackers. They are placed in the wp-config.php file and are created automatically during installation.
Despite the fact that those keys are distinctive and unique, there is some danger when you do not manually set a new one. Mainly, you never know if your WordPress package has not been tweaked by somebody before it got to you.
If you include new security keys after the installation, you are essentially making your sessions hyper-safe for years to come.
You can acquire a new set of keys in: https://api.wordpress.org/secret-key/1.1/salt/
3. Not including a custom favicon
No matter what theme you use when running your site, there’s always going to be some default favicon integrated. Theme developers care about their own brands so they always offer something that indicates where the theme comes from.
However, you should always remove it right off the bat and include a brand new favicon that represents your personal brand.
Favicons are commonly shown in browser’s tabs as well as bookmarks. Essentially, a favicon is the fastest way of identifying a website.
The most common method is to turn the site’s logo into a favicon, save it as a 32 by 32 pixel image, and convert to .ico (there a few online converter tools available).
Note. A couple of years ago 16×16 pixel had been enough, but now, with Retina displays and all, the new file format of 32 x 32 is a lot better choice.
4. Losing your admin password
This can be difficult. It’s a very popular mistake. Recovering your admin security password isn’t actually that hard, but it always takes a short while and it can become really difficult if you need some administrative tasks handled RIGHT NOW.
There are three ways of solving this problem:
(1) You may use the recovery mechanism built-in WordPress. Just go to your wp-login panel and click the “Lost your password” link.
(2) If that doesn’t work (I don’t know why, however sometimes it just doesn’t), you can perform a manual reset via phpMyAdmin. Your web host ought to provide you with an URL. Go to the wp_pbgt_users table and edit the row related to your admin user.
After you type in the security password, select the MD5 hashing function from the dropdown next to the password field. Hit “Go” and you are done.
5. “Headers already sent” Error
This is one of the more common issues during development or website setup for websites operating on PHP.
The most irritating thing about it is that whenever you get hit by this issue, nothing seems to work, and no matter what you do to fix it, it has no effect at all.
With regard to problems where nothing looks like it works, the solution is usually very simple (just to annoy us even more, probably).
In WordPress, most “headers already sent” problems could be tracked down to the wp-config. php file.
The most common option would be the following:
- Make sure that the <? Php tag is positioned in the first line of the file,
- Remove all spaces before the opening <? php Make sure that the last characters of the file are ? >
- Really, it’s that simple 90% of the time…
6. RSS feeds taking forever to update
Usually, RSS feeds get updated instantaneously every time a new piece of content gets published. With the exception that sometimes they do not.
(To notice this problem, you must be subscribed to your feeds. )
The most common reason why feeds don’t get updated could be the use of caching plugins. Although they are great for many things, caching your own personal feeds is not one of them.
For W3 Total Cache, click on Performance > Web page Cache and uncheck the “Cache feeds” box.
7. “Memory exceeded” problems
Every now and then, you will see a message informing you that the allowed memory size of XXXXX has been exhausted. Based on the place where the error comes up it can result in just a caution message recorded in the log, or even a complete crash.
Regrettably, this is a problem that’s not necessarily solvable on your side.
In theory, you can edit your php.ini file on your server, however in practice no web host will grant you full access to it. The line to use (if you have the opportunity):
memory_limit = 64M;
If you do not have any control over the php. ini file, there are a few more solutions you can try.
The first is in your. htaccess document. Try using a line such as:
php_value memory_limit 64M;
Additionally, you can go to your wp-config.php file and use this line:
define(‘wp_pbgt_MEMORY_LIMIT’, ’64M’);
However, there is no guarantee that any of these works.
As it turns out, the best option would be to debug the problem and discover the real source. Which leads me to:
8. The white-colored screen of death
The white screen of death in WordPress is like the blue screen of death in Windows … as in: you do not know what is happening and you don’t know what to do about it either.
In WordPress, the white screen of death is when none of the site gets shown, not even when you look at the HTML source code view.
The absolute quickest way of finding the cause of the issue is to, first, enable the debug mode by putting these lines in your wp-config. php file:
define(‘wp_pbgt_DEBUG’, true); //enter debug mode
define(‘wp_pbgt_DEBUG_LOG’, true); //debug to a debug. log file located in wp-content
define(‘wp_pbgt_DEBUG_DISPLAY’, false); //don’t display any debug info on the actual screen
And then recreate the precise conditions before the crash. For example, if the white screen occurred after activating a theme or perhaps a plugin then simply delete this via ftp, activate it again and find out what happens.
If the site crashes again, one of the last lines in the debug log will tell you what’s going on exactly.
Should you be unable recreate the pre-crash circumstances then start by renaming your own plugins directory to like “plugins2″ or whatever else you want.. (The idea is to turn off all plugins at once)
Then create a new “plugins” directory and start copying (and activating) the plugins 1 by 1. When the crash happens once again, you have your solution within the log file.
If the concern is not linked to plugins, look at your current theme as well and repeat the same process.
Getting a solution for the white display screen of death crash may take a while.
What’s your experience with common WordPress problems as well as difficulties? Is there something else really worth mentioning here? Feel free to post your questions in the comment below!!
