If you’ve gotten the notification from ManageWP that you have extra database tables in your WordPress install, here’s a quick and easy video on removing those extra database tables.
Here’s what the notification would have looked like from ManageWP:
Backups completed successfully.
We have detected database tables we believe do not belong to this WordPress install on yourwebsite.com
If you wish to review and/or include them in backup, click hereWarning notice on ManageWP.
Video tutorial and transcript on removing extra database tables
Hi all, today I’m going to talk to you about a new feature on ManageWP where it detects database tables that do not match the prefix set up for your WordPress site.
That starts out by telling you that it has completed the backup successfully. But it has detected database tables we believe do not belong to this WordPress install on your URL. If you wish to review and or include them in the backup, click here. I go ahead and click here and it brings me to the backups specifically the database tables.
It’s showing me a whole bunch of database tables that start with just wp_. Now the most likely scenario for why this happened is that when you set up your WordPress site, you maybe a chose new prefix or possibly imported this from another website, and there were a bunch of database tables wp_ set up by default.
So in this scenario, I happen to know that the database prefix for this website is not wp_. So I’m going to go to my hosting and go to the database administration tool and delete these extra tables.
So I have now launched my database tool, and as you can see, this website has a ton of tables that all start with this long, confusing prefix. So what I’m going to do is I’m going to go to the table column. I’m going to scroll down until I find these little wp_ tables.
Now, in this case, I imported the site from another hosting company, and when the site was initially set up, it created all of these wp_ tables, and then I imported and it switched the database prefix to my new prefix, but left all the old tables. So I happen to know these are useless.
Before you do any database operations, especially what we’re about to do and drop tables. You want to make sure that you have a complete backup of your database, preferably a complete backup of your entire WordPress site, and most importantly, the ability to restore that backup.
Many backup tools that have restore options are limited that your WordPress website has to actually be working in order for them to restore the database. Doing operations such as dropping tables can completely break your website, at which point you would not have a working WordPress install, and therefore those other tools would not be able to restore.
So make sure that you have a database and the ability to restore the backup even if your WordPress site is completely broken.
Now I’m going to take these extra tables and click Drop. It asks if I’m really sure because again, this is a destructive operation and I am. All right, tables are dropped and I am all done.
So now I’m just going to go back to ManageWP, and I’m just going to tell it to ignore those. So I’m just going to dismiss the notification and next time it runs a backup. It will automatically remove that error notification because the tables no longer exist.
So here I am back on ManageWP and all I’m going to do is just click dismiss on this notification. The very next time that it takes a backup, it won’t see these tables and therefore won’t reproduce the notification. I don’t need to click either of these buttons.
In this tutorial on removing extra database tables, I’ve used the database manager at my hosting company. If you don’t know how to access the database manager at your hosting company, you should contact your host. Also, if you don’t know how to open the database manager, you likely don’t know how to restore database tables in case anything goes wrong.
It’s always a good idea to get an experienced developer involved for just a short consult to make sure that you don’t damage your WordPress website. This is definitely a circumstance where it’s better to be safe than sorry.