This page lists the most common WordPress errors experienced by WordPress users, and provides a starting point for fixing them. At
WordPress Support, you will also find links to more detailed pages or forums where a volunteer will be there to help.

The White Screen of Death #

Both PHP errors and database errors can manifest as a white screen, a blank screen with no information, commonly known in the WordPress community as the WordPress White Screen of Death (WSOD).

Before resorting to desperate measures, there are a number of reasons for the WordPress white screen of death:

• A Plugin is causing compatibility issues. If you can access the Administration Screens try deactivating all of your Plugins and then reactivating them one by one. If you are unable to access your Screens, log in to your website via FTP. Locate the folder wp-content/plugins and rename the Plugin folder plugins_old. This will deactivate all of your Plugins. You can read more about manually deactivating your plugins in the Troubleshooting FAQ.
• Your Theme may be causing the problem. This is especially likely if you are experiencing the white screen of death after you have just activated a new Theme, or created a New Site in a WordPress Network. Log in to the WordPress Administration Screens and activate the default WordPress Theme (e.g. Twenty Seventeen). If you can’t access your Administration Screens, access your website via FTP and navigate to the /wp-content/themes/ folder. Rename the folder for the active Theme.

The WP_DEBUG feature often provides additional information.

Top ↑

Internal Server Error #

There can be a number of reasons for an Internal Server Error. Here are some thing you can do to solve it:

• The most likely issue is a corrupted .htaccess file. Log in to your site root using FTP and rename your .htaccess file to .htaccess_old. Try loading your site to see if this has solved your problem. If it works, make sure to visit Settings > Permalinks and reset your permalinks. This will generate a new .htaccess file for you.
• Try deactivating all of your Plugins to see if it is a Plugin issue. If you are unable to access your WordPress Administration Screens, deactivate your Plugins via FTP by following these instructions.
• Switch the Theme to the WordPress default Theme (e.g. Twenty Seventeen) to eliminate any Theme-related problems.
• Increase the PHP Memory limit
• Try re-uploading the wp-admin and wp-includes folders from a fresh install of WordPress.

Top ↑

Error Establishing Database Connection #

If you get a page featuring the message “Error Establishing Database Connection,” this means that there is a problem with the connection to your database and there could be a number of reasons for this. The following are possible reasons and solutions.

Incorrect wp-config.php Information #

“Error establishing a database connection” is usually caused by an error in your wp-config.php file. Access your site in your FTP client. Open up wp-config.php and ensure that the following are correct:

• Database name
• Database username
• Database password
• Database host

Learn more about editing wp-config.php.

If you are sure your configuration is correct you could try resetting your MySQL password manually.

Top ↑

Problems with Your Web Host #

The next step is to contact your web host. The following hosting issues may be causing the problem:

• Your database has met its quota and has been shut down.
• The server is down.

Contact your hosting provider to see if either of these issues is causing your problem.

Top ↑

Compromised Website #

If you have checked wp-config.php for errors, and confirmed with your host for hosting issues, it is possible that your site has been hacked.

Scan your site with Sucuri SiteCheck to ensure that it hasn’t been compromised. If it has you should check out My Site was Hacked.

Top ↑

Failed Auto-Upgrade #

There will be situations when the WordPress auto-update feature fails. Symptoms include:

• A blank white screen and no information.
• A warning that the update failed.
• A PHP error message.

The WordPress automatic upgrade feature may fail due to a glitch in the connection with the main WordPress files, a problem with your Internet connection during upgrade, or incorrect File Permissions

To update your WordPress site manually, see the Manual Update article.

Top ↑

Connection Timed Out #

The connection timed out error appears when your website is trying to do more than your server can manage. It is particularly common on shared hosting where your memory limit is restricted. Here are some things you can try:

• Deactivate all Plugins. If deactivating all the WordPress Plugins on your site resolves the issue, reactivate them one-by-one to see which plugin is causing the problem. If you are unable to access your Administration Screens, read about how to manually deactivate your plugins.
• Switch to the default WordPress Theme. This should rule out any Theme-related problems.
• Increase your memory limit in wp-config.php. If you are on shared hosting you may have to ask your hosting provider to increase your memory limit for you.
• Increase the maximum execution time in your php.ini file. This is not a WordPress core file so if you are not sure how to edit it, contact your hosting provider to ask them to increase your maximum execution time. See below instructions for increasing maximum execution time.

