I wrote ABCode Database Exporter for one job: getting a copy of a WordPress database out of a site when you have a login and not much else. A .sql file, downloaded from the admin, in about four clicks.
The usual routes are phpMyAdmin in the hosting panel or mysqldump over SSH, and I still use both when I have them, as I set out in backing up a WordPress database properly. The trouble is that plenty of people have neither. Some hosts hide phpMyAdmin behind a support ticket, some never offer SSH, and phpMyAdmin’s export screen has enough options to produce a file that will not import.
By the end of this you will know what every button does, when each is the right pick, and how to put the file back. It is free on wordpress.org, there is no settings page, and there is no paid tier.
Before you start
You need an administrator account. On multisite you need to be a Network Administrator, because every site in a network shares one database, so a single export contains all of them. The plugin needs WordPress 5.0 or later and PHP 7.4 or later.
Exporting is read-only. The plugin reads your tables and writes a file, so running it on a live site is safe. Importing is the half that can destroy a site, because an import writes over what is already there.
One limit worth knowing now rather than during a restore: this exports the database and only the database. Your uploads, themes and plugins are files on disk and are not in the .sql. A site restored from a database export alone comes back with its posts, users and settings intact and every image broken.
Step 1: Install it from the Plugins screen
Go to Plugins, then Add New. Search for “ABCode Database Exporter”, click Install Now, then Activate. If your host blocks installs from the admin, download the zip from the wordpress.org listing and use the Upload Plugin button on the same screen.
Nothing to configure afterwards: no settings page, no wizard. The plugin’s row on the Plugins screen gains a link straight to the export screen.
Step 2: Open Tools, then Database Exporter
The screen lives under Tools. The top of it summarises what you are about to export: the database name, how many tables it holds and how much space they take. Below that is a filter box for finding a table by name, then the table list, each row with a checkbox and three buttons, and at the bottom the export button with the number of selected tables written into it.
That screenshot is from a small test install and it still shows thirty-three tables, because every plugin that stores its own data adds some. A real site carries more again. What the header is useful for is noticing change: a table count that has jumped means a plugin created tables, and a size that has jumped usually means one table has run away with itself.
Step 3: Export the whole database
Every table starts ticked, so if you want the lot, go straight to the button and press it. It writes the file table by table with a progress bar rather than in one go, which is why it copes with large databases on cheap shared hosting. A single-shot export is the one that hits the PHP time limit and dies halfway through, leaving a file that looks fine until you try to import it.
When it finishes you choose a plain .sql or a gzipped .sql.gz. Gzip needs PHP’s gzip extension, which nearly every host has, and it makes a real difference because SQL is repetitive text. Take the compressed one over a slow connection, the plain one if you are unsure what will open it.
Then click Download. The copy on the server is temporary: a protected directory, a randomised filename, tied to your user account, deleted after an hour. That matters more than it sounds, because a database export left in a guessable spot on a public server is your user table available to anyone who finds the URL.
Step 4: Export only the tables you pick
Untick what you do not want, or use the filter box to find one table and tick just that. The button always tells you how many tables are selected, so you can check before you commit.
This is the mode I use most: wp_options to compare settings between staging and live, one plugin’s tables before deleting the plugin, the orders tables to reproduce a checkout bug. If you do this often, read exporting single WordPress database tables too, because a partial export has consequences a full one does not. Tables refer to each other, and a wp_posts without its wp_postmeta is a set of posts with no custom fields.
Step 5: The Schema, CSV and SQL buttons
Each row has three buttons of its own, and they do different jobs.
SQL exports that one table, structure and rows, in the same format as the full export. Use it when the table is going back into a database, whether that is staging, live or somebody else’s site.
CSV exports the rows as a spreadsheet. Use it when a person is going to read the data rather than a database: handing a client a list of subscribers, or pulling numbers out to add up. A CSV cannot be imported back into MySQL as it stands, so it is an output format rather than a backup.
Schema copies that table’s CREATE TABLE statement to your clipboard. No download, no file. It is the fastest way to see what columns a table actually has, which I use constantly when a plugin has created tables and I want to know what it stores.
If you export data that identifies people, treat the file accordingly. Send it as a link that expires rather than an email attachment, and delete it once collected.
Step 6: Import the file somewhere
Exporting was the safe half. This is the half where you can lose a site, so read the file before you run it. Open the .sql in a text editor and look at the top. If the statements drop each table before recreating it, importing replaces those tables permanently, with no confirmation prompt. If they do not, the import stops with an error saying the table already exists. Know which before you start.
The rule I stick to: export the destination first, then import into it. The worst case is then that you put back what was there five minutes ago.
In phpMyAdmin, open the destination database, go to the Import tab, choose the file and run it. Most installs accept a .sql.gz directly; if yours refuses, decompress it first. Watch the upload size limit on that screen too, since a big export will exceed it.
With WP-CLI, from the site’s root directory:
# Take a copy of the destination first. This is the undo button.
wp db export before-import.sql
# Import. This runs immediately against the live database with no
# confirmation step, so be sure you are on the right site.
wp db import backup.sql
# For a gzipped export, decompress on the way in. The trailing "-"
# tells WP-CLI to read from standard input rather than a file.
gunzip -c backup.sql.gz | wp db import -The output is written in the format phpMyAdmin produces, which mysql, WP-CLI, MySQL Workbench and Adminer all read, so nothing is tied to my plugin. Uninstall it tomorrow and your existing exports still work.
What it does not do
It exports. It does not import, so there is no restore button anywhere in it, and that is deliberate: an import button in the admin is a one-click way to destroy a site.
It does not filter rows, so “only this year’s orders” is still a query in phpMyAdmin or a mysqldump --where. It does not schedule anything, send files off-site, or touch wp-content. If any of those are what you need, a full backup plugin or your host’s own backups is the better answer.
How to check it worked
Open the downloaded file in a text editor. A good export starts with a header comment naming the database, then CREATE TABLE statements each followed by their INSERT statements. If you can see your table names and recognisable data, you have a real file. Check the size too: a working site’s export runs to megabytes, and a few kilobytes means it stopped early.
The only test that genuinely proves a backup is importing it somewhere and looking at the result. Import into staging or a local copy, load the front page, log in, click around. Ten minutes, and it is the difference between having a backup and believing you have one.
When it does not work
The export starts and then stops partway
Usually the host rather than the plugin, because some security modules kill long-running admin AJAX requests. Try again with fewer tables selected to find out whether one table is the problem, and check the error log, which you can reach through WordPress debug mode without panel access.
The gzip option is missing or fails
PHP’s gzip extension is not enabled on that server. Take the plain .sql and compress it on your own machine, or ask the host to enable it.
The screen is not under Tools
Either the plugin is not activated, or you are not an administrator. On multisite it appears only for Network Administrators, because the export covers every site in the network.
The import fails with “table already exists”
The file creates tables without dropping them first and the destination already has them. Drop the affected tables before importing, or import into an empty database. Not on a live site without exporting it first.
Common questions
Is it safe to run on a live site?
Yes. Exporting only reads. The one thing to watch is a very large database on a busy shared server, where a long read adds load, so I would run a full export at a quiet hour on a big site.
Can I use this to move a site to a new host?
For the database half, yes. You still have to move the files over FTP or a file manager, and deal with the URLs stored inside the database, which is a search and replace job rather than a copy and paste one.
Does it export tables that plugins created?
Yes, every table in the WordPress database is listed, including ones created by plugins or custom code. That is often the reason to use it, because those are the tables nobody documents.
Do I still need a backup plugin?
If the site matters, yes. This is a manual tool for the moment you want a copy in your hand. It does not run on a schedule, store copies off-site, or include your files.
Where this fits
This plugin replaces one errand: opening a hosting panel, finding phpMyAdmin, guessing at export settings, waiting. It does not replace a backup strategy and it does nothing phpMyAdmin cannot. It does that one thing where you already are, with fewer ways to get it wrong. It has its own page on this site, and it stays free.
I would still reach for the command line for anything repeatable: nightly exports, scripted deploys, a search and replace across a migration. Anything you do once, from a browser, on a site whose host has given you very little, is what I built this for. If you have hit something it will not do, get in touch.
This one started as an errand I was tired of repeating, which is usually where a good plugin comes from. If you have a job like that in your own workflow, it is the same thinking behind our WordPress plugin development.
