How to fix WordPress showing the install screen after installation

When WordPress keeps showing the installation screen after having installed WordPress, you have to check

1. if the database tables of your WordPress installation do exist and are accessible.
2. if you are missing permissions for your database tables.
3. if your database tables are corrupted.

Do you have every been presented with the WordPress installation screen after you have installed WordPress?

In almost all cases a configuration problem inside your wp-config.php file exists. Nonetheless there might be cases, when you are having permission issues or defect database tables.

This article describes the in-depth reason for this issue and how to fix it in your environment.

Why does WordPress redirect to the installation screen?

I assume that ${PREFIX} is equal to the value of $table_prefix in your wp-config.php. This keeps the naming convention in this article consistent.

WordPress has two methods which decide if WordPress is installed or not:

1. wp_installing() in wp-includes/load.php
2. is_blog_installed() in wp-includes/functions.php

wp_installing returns true, if the constant WP_INSTALLING is defined. This is the case when the installation screen is showed up. WordPress uses the constant mainly to prevent errors for XMLHTTP requests during the installation.

The function is_blog_installed is more complex. WordPress checks if the option siteurl is available:

1. The table ${PREFIX}_options does exist
2. and the option siteurl can be loaded from the ${PREFIX}_options database table

If the ${PREFIX}_options table does not exist or the option siteurl is empty but other WordPress databases tables do exist, you are presented with WordPress’ repair screen. You will receive the following error:

One or more database tables are unavailable. The database may need to be repaired.

That being said: Seeing the installation screen is good. WordPress can connect to the database. The MySQL hostname, username and password values in your wp-config.php are correct. The installation screen is showed due to other reasons.

1. Check the $table_prefix in your wp-config.php

The obvious reason is a mismatch:

• You have set the global variable $table_prefix in your wp-config.php
• Your database tables don’t use the defined $table_prefix.

You can fix it by opening your wp-config.php. Search for the string $table_prefix. The corresponding line will look like the following:

In the screenshot above, the prefix for all of WordPress tables is wp_.

Now open a command line (or a tool like MySQL Workbench or phpMyAdmin). On your command line connect to the MySQL database:

mysql -h ${HOST} -u ${USERNAME} -p ${DATABASE}

Type

SHOW TABLES;

to list each table of your WordPress database. You will receive the following output:

As you can see, the prefix of each table (e.g. wp_options) matches the $table_prefix defined in the wp-config.php. When changing $table_prefix to something like wp_error_ you would be instantly redirected to the installation screen.

A common mismatch between the $table_prefix and your database tables comes from importing an SQL dump from a different host. If you are using a hosted WordPress environment, the prefix is often randomly generated. Your SQL dump contains the prefix for each database table. If you have just downloaded a fresh WordPress ZIP file, your wp-config defaults to wp_, but not to the randomly generated prefix of your hoster.

2. Case-sensitivity of table names and prefixes

Did you know that MySQL database table names are case-sensitive in Linux environments? This is tricky one if you are used to Windows environments. On Windows, the case-sensitivity of files do not matter.

You need to know that each table of your MySQL, MariaDB or Aurora installation has atleast two physical files on the hard drive. The first part of the filename of these files is equal to the table name plus a filename extension.

On Linux, files in the file system are always case-sensitive. This means you can have two files “a.txt” and “A.txt” in the same directory. On Windows this would not work.

If you now have a mismatch in your upper-/lower-case spelling of your $table_prefix configuration and are in a Linux environment, you get in trouble. A $table_prefix wP_ (please note the upper-case P) will not work with a database table wp_: MySQL/Linux can’t find the underlying database table file in the filesystem.

You can easily fix it by comparing the cases of all letters between your $table_prefix configuration and the installed tables.

3. Custom user or user_meta table

You can configure WordPress to use a custom user and user_meta table. This is a feature to share users between different WordPress installations. Check you your wp-config.php for any occurences of CUSTOM_USER_TABLE or CUSTOM_USER_META_TABLE like the following:

define('CUSTOM_USER_TABLE', 'my_user_table');
define('CUSTOM_USER_META_TABLE', 'my_user_meta_table');

If one or both of the custom tables do not exist, WordPress will redirect you to the installation screen.

4. Missing permission for database user

WordPress requires a database user with permissions to execute a SELECT statement. With

mysql -h ${HOST} -u ${USERNAME} -p ${DATABASE}

SHOW GRANTS FOR ${USERNAME};

you can show, which permissions the user has. In the following screenshot, the user wp_install_redirect misses the SELECT permission:

If you are missing the SELECT permission too, you can grant the permission by executing

mysql -h ${HOST} -u ${USERNAME} -p ${DATABASE}

GRANT SELECT ON ${DATABASE}.* TO '${USERNAME}'@'%';
SHOW GRANTS FOR ${USERNAME};

Depending upon permissions set for specific tables, the installer screen may look different. The installer screen may show, that the User(s) already exists:

5. Database tables are corrupted

In some, rare cases your database tables are corrupted. This can happen due to a hard drive defect, a bug in the filesystem or maybe an unclean shutdown of MySQL. When you are issuing a SHOW TABLES command as described above, you will see all tables. If you are trying to execute DESCRIBE $table, the statement will fail.

As described in the official MySQL documentation, you can check every table and try to repair them:

mysql -h ${HOST} -u ${USERNAME} -p ${DATABASE}

CHECK TABLE ${TABLE};
REPAIR TABLE ${TABLE};