Database table prefix
The table prefix is the few characters at the start of every WordPress database table's name, wp_ unless it was changed at setup. It is set in wp-config.php and it is also written inside the database, which is why changing it by hand locks administrators out.
- By
- WP Ministry
- Published
In short
- The prefix is set by the $table_prefix line in wp-config.php and starts every table's name. The default is wp_.
- Any SQL you copy from a guide is written for wp_. Change the table names, and any key built from the prefix, to match yours.
- The prefix is also inside the names of the rows that hold roles. Change the prefix without renaming them and no account can open the dashboard.
The table prefix is the text WordPress puts at the start of the name of every table it keeps in its database. The default is wp_, so posts are in wp_posts, settings in wp_options and users in wp_users. One line in wp-config.php sets it:
$table_prefix = 'wp_';It exists so that more than one WordPress installation can share one database: each has a prefix of its own, and their tables never meet. WordPress's documentation says to keep security in mind if you do that. The prefix may hold only numbers, letters and underscores.
Where you meet it
- At setup. WordPress asks for it in a field named "Table Prefix", with the note "If you want to run multiple WordPress installations in a single database, change this."
- In
wp-config.php, on the line above. The wp-config.php generator asks for it too. - In every table's name, in whatever tool your host gives you for the database.
- In SQL copied from a guide. A query written for
wp_optionsfinds nothing, or fails, on a site whose table isabc_options. - On a multisite network. The first site uses the prefix alone. Each further site adds its number, as in
wp_2_posts.
What goes wrong
The prefix is in more places than the table names. WordPress also builds the names of a few rows from it. With wp_ they are:
| Table | Row | Holds |
|---|---|---|
| options | wp_user_roles | The site's roles and what each may do |
| user meta | wp_capabilities | One user's role |
| user meta | wp_user_level | A number WordPress works out from that role |
That is what breaks when the prefix is changed by hand.
- Only the line in
wp-config.phpis changed. WordPress looks for tables that do not exist and concludes the site is new. Every address leads to the installation screen. Nothing is lost: put the old prefix back and the site returns. WordPress's sample file warns of exactly this. - The tables and the line are changed, the rows are not. The site loads and everyone can log in, but WordPress finds no roles under the new name. Every dashboard screen answers "Sorry, you are not allowed to access this page." How to fix it has the three statements that rename the rows.
- A query uses the wrong prefix. This is the usual reason a copied query returns nothing. The key is the part people miss: listing administrators means reading
abc_capabilities, notwp_capabilities. See what to do about an unknown admin user and how to clean up a WordPress database, which both say where the prefix goes.
Not every name that starts with wp_ comes from the prefix. The option wp_page_for_privacy_policy has that name on every site, whatever the prefix. Rename only the rows above.
How to look at yours
Go to Tools, then Site Health, open the Info tab and expand Database. The row is "Table prefix". With WP-CLI:
wp config get table_prefixCommon questions
Should I change the table prefix for security?
WordPress's hardening guide says many published SQL injection attacks assume the prefix is wp_, and that another prefix can block at least some of them. It lists the change under security through obscurity, which it calls generally an unsound primary strategy. Choosing another prefix at setup costs nothing. On a site that is already running, the change is the risky operation described above.
How do I change the prefix on a site that is already running?
Export the database first. Then rename every table, change $table_prefix to match, and rename the three rows in the table above to the new prefix. All three steps have to be done before the dashboard works again. Try it on a staging copy first.