What do you do if you can’t log in to WordPress admin? Recently, on a client’s WordPress site hosted on their own Network Solutions server, we were unable to log in. The WordPress login page kept refreshing instead of allowing us to access the admin area. We couldn’t get past the login page no matter what we tried. So what did we do? Read on!
Prerequisites for troubleshooting this issue:
- Know how to back up your WordPress website.
- Have FTP access and be comfortable editing the wp-config.php file.
- Optional: Have access to the hosting control panel to verify database size (if host provides that information).
This is how we investigated and then fixed this issue where we were unable to log in to the WordPress admin area:
1. First, we opened the wp-config.php file located on the server where the WordPress installation lives.
We found this line:
define('WP_DEBUG', false);
And replaced it with:
define('WP_DEBUG', true);
define('WP_DEBUG_LOG', true);
define('WP_DEBUG_DISPLAY', false);
define('SCRIPT_DEBUG', true);
@ini_set('display_errors', 0);
2. Then we went back to the WordPress login page, and tried to log in.
3. When that failed again, we went to view the “debug.log” file on the server, located in wp-content/, to see what we could find.
4. Turning on debug in wp-config showed errors like this in the log:
[18-Apr-2017 18:17:20 UTC] WordPress database error UPDATE command denied to user ‘XXXXXX’@’XXXXXX’ for table ‘wp_options’ for query UPDATE `wp_options` SET `option_value` = ‘1’ WHERE `option_name` = ‘rs_tables_created’ made by require(‘wp-blog-header.php’), require_once(‘wp-load.php’), require_once(‘wp-config.php’), require_once(‘wp-settings.php’), do_action(‘plugins_loaded’), WP_Hook->do_action, WP_Hook->apply_filters, call_user_func_array, RevSliderFront::createDBTables, update_option
[18-Apr-2017 18:17:21 UTC] WordPress database error INSERT, UPDATE command denied to user ‘XXXXXX’@’XXXXXX’ for table ‘wp_options’ for query INSERT INTO `wp_options` (`option_name`, `option_value`, `autoload`) VALUES (‘_transient_woocommerce_cache_excluded_uris’, ‘a:6:{i:0;s:5:\”p=667\”;i:1;s:6:\”/cart/\”;i:2;s:5:\”p=668\”;i:3;s:10:\”/checkout/\”;i:4;s:5:\”p=669\”;i:5;s:12:\”/my-account/\”;}’, ‘yes’) ON DUPLICATE KEY UPDATE `option_name` = VALUES(`option_name`), `option_value` = VALUES(`option_value`), `autoload` = VALUES(`autoload`) made by require(‘wp-blog-header.php’), require_once(‘wp-load.php’), require_once(‘wp-config.php’), require_once(‘wp-settings.php’), do_action(‘init’), WP_Hook->do_action, WP_Hook->apply_filters, call_user_func_array, WooCommerce->init, do_action(‘before_woocommerce_init’), WP_Hook->do_action, WP_Hook->apply_filters, call_user_func_array, WC_Cache_Helper::prevent_caching, set_transient, add_option
At first glance, these appear to be permissions issues. But we were able to log into the database directly through PhpMyAdmin, but we were unable to grant any extra permissions to the user.
5. So then we logged into the Network Solutions hosting control panel. The “Database Manager” area listed out the database, and showed the database size was listed at “300.24 of 300MB allowed.” Ah-ha! The root cause of this issue was that the WordPress admin area became inaccessible because the database size exceeded the size allowed by their hosting company (in this case, Network Solutions). This is why we recommend hosting your WordPress website with us.
WARNING: Before making ANY database changes: be sure you have a full database backup AND that you know how to restore it if necessary.
We recommend UpdraftPlus or WP-DB Manager for this purpose.
So how did we solve this issue?
We reduced the size of the database by:
- Deleting revisions from the posts and postmeta table.
- Deleting transients from the options table.
There are plugins that can help you do this, but make sure you have backed up your database before using them.
The change didn’t take effect immediately. It took a few hours for the server to recognize the size had been effectively reduced.
But those changes alone brought the site from 300.24MB to 80MB.
Network Solutions noted the new database size in their control panel database management area:
And then we were able to log in to the admin area of the WordPress site again.
This happened on Network Solutions, but could happen on other hosts where they limit the size of the database. This might be something to keep in mind if you’re in the market for a new WordPress host.
Tips for prevention:
- Use a plugin to automate database repair and optimization. WP-DBManager can do this on a schedule, while also emailing you database backups.
- In your wp-config.php file, limit the number of revisions stored in the database by adding this line (change 3 to the number of revisions you’d like to store — we recommend no more than 10):
define('WP_POST_REVISIONS', '3'); - Use a plugin to clear out transients from the wp_options table, or periodically log into your database and clear them out manually.
Reminder:
After you have finished debugging the issue, don’t forget to turn debugging back off in wp-config.php by removing the lines you added and re-adding define(‘WP_DEBUG’, false);
This is only one possible solution to the issue of being unable to log into your WordPress admin area. Using the debug constant in your wp-config.php file can help you look into other possible reasons for this issue.
If you’re having trouble with this or another issue on WordPress and need a hand sorting it out, we can help.
Still looking for help because you can’t log in to WordPress admin? Check out WP City’s article for more possible solutions.
