WordPress is a file system that works around a central database. This database is used to store all the relevant information, options and settings required for a WordPress website to function. As such, it is a common target for malicious attacks and its security should be a priority for every WordPress developer. Among the long list of security features that can be used in WordPress itself, many can be added to the wp-config.php file. One of these settings is the table_prefix option, which we’ll cover in this article.
That is, the default prefix of WordPress databases is “wp_exposes them to attacks that could exploit the use of such default settings and use them to gather valuable user information. To guard against this type of attack, simply change the table prefix to something other than “wp_”, which others may not guess.
Changing WordPress Database Prefix
This process involves three main steps, but before trying them it’s always a good idea to back up the database so you can simply restore it if needed.
For the first part of changing the prefix you will use the wp-config.php file and change the default prefix for all tables. To do this you will need to access your website via FTP and edit the wp-config.php file in the root directory. right click select this file and Edit View from the drop-down list.
When the file opens in a new window, you will need to change the following line in it:
$table_prefix = 'wp_';
into
$table_prefix = ‘wp_new_';
We set the default database prefix to “wp_new_”. You are free to change this as you wish. But keep in mind that you can only use numbers, letters, and underscores to create the prefix. The start should still consist of “wp_” and you can enter your own part of your prefix after it. It is also good practice to end the new prefix with an underscore “_” so that table names are easily recognized.
After you change the line, you need to save your changes. The following popup will appear:
Simply click Yup and the file is edited.
Now, if you try to access your website one more time, you will be prompted to start the database setup once again, as the new setting for prefixes must be applied. If you do, your entire database will be invalidated and you will lose everything stored in it.. This means that if you have already started working on your website, everything you have done so far will be deleted.
To avoid this, you will need to change the names of all existing tables (and some occurrences of prefixes within tables) from within phpMyAdmin.
If you are running on a live server, you will need to contact your hosting provider or access your server to log in to your installation’s phpMyAdmin. cPanel and go to phpMyAdmin.
If you are working on a local server, you can go to the designated clipboard for it. For example, if you are using XAMPP, go to the control panel and press the admin button for MySQL.
After doing any of these you will be redirected to the phpMyAdmin control panel page in your default browser.
On the left side of the page, you will see a list of your databases. choose what you want edit just by clicking on it. If you are working on a premium WordPress theme, chances are quite a lot of tables will be shown on the next screen:
Replacing them all one by one would be a tedious task. Fortunately, once you scroll down to the bottom of this page, check all option. Click on it and from the drop down menu select the option next to Change table prefix.
A small window will open with two text boxes. One to enter the old table prefix, which in our case is “wp_”, and the second is to enter the new prefix we defined earlier in the wp-config.php file, which in our case is “wp_new_”.
With pressing the continue button you will make the change and you will be able to proceed to the last step.
Because the database tables themselves are interconnected, some have specific entries in them that point to one of the other tables. Among them, the old prefix is still used. If you leave it that way, errors will occur and you may have to restore your backed up database once again to avoid losing all the progress you’ve made in building your website.
What you need to do to avoid this Go to the SQL tab near the top of the browser window and add the code below in the text field that appears:
SELECT * FROM 'wp_new_options' WHERE 'option_name' LIKE 'wp\\_%'
After entering this code You should change the “wp_new_options” section to reflect your new prefix (so it should contain your new prefix followed by the word “options”). This will access the options table and take any option_name attribute starting with “wp_” from it. In essence, it will take all values of this attribute starting with the old prefix.
once you press go button A list of all entries in this table will be displayed along with a notification of how many are found.
Now that we have placed all instances of the old prefix in the options table, you will need to change them one by one. To do this double click the option_name field and add your new prefix instead of the old one. When you click outside the text box again, the information will be saved and a notification will pop up.
You will need to do this for the “usermeta” table as well.
As in the step above, go to the SQL tab once again and paste the code below into the large text box.
SELECT * FROM ‘wp_new_usermeta’ WHERE ‘meta_key’ LIKE ‘wp\\_%’
Replacing the “wp_new_” prefix with the prefix of your choice. After that Pressing the Go buttonYou should see a list of old prefix instances in the “usermeta” table.
This time you will have to manually change the “meta_key” column values to include the new prefix instead of the old one.
Once you do that, the table prefix changing process is complete and you can return to your website without any issues.
final thoughts
This wraps up our tutorial on changing the default WordPress database prefix. By following these steps, you can give yourself some peace of mind and ensure that your database and website are much more secure against possible cyber attacks.
Support our work ❤️
If you enjoyed this article, consider leaving a tip to help us keep publishing great content.

