Top ↑

Maintenance Mode Following Upgrade #

When WordPress updates, it automatically installs a .maintenance file. Following upgrade, you may receive a message that says “Briefly unavailable for scheduled maintenance. Please check back in a minute.” The maintenance file may not have been removed properly.

To remove this message do the following:

1. Log in to your website using your FTP program
2. Delete the .maintenance file, which will be found in your site root.

Read more about the maintenance mode issue.

Top ↑

You Make Changes and Nothing Happens #

If you are making changes to your website and you do not see the changes in your browser, you may need to clear your browser cache. Your browser stores information about the websites that you visit. This makes it faster to load websites when you visit them because the browser just has to reload information already stored on your computer, rather than downloading it again.

If you make a change to a website and the browser does not think it is significant, it will simply load the data from your cache, and you won’t see your changes. To fix the problem, simply empty your browser cache or close the tab and reopen the link.

Top ↑

Pretty Permalinks 404 and Images not Working #

If you are experiencing 404 errors with pretty permalinks and a white screen when you upload images, mod_rewrite may not be enabled in Apache by default. Mod_rewrite is an extension module of the Apache web server software which allows for “rewriting” of URLs on-the-fly. It’s what you need to make pretty permalinks work.

WordPress Multisite networks usually experience this but it can also occur on shared hosting providers or after a site migration or server move.

Reset your permalinks through Settings > Permalinks. If this does not work, you may have to edit the .htaccess file manually.

# 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

If you are not familiar with editing your .htaccess file, contact your hosting provider to ask them to turn on mod_rewrite rules. There is more information on pretty permalinks in the WordPress Codex.

Top ↑

Custom Post Type 404 Errors #

You may experience problems with 404 errors and custom post types. Try the following steps:

1. Make sure that none of your Custom Post Types and single pages have the same name. If they do, rename the single page, including the slug.
2. Log in to your WordPress Administration Screens, navigate to Settings > Permalinks. Select the default permalinks. Save. Then reselect your preferred permalinks. This will flush the rewrite rules and should solve your problem.

Top ↑

Specific Error Messages #

There are a number of different errors that will appear in your error logs. To access your error logs you will need to turn on debugging and then locate your error log via FTP. The following information will help you to decipher some of the common error messages.

Top ↑

PHP Errors #

Below are some common PHP error messages.

Fatal Errors and Warnings #

CANNOT MODIFY HEADER INFORMATION – HEADERS ALREADY SENT

If you receive a warning that WordPress cannot modify header information and headers are already sent, it usually means that you have spaces or characters before the opening tags or after the closing tags. Read how to fix the headers already sent error.

If you are experiencing this problem when you have just installed WordPress you may have introduced a syntax error into wp-config.php. These instructions will help you to fix the error.

CALL TO UNDEFINED FUNCTION

An error reading call to undefined function could mean that a WordPress Plugin is trying to find a file or data which isn’t present or accessible in the code. Reasons for this include:

• An error when trying to auto-install or auto-upgrade a Plugin. Try installing or upgrading the Plugin manually.
• An error when trying to auto-install or auto-upgrade a Theme. Try installing or upgrading the Theme manually.
• You may be using an incompatible WordPress Plugin or incompatible Theme. This could happen with older versions of WordPress and a new WordPress Plugin, or if you are trying to use a WordPress Multisite Plugin on a single site installation. Upgrade WordPress to resolve this issue.
• You may be trying to call a function that doesn’t exist. Check functions.php for misspellings.

Try deactivating the WordPress Plugin or changing the WordPress Theme that caused the error to appear. If you are unable to do this from within the Administration Screens, you may have to do this manually via FTP.

ALLOWED MEMORY SIZE EXHAUSTED

An Allowed Memory Size Exhausted error means that your WordPress installation doesn’t have enough memory to achieve what you want. You can try out the following steps:

• Increase your memory limit in wp-config.php
• Increase your memory limit by editing php.ini. This is not a file that comes with WordPress so if you are unfamiliar with it you should contact your web host about increasing your memory limit.

MAXIMUM EXECUTION TIME EXCEEDED

You may receive a message such as “Maximum execution time of 30 seconds exceeded” or “Maximum execution time of 60 seconds exceeded”. This means that it is taking to longer for a process to complete and it is timing out. There are a number of ways to fix this error.

Editing .htaccess

Make sure you back up .htaccess before you edit it.

Add the following line to .htaccess:

php_value max_execution_time 60

Editing php.ini

Add the following to php.ini

max_execution_time = 60

If you are unsure of how to make these changes, or if you are on shared hosting that prevents you from making them yourself, you should contact your hosting provider and ask them to increase your maximum execution time.

Top ↑

Parse errors #

SYNTAX ERROR

A syntax error means that you have made a mistake while creating your PHP structure. You could, for example, be;

• Missing a ; at the end of an individual line.
• Using curly quotation marks.
• Missing a curly bracket.

When this error appears it will tell you which file the error appears in (functions.php for example) and approximately which line (it may not always be the exact line so be sure to check just before and just after) in the code.

UNEXPECTED

If you are receiving an error which says ‘parse error: unexpected’ this usually means that you have forgotten to include a character. The most common are:

• Unexpected ‘=’ : you have forgotten to include the $ when referencing a variable
• Unexpected ‘)’ : you have forgotten to include the opening bracket (
• Unexpected ‘(‘ : you have forgotten to include the closing bracket )
• Unepxpected T_STRING: you have forgotten a quotation mark or a semi-colon at the end of the previous line
• Unexpected T_ELSE: you have an else statement with no opening if statement

Top ↑

Use of an undefined constant #

As with parse errors, “use of an undefined constant” means that you are missing a character. It could be one of the following:

• Missing a $ when referencing a viariable
• Missing quotation marks around array keys

Top ↑

Database Errors #

The following errors may appear in relation to your WordPress database.

Top ↑

Error 13 – Cannot Create/Write to File #

There are a number of reasons why you may be experiencing this error.

MySQL cannot create a temporary file. 

The MySQL variable tmpdir is set to a directory that cannot be written to when using PHP to access MySQL. To verify this, enter MySQL at the command line and type show variables. You’ll get a long list and one of them will read: tmpdir = /somedir/ (whatever your setting is.)

To solve this, alter the tmpdir variable to point to a writable directory.

1. Find the my.cnf file. On *nix systems this is usually in /etc/. On Windows system, Find the my.ini.
2. Once found, open this in a simple text editor and find the [mysqld] section.
3. Under this section, find the tmpdir line. If this line is commented (has a # at the start), delete the # and edit the line so that it reads: tmpdir = /writable/dir where /writable/dir is a directory to which you can write. Some use /tmp, or you might also try /var/tmp or /usr/tmp. On Windows, use C:/Windows/tmp.
4. Save the file.
5. Shutdown MySQL by typing mysqlshutdown -u -p shutdown.
6. Start MySQL by going to the MySQL directory and typing ./bin/safe_mysqld &. Usually the MySQL directory is in /usr/local or sometimes in /usr/ on Linux systems.

The file permissions are incorrect

Correct the File Permissions.

If none of this make sense and you have someone to administrate your system for you, show the above to them and they should be able to figure it out.

Top ↑

CREATE Command Denied to User #

This error occurs when the user assigned to the database does not have adequate permissions to perform the action to create columns and tables in the database. You will need to log in to CPanel or Plesk to give your database user adequate permissions.

Alternatively you can create a new user to assign to your database. If you do create a new user you will need to ensure that it is updated in wp-config.php.

Top ↑

Error 28 #

It could be because:

• you are out of space on /tmp (wherever tmpdir is), or,
• you have too many files in /tmp (even if there is lots of free space), or,
• Your cache on your server is full

This is a MySQL error and has nothing to do with WordPress directly; you should contact your host about it. Some users have reported that running a “repair table” command in phpMyAdmin fixed the problem.

Top ↑

Error 145 #

This indicates that a table in your database is damaged or corrupted. If you are comfortable using phpMyAdmin you can use .

Always backup your database before performing any actions on it.

If you have not used phpMyAdmin before, or are uncomfortable doing so, contact your web host and ask them to run CHECK/REPAIR on your database.

Top ↑

Unknown Column #

An unknown column error can be caused by a missing column in the database. If you have just upgraded WordPress then try manually upgrading again. To update your WordPress site manually, see the Update article.

If you are running a database query when you encounter the error then you may by using incorrect quotation marks for the identifier quote character. This question on Stack Overflow provides more details. Also see the MySQL documentation.

Top ↑

Resources #

• MySQL Error Codes and Messages

The post Common WordPress Errors first appeared on CODIBU.

Enable Cookies #

In order to make sure that cookies are enabled for your browser, you need to:

1. Clear your browser cookies.
2. Clear your browser cache.

To see how to clear cookies and caches on various browsers, visit Clearing Cache and Cookies.

Top↑

WordPress MultiSite Network #

• Check your wp-config.php file.
• Verify the DOMAIN_CURRENT_SITE value.

Top ↑

Disable Plugins #

Some WordPress Plugins may interfere with the login process. Disable all of your WordPress Plugins, either through the Administration Screen or by removing them from the /wp-content/plugins/ folder, so they will not be recognized by the program.

Alternatively, you can rename the plugins folder to something else temporarily to something like

/wp-content/pluginsXX/ and they will not be recognized. Rename the folder back to /wp-content/plugins/ once the base WordPress installation has been recovered.

Top ↑

Deactivate Theme #

• Rename the active theme folder (in wp-content/themes) by using FTP. Once renamed, WordPress will revert to using the {{DefaultTheme}}. When finally logged in, change to a different theme.
• To find out what caused problem in the theme, upload and run this code when the theme is active:

Top ↑

New Login File #

Sometimes the wp-login.php file may have been corrupted or uploaded incorrectly.

• Delete wp-login.php off of your server and upload a new copy from a fresh WordPress download. Remember, overwriting file via FTP can lead to incomplete transfers.
• Edit wp-login.php as follows:
  • Go to the case retrievepassword section, found under this comment:

Replace:

With:

Top ↑

Edit Users Table #

Access your site’s phpMyAdmin and edit the database carefully.

• Open the WordPress database.
• Click on the users table in the left menu (default is wp_users, or yourprefix_users if you defined a different table prefix.)
• Click BROWSE.
• Click on the EDIT button next to the admin user.
• Delete whatever is in the password field.
• Enter your desired password.
• From the Function drop-down list, choose MD5.
• Save the info in the database.
• Log in to WordPress using “admin” and the password you used.
• In the case of newer versions of WordPress, the password is double hashed, but as long as you md5 the password, it will complete the hash (it upgrades your password for you).

Top ↑

Password Problems #

For information on problems logging in due to a wrong or lost password, see Resetting Your Password. Remember: the Username and Password fields are case sensitive.

Top ↑

Site URL Redirecting #

In certain cases your WordPress address URI may have been reset.

• Check the siteurl value in the wp-options table of your WordPress database. A guide to doing this is available here.
• Is it set as http:/?
• If it is, change siteurl to the correct value.
• Open wp-login.php in a text-editor and comment or delete the following lines:

Changed your WordPress address URI and cannot login nor access the database (but still can access the login page) ?

wp-login.php can be used to reset the address:

Top↑

Subdomains or Subdirectories #

In your wp-config.php try changing from:

To:

Top ↑

Headers Already Sent #

If you get an error about headers already sent, see Solving the Headers Already Being Sent Problem.

Top ↑

Check Your URL Options #

In some situations, your blog can be seen from inside your domain, but not outside. Following the instruction above about changing the wp-options MySQL table might still result in login failure.

In this event, double-check your wp-options table siteurl (WordPress address URL) and home (Blog Address URL) values to make sure they reference the same base externally available address; i.e., http://blog.yourdomain.com. The standard install may set them to your local (internal) host name, such as http://servername

Another issue may be if you are redirecting using .htaccess from a non-www url prefix to a www while you have the wp-options table siteurl (WordPress address URL) and home (Blog Address URL) set with non-www prefix. Consequently this would create an endless loop which you need to avoid.

One way is to disable the .htaccess redirection temporarily by placing # before the line or eliminating the entries entirely and trying to Login again.

Advanced users may want to adjust the wp-options table siteurl (WordPress address URL) and home (Blog Address URL) through the database.

Notice that this issue can also occur if you are redirecting from www to non-www but have your wp-options table siteurl (WordPress address URL) and home (Blog Address URL) set with a www url prefix.

Top ↑

Check your Firewall #

Some firewalls (e.g., eTrust Personal Firewall) block you from logging in to WordPress. Disable your firewall and try to log in again.

Top ↑

If All Else Fails #

If these steps fail, please indicate that you have tried all these possible solutions when posting at the WordPress Support Forum. Be sure to give details of your server setup, if you know it, including mySQL and PHP versions, as well as your operating system (OS), browser, and the WordPress version that is causing these problems.

The post Login Trouble first appeared on CODIBU.

For non-programmers or general users, these options can be used to show detailed information about errors.

WP_DEBUG #

WP_DEBUG is a PHP constant (a permanent global variable) that can be used to trigger the “debug” mode throughout WordPress. It is assumed to be false by default and is usually set to true in the wp-config.php file on development copies of WordPress.

// This enables debugging.
define( 'WP_DEBUG', true );

// This disables debugging.
define( 'WP_DEBUG', false );

Note: The true and false values in the example are not surrounded by apostrophes (‘) because they are boolean (true/false) values. If you set constants to 'false', they will be interpreted as true because the quotes make it a string rather than a boolean.

It is not recommended to use WP_DEBUG or the other debug tools on live sites; they are meant for local testing and staging installs.

PHP Errors, Warnings, and Notices #

Enabling WP_DEBUG will cause all PHP errors, notices and warnings to be displayed. This is likely to modify the default behavior of PHP which only displays fatal errors and/or shows a white screen of death when errors are reached.

Showing all PHP notices and warnings often results in error messages for things that don’t seem broken, but do not follow proper data validation conventions inside PHP. These warnings are easy to fix once the relevant code has been identified, and the resulting code is almost always more bug-resistant and easier to maintain.

Top ↑

Deprecated Functions and Arguments #

Enabling WP_DEBUG will also cause notices about deprecated functions and arguments within WordPress that are being used on your site. These are functions or function arguments that have not been removed from the core code yet but are slated for deletion in the near future. Deprecation notices often indicate the new function that should be used instead.

Top ↑

WP_DEBUG_LOG #

WP_DEBUG_LOG is a companion to WP_DEBUG that causes all errors to also be saved to a debug.log log file This is useful if you want to review all notices later or need to view notices generated off-screen (e.g. during an AJAX request or wp-cron run).

Note that this allows you to write to log file using PHP’s built in error_log() function, which can be useful for instance when debugging Ajax events.

When set to true, the log is saved to debug.log in the content directory (usually wp-content/debug.log) within your site’s filesystem. Alternatively, you can set it to a valid file path to have the file saved elsewhere.

define( 'WP_DEBUG_LOG', true );
-or-
define( 'WP_DEBUG_LOG', '/tmp/wp-errors.log' );

Note: for WP_DEBUG_LOG to do anything, WP_DEBUG must be enabled (true). Remember you can turn off WP_DEBUG_DISPLAY independently.

Top ↑

WP_DEBUG_DISPLAY #

WP_DEBUG_DISPLAY is another companion to WP_DEBUG that controls whether debug messages are shown inside the HTML of pages or not. The default is ‘true’ which shows errors and warnings as they are generated. Setting this to false will hide all errors. This should be used in conjunction with WP_DEBUG_LOG so that errors can be reviewed later.

define( 'WP_DEBUG_DISPLAY', false );

Note: for WP_DEBUG_DISPLAY to do anything, WP_DEBUG must be enabled (true). Remember you can control WP_DEBUG_LOG independently.

Top ↑

SCRIPT_DEBUG #

SCRIPT_DEBUG is a related constant that will force WordPress to use the “dev” versions of core CSS and JavaScript files rather than the minified versions that are normally loaded. This is useful when you are testing modifications to any built-in .js or .css files. Default is false.

define( 'SCRIPT_DEBUG', true );

Top ↑

SAVEQUERIES #

The SAVEQUERIES definition saves the database queries to an array and that array can be displayed to help analyze those queries. The constant defined as true causes each query to be saved, how long that query took to execute, and what function called it.

define( 'SAVEQUERIES', true );

The array is stored in the global $wpdb->queries.

NOTE: This will have a performance impact on your site, so make sure to turn this off when you aren’t debugging.

Top ↑

Example wp-config.php for Debugging #

The following code, inserted in your wp-config.php file, will log all errors, notices, and warnings to a file called debug.log in the wp-content directory. It will also hide the errors so they do not interrupt page generation.

// Enable WP_DEBUG mode
define( 'WP_DEBUG', true );

// Enable Debug logging to the /wp-content/debug.log file
define( 'WP_DEBUG_LOG', true );

// Disable display of errors and warnings
define( 'WP_DEBUG_DISPLAY', false );
@ini_set( 'display_errors', 0 );

// Use dev versions of core JS and CSS files (only needed if you are modifying these core files)
define( 'SCRIPT_DEBUG', true );

NOTE: You must insert this BEFORE /* That's all, stop editing! Happy blogging. */ in the wp-config.php file.

Top ↑

Debugging Plugins #

There are many debugging plugins for WordPress that show more information about the internals, either for a specific component or in general. Here are some examples:

• Query Monitor
• Debug Bar
• Log Deprecated Notices

Top ↑

External Resources #

• WordPress ‘wp-config.php’ file Generator
• ‘No White Screen’ plugin: Display the error instead of a white screen

The post Debugging in WordPress first appeared on CODIBU.

• The White Screen
• Internal Server Error
• Error Establishing Database Connection
• Failed Auto-Upgrade
• Connection Timed Out
• Maintenance Mode Following Upgrade
• PHP errors or MySQL DB errors

How to deactivate all plugins when not able to access the administrative menus? #

Sometimes it may be necessary to deactivate all plugins, but you can’t access the Administration Screens to do so. One of two methods are available to deactivate all plugins.

Use phpMyAdmin to deactivate all plugins.

1. In the table wp_options, under the option_name column (field) find the active_plugins row
2. Change the option_value field to: a:0:{}

Or reset your plugins folder via FTP or the file manager provided in your host’s control panel. This method preserves plugin options but requires plugins be manually reactivated.

1. Via FTP or your host’s file manager, navigate to the wp-contents folder (directory)
2. Via FTP or your host’s file manager, rename the folder “plugins” to “plugins.hold”
3. Login to your WordPress administration plugins page (/wp-admin/plugins.php) – this will disable any plugin that is “missing”.
4. Via FTP or your host’s file manager, rename “plugins.hold” back to “plugins”

Top ↑

How to clear the “Briefly unavailable for scheduled maintenance” message after doing automatic upgrade? #

As part of the automatic upgrade WordPress places a file named .maintenance in the blog base folder (folder that contains the wp-admin folder). If that file exists, then vistors will see the message Briefly unavailable for scheduled maintenance. Check back in a minute.

To stop that message from being displayed to vistors, just delete the .maintenance file. The automatic upgrade should be executed again, just in case it failed.

Top ↑

An update was just released, so why does my blog not recognize the update is available? #

When an update is released, notification of that release is displayed at the top administration screens saying WordPress x.x.x is available! Please update now. Not every blog will see that message at the same time. Your blog is programmed to check for updates every 12 hours, but the timing of that check is purely random. So if your blog just checked for updates minutes before an update was released, you won’t see the update message until your blog checks for updates 12 hours later.

If you want your blog to check right now for updates, you can delete the update_core option name record in your wp_options table. Note that plugins and themes each have their own check and update cycle, controlled by the records update_plugins and update_themes, in wp_options.

Relevant discussion thread:

• https://wordpress.org/support/topic/242485

Top ↑

Why did I lose custom changes to the WordPress Default Theme during the last automatic upgrade? #

A core upgrade copies all the new files from the distribution over the old ones, so if you changed existing files in the WordPress default theme (e.g. wp-content/themes/twentysixteen/style.css), those changes got overwritten with the new version of that file.

Please note, a core upgrade goes through a list of “old files”, as defined in wp-admin/includes/update-core.php, and deletes those files. Any files not on the list, and not in the distribution, are preserved.

Remember, that before upgrades, whether automatic or manual, both the WordPress Files and database should be backed-up as explained in WordPress Backups.

A better way to modify the default theme is by using a child theme. It’s a little more work to set up, but worth the effort because your customizations will be safe when the main theme is updated.

Top ↑

How do you repair a MySQL database table? #

Every once in a while, it may be necessary to repair one or more MySQL database tables. According to the How to Repair MyISAM Tables at dev.mysql.com there are a number of reasons to repair a table including errors such as “tbl_name.frm is locked against change”, “Can’t find file tbl_name.MYI (Errcode: nnn)”, “Unexpected end of file”, “Record file is crashed”, or “Got error nnn from table handler”.

Here are the steps to repair a table in a MySQL database using phpMyAdmin:

1. Login to hosting account.
2. Login to phpMyAdmin.
3. Choose the affected database. If you only have one database, it should choose it by default so you don’t need to do anything.
4. In the main panel, you should see a list of your database tables. Check the boxes by the tables that need repair.
5. At the bottom of the window just below the list of tables, there is a drop down menu. Choose “Repair Table”

Remember, that it is advisable to have a current backup of your database at all times. See also WordPress Backups

Top ↑

How do I empty a database table? #

Refer Emptying a Database Table

Top ↑

Emailed passwords are not being received #

Description: When users try to register with your blog or change their passwords by entering their username and/or email, WordPress indicates that their password has been emailed to them, but it is never received.

Reason and Solutions: WordPress uses the standard PHP mail() function, which uses sendmail. No account information is needed. This is not generally a problem if you are using a hosting service, but if you are using your own box and do not have an SMTP server, the mail will never send. If you are using a *NIX box, you should have either postfix or sendmail on your machine; you will just need to set them up (search the Internet for how-to’s). If you do not want to go through setting up a complete mail server on your *NIX box you may find ssmtp useful — it provides “A secure, effective and simple way of getting mail off a system to your mail hub”. On a Windows machine, try a sendmail emulator like Glob SendMail.

More help can be found on this thread of the WordPress Support Forums: https://wordpress.org/support/topic.php?id=24981.

Windows Host Server Specific: Check your “Relay” settings on the SMTP Virtual Server. Grant access to 127.0.0.1 . Then in your php.inifile, set the SMTP setting to the same IP address. Also set smtp_port to 25.

Ensure Proper Return Address is Used: By default, the WordPress mailer fills in the From: field with wordpress@yourdomain.com and the From: name as WordPress.

This is fine if this is a valid e-mail address. For example, if your real e-mail is wordpress@yourdomain.com, your host should pass the email on for delivery. It will probably send your mail as long as yourdomain.com is setup to send and receive mail, even if wordpress is not a valid mail box. But if you set you real email as the From: address and it’s something like wpgod@gmail.com, the mail may not send because gmail.com is not a domain handled by the mail server.

Treated as Spam: Your email message may have been routed to a spam folder or even worse, simply discarded as malicious. There are a couple measures you can use to convince recipient’s mail servers that your message is legitimate and should be delivered as addressed.

SPF: (Sender Policy Framework) This is the most common anti-spam measure used. If you are on a hosted system, there is a good chance your host has set this up for the mail server you are using. Have WordPress email you and check the message headers for evidence that the message passed the SPF check. You can get a message sent by following the Forgot Password link on the login page. To keep your old password, do not follow the link in the message.
If your system email failed the SPF check, you can set up the credentials if you have access to your DNS records and your mail server’s domain belongs to you. Check the return path of the email your system sent. If the mail server listed there has your domain name, you can set up SPF credentials. There are several how-tos on the Internet.

DKIM: (Domain Key Identified Mail) This system is also used. You can use both SPF and DKIM in the same message. Again, just as with SPF, you can check if your receiving mailserver verified your host’s domain key by examining the mail header. There is a fair chance no signature key was provided, indicating your host chose to not use this protocol. Also as with SPF, if you can edit your DNS records and the mail server belongs to your domain, you can set up DKIM credentials yourself. Some how-tos exist if you search the Internet.

Top ↑

Why can’t I see my posts? All I see is Sorry, no posts match your criteria? #

Clearing your browser cache and cookies may resolve this problem. See also I Make Changes and Nothing Happens

Top ↑

How do I solve the Headers already sent warning problem? #

Description: You get a warning message on your browser that says:

Warning: Cannot modify header information - headers already sent by
(output started at

Reason and Solution:

It is usually because there are spaces, new lines, or other stuff before an opening <?phptag or after a closing ?>  tag, typically in wp-config.php. This could be true about some other file too, so please check the error message, as it will list the specific file name where the error occurred (see “Interpreting the Error Message” below). Replacing the faulty file with one from your most recent backup or one from a fresh WordPress download is your best bet, but if neither of those are an option, please follow the steps below.

Just because you cannot see anything does not mean that PHP sees the same.

1. Download the file mentioned in the error message via FTP or the file manager provided in your host’s control panel.
2. Open that file in a plain text editor (NOT Microsoft Word or similar. Notepad or BBEdit are fine).
3. Check that the very first characters are with no blank lines or spaces after it.
4. Before saving, or use the Save as dialog, ensure the file encoding is not UTF-8 BOM but plain UTF-8 or any without the BOM suffix.

To be sure about the end of the file, do this:

1. Place the cursor between the ? and >
2. Now press the DELETE key on your computer Note to MAC users: The “DELETE” key on a PC deletes characters to the right of the cursor. That is the key noted here.
3. Keep that key pressed
4. For at least 15 seconds
5. Now type > and
6. save without pressing any other key at all.
7. If you press another key, you will bring the problem back.
8. DO NOT PUT CODE IN UNNECESSARY CODE BLOCKS, PUT THEM IN A SINGLE PHP BLOCK.

Wrong:

<?php some code; ?> <?php some other codes; ?> 

Correct:

<?php code; some other code; ?> 

Upload the file back to your server after editing and saving the file.

Note: Also check the encoding of the file. If the file is encoded as UTF-8 with BOM, the BOM is seen as a character which starts the output.

Interpreting the Error Message:

If the error message states: Warning: Cannot modify header information - headers already sent by (output started at /path/blog/wp-config.php:34) in /path/blog/wp-login.php on line 42, then the problem is at line #34 of wp-config.php, not line #42 of wp-login.php. In this scenario, line #42 of wp-login.php is the victim. It is being affected by the excess whitespace at line #34 of wp-config.php.

If the error message states: Warning: Cannot modify header information - headers already sent by (output started at /path/wp-admin/admin-header.php:8) in /path/wp-admin/post.php on line 569, then the problem is at line #8 of admin-header.php, not line #569 of post.php. In this scenario, line #569 of post.php is the victim. It is being affected by the excess whitespace at line #8 of admin-header.php.

Top ↑

Why doesn’t my “Publish” or “Save Draft” button work? #

To resolve this and similar issues, disable your plugins one at a time until you find the source of the issue. Generally, this will be due to two or more plugins trying to use the same resources (for example, JQuery or other Java-based tools).

In addition, it could be that there is a problem with your browser. A common resolution is to empty the browser’s cache. Please consult the documentation for your preferred browser to learn how to do this.

Top ↑

How to fix 404 error when using Pretty Permalinks? #

If an error 404 occurs when using the Pretty Permalink choices such as Day and Name in Administration > Settings > Settings_Permalinks_Screen it could be a result of the mod_rewrite module not being activated/installed. The solution is to activate mod_rewrite for the Apache web-server. Check the apacheconfhttpd.conf file for the line # LoadModule rewrite_module modules/mod_rewrite.so
and delete the # in front of the line. Then stop Apache and start it again. Note: you may have to ask your host to activate mod_rewrite.

See also Using Permalinks. Relevant discussion thread is https://wordpress.org/support/topic/234726

Top ↑

Why isn’t the admin user listed as an author when editing posts? #

Not sure why this problem happens, but here’s a couple of things to try one of these two solutions.

This usually fixes the problem:

1. Create new admin user (e.g. newadmin) with Administrator Role
2. Login as ‘newadmin’
3. Degrade the old ‘admin’ user to Role of Subscriber and Save
4. Promote the old ‘admin’ back to Administrator Role and Save
5. Login as the old ‘admin’

If that doesn’t work, try:

1. Create a new admin user (e.g. newadmin) with Administrator Role
2. Login as ‘newadmin’
3. Delete the old ‘admin’ user and assign any posts to ‘newadmin’
4. Create ‘admin’ user with Administrator Role
5. Login as ‘admin’
6. Delete ‘newadmin’ user and assign posts to ‘admin’

Top ↑

Why is the wrong author name displayed for a post on a blog? #

This problem is usually solved by the same solution as is presented in the question right before this one:
Why isn’t the admin user listed as an author when editing posts?

Top ↑

How do I find more help? #

There are various resources that will help you find more help with WordPress, in addition to these FAQ.

• Troubleshooting
• Finding WordPress Help
• Using the Support Forums
• Resources and Technical Articles about WordPress
• Installation Problems

The post FAQ Troubleshooting first appeared on CODIBU.