Title: WP-DBManager
Author: Lester Chan
Published: <strong>03 January 2006</strong>
Last modified: 09 August 2026

---

Search plugins

![](https://ps.w.org/wp-dbmanager/assets/banner-772x250.png?rev=3639526)

![](https://ps.w.org/wp-dbmanager/assets/icon.svg?rev=977538)

# WP-DBManager

 De [Lester Chan](https://profiles.wordpress.org/gamerz/)

[Download](https://downloads.wordpress.org/plugin/wp-dbmanager.4.0.0.zip)

 * [Details](https://lij.wordpress.org/plugins/wp-dbmanager/#description)
 * [Reviews](https://lij.wordpress.org/plugins/wp-dbmanager/#reviews)
 *  [Installation](https://lij.wordpress.org/plugins/wp-dbmanager/#installation)
 * [Development](https://lij.wordpress.org/plugins/wp-dbmanager/#developers)

 [Supòrto](https://wordpress.org/support/plugin/wp-dbmanager/)

## Description

WP-DBManager looks after the database behind your site: it backs it up, restores
it, optimizes and repairs it, empties or drops tables and runs queries you write,
all from wp-admin rather than from a shell or phpMyAdmin. Backups, optimization 
and repair can be left to run on a schedule, and the backup can be emailed to you
when it finishes.

### Donations

I spent most of my free time creating, updating, maintaining and supporting these
plugins, if you really love my plugins and could spare me a couple of bucks, I will
really appreciate it. If not feel free to use it without any obligations.

### Usage

### Securing The Backup Folder

A database backup contains everything, including your users table. Anyone who can
guess a backup file name can download the lot, so the folder must not be served 
over HTTP.

**The reliable option, on any server:** set `Path To Backup` under `WP-Admin -> 
Database -> Settings` to a folder outside your web root, for example `/var/www/example.
com/backup-db` when WordPress lives in `/var/www/example.com/public_html`. Nothing
served, nothing to configure.

If the folder has to stay inside the web root:

 * **Apache** — move `htaccess.txt` from `Folder: wp-content/plugins/wp-dbmanager`
   to `Folder: wp-content/backup-db/.htaccess`
 * **IIS** — move `Web.config.txt` from `Folder: wp-content/plugins/wp-dbmanager`
   to `Folder: wp-content/backup-db/Web.config`
 * **nginx** — nginx does not read `.htaccess` files, so the file above does nothing.
   Add this to your server block and reload nginx:

    ```
    location ^~ /wp-content/backup-db/ { deny all; }
    ```

Move `index.php` from `Folder: wp-content/plugins/wp-dbmanager` to `Folder: wp-content/
backup-db/index.php` as well, so the folder cannot be listed.

The `Backup DB` page requests a file from the folder and reports what the server
actually returns, so you can confirm the folder is closed rather than assume it.

### WP-CLI

    ```
    wp dbmanager tables
    wp dbmanager backups
    wp dbmanager backup --yes
    wp dbmanager backup --no-gzip --yes
    wp dbmanager restore <file> --yes
    wp dbmanager delete <file>... --yes
    wp dbmanager email <file> --to=ops@example.org --yes
    wp dbmanager optimize --all --yes
    wp dbmanager repair wp_options --yes
    wp dbmanager empty <table>... --yes
    wp dbmanager drop <table>... --yes
    ```

**Everything that changes anything asks first**, so a script has to pass `--yes`.
That includes `backup`, which deletes the oldest backups to stay inside `Maximum
Backup Files`, and `email`, because a dump holds your users table and a sent message
cannot be recalled. `tables` and `backups` only read, and take a `--format` of `
table`, `csv`, `json`, `yaml`, `count` or `ids`; their sizes are in bytes rather
than the KiB and MiB the screens print, because a shell is better at arithmetic 
than at parsing `1.2 MiB`.

    ```
    optimize and `repair` take table names or `--all`. `empty` and `drop` take names only: emptying or dropping every table in a database is not maintenance, and the screen at least shows you the list before you tick it.
    ```

**There is no `run` subcommand.** WP-CLI already ships `wp db query`, which reaches
the same database through the same client, so the `Run SQL Query` screen has no 
command counterpart. That screen is unchanged and still works.

    ```
    wp dbmanager checks no capability. WP-CLI has no logged-in user unless you ask for one with `--user`, and whoever can run it can already read the credentials in `wp-config.php`, so a check would refuse every scheduled backup script while protecting nothing. The `install_plugins` gate on the admin screens is unchanged.
    ```

## Screenshots

[⌊Database, the server it runs on and the size of every table⌉⌊Database, the server
it runs on and the size of every table⌉[

Database, the server it runs on and the size of every table

[⌊Backup DB, which checks the paths and the folder before it offers to run⌉⌊Backup
DB, which checks the paths and the folder before it offers to run⌉[

Backup DB, which checks the paths and the folder before it offers to run

[⌊Manage Backup DB, every backup with its checksum, date and size⌉⌊Manage Backup
DB, every backup with its checksum, date and size⌉[

Manage Backup DB, every backup with its checksum, date and size

[⌊Optimize DB, which reclaims the space MySQL still holds after deletions⌉⌊Optimize
DB, which reclaims the space MySQL still holds after deletions⌉[

Optimize DB, which reclaims the space MySQL still holds after deletions

[⌊Repair DB, for tables the server has marked as crashed⌉⌊Repair DB, for tables 
the server has marked as crashed⌉[

Repair DB, for tables the server has marked as crashed

[⌊Empty/Drop Tables, one row per table and what emptying it would remove⌉⌊Empty/
Drop Tables, one row per table and what emptying it would remove⌉[

Empty/Drop Tables, one row per table and what emptying it would remove

[⌊Run SQL Query, for the statement no screen has a button for⌉⌊Run SQL Query, for
the statement no screen has a button for⌉[

Run SQL Query, for the statement no screen has a button for

[⌊Database Settings: the paths, the schedule, and where a backup is mailed⌉⌊Database
Settings: the paths, the schedule, and where a backup is mailed⌉[

Database Settings: the paths, the schedule, and where a backup is mailed

## Installation

 1. Install and activate the plugin.
 2. The plugin creates a `backup-db` folder inside `wp-content` if that folder is writable.
    If it does not appear, create it yourself and make it writable.
 3. **Secure the backup folder**, as described under Usage. Anyone who can reach it
    over HTTP can download your entire database.
 4. Go to `WP-Admin -> Database -> Settings` to configure the backup, optimize and 
    repair schedules.
 5. Go to `WP-Admin -> Database -> Backup DB`, which checks whether the folder is actually
    reachable over HTTP and tells you if it is.

## FAQ-e

### My database is not backed up / My backup file is 0Kb

 * Go to `WP-Admin -> Database -> Backup DB`. The top of that page checks the backup
   folder, both binary paths, and whether `passthru()`, `system()` and `exec()` 
   are available, and tells you which one is the problem.
 * The usual answer is that the host does not allow `mysqldump` to be run at all,
   or that the path under `WP-Admin -> Database -> Settings` is wrong. Your host
   can tell you the correct path.
 * If you added extra flags to the mysqldump or mysql path, remove them. From 3.0.0
   the path is passed as a single argument, so anything after the binary name is
   treated as part of the file name.

### My gzipped backup file is about 20 bytes

 * That is an empty gzip stream: `mysqldump` failed and produced nothing, and `gzip`
   compressed the nothing.
 * Before 3.0.0 the plugin could not tell. `mysqldump | gzip` reports gzip’s exit
   status rather than mysqldump’s, and the file it leaves behind is not empty, so
   the check for a zero byte backup never fired. The file was renamed with a checksum
   and, if you had backup e-mails on, sent to you.
 * From 3.0.0 the dump is read back before it is accepted, and one with nothing 
   in it is deleted and reported as a failure. **Check any recent `.sql.gz` backups
   you are relying on** — a real one is far larger than 20 bytes, and `gunzip -c
   yourbackup.sql.gz | head` should show SQL.

### I clicked Optimize (or Repair) and it says “No Tables Selected”

 * From 3.0.0 these screens no longer tick every table for you. Tick the tables 
   you want — or the box in the header row to take the lot — then pick `Optimize`
   from `Bulk actions` and press `Apply`.
 * The old screens pre-selected everything, so a single click acted on the whole
   database whether or not that was what you meant. Selecting first is the WordPress
   convention and is a good deal harder to do by accident.
 * The same applies to `Empty/Drop Tables`, which additionally can no longer empty
   some tables and drop others in one submit — pick one action, apply it, then pick
   the other.

### The Database pages say “Sorry, you are not allowed to access this page”

 * Your bookmark points at the old address. In 3.0.0 the screens moved from `admin.
   php?page=wp-dbmanager/database-backup.php` to `admin.php?page=wp-dbmanager-backup`,
   and likewise for the others.
 * Reach them from the `Database` menu in the sidebar and re-bookmark. Nothing has
   been removed.
 * The old addresses embedded the plugin’s folder name, which meant the plugin only
   worked when installed as `wp-dbmanager`. It no longer cares what the folder is
   called.

### What is the difference between WP-DBManager and WP-DB-Backup?

 * WP-DBManager uses the `mysqldump` application to generate the backup and the `
   mysql` application to restore it, via the shell.
 * WP-DB-Backup uses PHP to generate the backup. In some cases WP-DB-Backup will
   work better for you because it requires fewer permissions — not every host allows`
   mysqldump`/`mysql` to be run directly.
 * WP-DBManager also gives you automatic optimizing and repairing of the database
   on top of backing it up.

### My backup folder is reported as visible to the public

 * Anyone who guesses a backup file name can download your entire database, including
   your users table, so this is worth fixing rather than hiding.
 * The most reliable fix on any server is to move the folder outside your web root—
   set `Path To Backup` under `WP-Admin -> Database -> Settings` to something like`/
   var/www/example.com/backup-db`. Nothing is served, so there is nothing to protect.
 * If it has to stay inside the web root, see _Securing The Backup Folder_ above.
   On nginx the bundled `.htaccess` does nothing at all; you need a `location` block.
 * The `Backup DB` page requests a file from the folder and reports what your server
   actually returned, so it is telling you what a visitor would get rather than 
   guessing. If you have verified it yourself and want the notice gone anyway, set`
   Hide Admin Notices` to `Yes` under `Settings`.

## Reviews

![](https://secure.gravatar.com/avatar/b520826c6ae4f54d949723318f70f291ee382c1fe80dd6d68601404edd5d13f7?
s=60&d=retro&r=g)

### 󠀁[Excelent plugin](https://wordpress.org/support/topic/excelent-plugin-576/)󠁿

 [federicorojas1100](https://profiles.wordpress.org/federicorojas1100/) 09 August
2026

Thanks for the update. The plugin is quite good. I’ve been using it for a while 
to optimize database performance and works quite good

![](https://secure.gravatar.com/avatar/cf3ce259feb3179936d0518e5191438c87deae0473573e5356fe6e77cd94e4b9?
s=60&d=retro&r=g)

### 󠀁[Remove all submissions in elementor](https://wordpress.org/support/topic/remove-all-submissions-in-elementor/)󠁿

 [modes200](https://profiles.wordpress.org/modes200/) 20 May 2025

Great plugin. I have used to clean up all submissions in elementor

![](https://secure.gravatar.com/avatar/21276ef0a192ecd0a7bef849cb6963537c147a3926b2de25d7b8c1b5a4b233ec?
s=60&d=retro&r=g)

### 󠀁[Best one for my particular needs, thanks!](https://wordpress.org/support/topic/best-one-for-my-particular-needs-thanks/)󠁿

 [robaxxx](https://profiles.wordpress.org/robaxxx/) 05 November 2022

I use this along with a Windows program called Backup4All on my server to create
regular backups of my WP instances to Amazon S3. It’s also easy to do an instant
db backup and then zip up the site folder with the db inside on the server if I’m
doing something risky. I wanted something that was simple, affordable and logical
and found this one best after testing many others. Thanks heaps!

![](https://secure.gravatar.com/avatar/08b5d287140d20bc2ed07150fed85d5f4597b9928da8937aaef77c7d051e3587?
s=60&d=retro&r=g)

### 󠀁[This was one tool used to help me bring back my wp site](https://wordpress.org/support/topic/this-was-one-tool-used-to-help-me-bring-back-my-wp-site/)󠁿

 [jamesoutland](https://profiles.wordpress.org/jamesoutland/) 02 October 2022

1st, I was able to target the files I wanted to clean. I would like to add just 
be careful what you remove. Then I was able to reinstall a program and it worked.
Not sure the tecnical reasons why it worked but it did. Thank you!

![](https://secure.gravatar.com/avatar/68d12b0bc5a279b854b74161cd3746f387b7549281de909163cf0399cd53e706?
s=60&d=retro&r=g)

### 󠀁[it doesnt work](https://wordpress.org/support/topic/it-doesnt-work-311/)󠁿

 [ntalam](https://profiles.wordpress.org/ntalam/) 29 August 2022 1 reply

SELECT * FROM ‘…. returns me nothing

![](https://secure.gravatar.com/avatar/a9c3ca262ef07c913f046456d6540c01259d5ac0d19682921b716dde1fcca130?
s=60&d=retro&r=g)

### 󠀁[Version 2.80.7 works again](https://wordpress.org/support/topic/no-longer-usable-6/)󠁿

 [nonick08](https://profiles.wordpress.org/nonick08/) 19 July 2022 1 reply

From version 2.80.7 the menu is visible again without activated theme and plugin
editor. old Since version 2.80.6 only works with activated theme and plugin editor.

 [ Read all 95 reviews ](https://wordpress.org/support/plugin/wp-dbmanager/reviews/)

## Contributors & Developers

“WP-DBManager” is open source software. The following people have contributed to
this plugin.

Contributors

 *   [ Lester Chan ](https://profiles.wordpress.org/gamerz/)

“WP-DBManager” has been translated into 11 locales. Thank you to [the translators](https://translate.wordpress.org/projects/wp-plugins/wp-dbmanager/contributors)
for their contributions.

[Translate “WP-DBManager” into your language.](https://translate.wordpress.org/projects/wp-plugins/wp-dbmanager)

### Interested in development?

[Browse the code](https://plugins.trac.wordpress.org/browser/wp-dbmanager/), check
out the [SVN repository](https://plugins.svn.wordpress.org/wp-dbmanager/), or subscribe
to the [development log](https://plugins.trac.wordpress.org/log/wp-dbmanager/) by
[RSS](https://plugins.trac.wordpress.org/log/wp-dbmanager/?limit=100&mode=stop_on_copy&format=rss).

## Changelog

### 4.0.0

 * FIXED: Changing the backup folder on the settings screen left the new folder 
   unprotected. The `.htaccess`, the `Web.config`, the silence-is-golden `index.
   php` and the `0750` were only ever written on activation and from the “try to
   fix” notice, so backups were then written to a bare directory — and the shipped
   default lives inside `wp-content`, which is served. A dump contains the users
   table
 * FIXED: The download and folder-repair handlers were registered on every request,
   front end included, where neither can legitimately arrive. Appending `?try_fix
   =1` to any URL on the site turned it into an “Access Denied” page, because the
   capability check runs before the nonce
 * FIXED: `.sql` was added to the site-wide upload types for everyone, so any Author
   gained a file type they could put in the public uploads directory — for a feature
   they cannot reach. Only users who may actually restore a database get it now
 * BREAKING: Requires WordPress 6.8 and PHP 8.2, up from 4.0 and 5.2.
 * BREAKING: The settings row is renamed from `dbmanager_options` to `wp_dbmanager_options`,
   and a second row, `wp_dbmanager_version`, records the plugin and schema versions.
   The rename happens by itself the first time the plugin loads.
 * BREAKING: The three cron hooks are renamed `wp_dbmanager_cron_backup`, `wp_dbmanager_cron_optimize`
   and `wp_dbmanager_cron_repair`, and their recurrences `wp_dbmanager_backup`, `
   wp_dbmanager_optimize` and `wp_dbmanager_repair`. The scheduled events are rebuilt
   automatically.
 * BREAKING: The Database admin pages have new addresses. `admin.php?page=wp-dbmanager/
   database-backup.php` is now `admin.php?page=wp-dbmanager-backup`, and so on for
   every screen. Update any bookmarks. The menu itself is unchanged, and the plugin
   no longer cares what its folder is called.
 * BREAKING: Every class is renamed from `DBManager_*` to `WP_DBManager_*`, and 
   the files under `includes/` with them.
 * BREAKING: A gzipped backup could be written, checksummed and e-mailed to you 
   even when mysqldump had failed and produced nothing at all. See the FAQ. Check
   that your recent `.sql.gz` backups are not around 20 bytes.
 * BREAKING: `Optimize DB` and `Repair DB` no longer tick every table for you. Select
   the tables you want, then choose the action from `Bulk actions`. Previously every
   table was pre-selected, so one click acted on all of them.
 * BREAKING: `Empty/Drop Tables` can no longer empty some tables and drop others
   in the same submit. Choose `Empty` or `Drop` from `Bulk actions`, then submit
   again for the other.
 * NEW: A `wp dbmanager` WP-CLI command — `tables`, `backups`, `backup`, `restore`,`
   delete`, `email`, `optimize`, `repair`, `empty` and `drop`. Everything that changes
   anything asks first, so scripts need `--yes`. There is no `run` subcommand: `
   wp db query` already does that, and the `Run SQL Query` screen is unchanged.
 * NEW: A `wp_dbmanager_capability` filter. Every capability check in the plugin
   goes through it, so the Database screens can be handed to another role in one
   place. The default is still `install_plugins`.
 * NEW: Every table on the Database, Manage Backup DB, Optimize, Repair and Empty/
   Drop screens is now a standard WordPress list table. Columns sort, the select-
   all box works, and the Optimize and Repair screens show each table’s size and
   overhead so you can see what is actually worth acting on.
 * NEW: Several backups can be deleted or e-mailed in one go. Restore and Download
   still act on one at a time, and say so rather than guessing.
 * NEW: Settings is a Settings API screen, built from registered sections and fields,
   and the backup, optimize and repair schedules now follow the settings however
   they are changed, including from WP-CLI.
 * NEW: The Backup Database page now asks the server whether the backup folder is
   actually reachable over HTTP, instead of assuming a dropped in .htaccess protects
   it. nginx is detected and given a configuration snippet that works.
 * NEW: ‘Attach Backup File’ option to control whether the scheduled backup e-mail
   carries the database file. Existing sites keep attaching it.
 * NEW: New backups are gzipped by default.
 * NEW: A PHPUnit test suite and GitHub Actions CI covering every admin screen, 
   the settings, the schedules and the backup handling, on six WordPress and PHP
   combinations in both single site and multisite, plus a vitest suite for the admin
   script.
 * NEW: WordPress 7.0
 * CHANGED: The admin screens use core’s own notice, table and form markup throughout.
   The hand-coloured green and red status lines are gone, which is what makes them
   legible in dark mode and to a screen reader.
 * CHANGED: New installs no longer prefill the backup e-mail address, so scheduled
   backup e-mails are opt-in.
 * CHANGED: Translations now come from the WordPress.org language packs. The bundled.
   pot file and the load_plugin_textdomain() call are gone, both were redundant.
 * FIXED: A failed gzipped backup is no longer passed off as a real one. `mysqldump
   | gzip` reports gzip’s exit status rather than mysqldump’s, and gzip turns empty
   input into a valid 20 byte file, so the old size check never saw the failure.
   Gzip is the default, so this was the common case.
 * FIXED: The confirmation dialogs before restoring, dropping and emptying showed`
   Database.nThis Action Is Not Reversible.` instead of proper line breaks.
 * FIXED: The Windows and Linux path hints under Settings displayed `'<strong>mysqldump.
   exe</strong>'` as literal text.
 * FIXED: Backups larger than 1 GiB reported their size in the wrong unit, so a 
   2 GiB backup showed as `2048.0 GiB`.
 * FIXED: The mysqldump command, its connection arguments and the restore command
   were written out three separate times and had drifted apart; only two of the 
   three checked that the dump had produced a file.
 * FIXED: Escape all output on the admin screens to prevent XSS.
 * FIXED: Validate table names against the database before emptying, dropping, optimizing
   or repairing.
 * FIXED: The database password is no longer passed on the command line.
 * FIXED: Require the `install_plugins` capability for the backup folder notice,
   the download and the folder fix.
 * FIXED: Only download backup files that resolve inside the backup folder.
 * FIXED: A download the plugin refuses no longer ends in a blank page. `Manage 
   Backup DB` now reports `Invalid Database Backup File` instead of returning an
   empty response with no explanation.
 * FIXED: Validate the mysqldump, mysql and backup paths independently.
 * FIXED: Every file now refuses to run when loaded directly.
 * FIXED: Cron backups no longer rename and e-mail a dump that failed, an empty 
   file is no longer passed off as a backup.
 * FIXED: Restoring no longer reports success when the restore did not run.
 * FIXED: Keep pruning old backups until the maximum is met, and treat a maximum
   below 1 as no limit.
 * FIXED: Two backups written in the same second are no longer invisible to pruning
   and the manage screen.
 * FIXED: Network activation and uninstall now cover every site, not just the first
   100.
 * FIXED: Uninstalling on multisite no longer overwrites the current site ID while
   it works.
 * FIXED: Removed jQuery dependency.
 * NOTE: This release is numbered 4.0.0. 3.0.0 is already on WordPress.org, so the
   work that was going to be 3.0.0 ships as 4.0.0 instead.
 * NOTE: The mysqldump and mysql paths are now passed as a single argument. If you
   added extra flags to either path under Settings, move them out or your backups
   will fail.
 * NOTE: Backup file names now carry a real Unix timestamp. Backups taken before
   this release will show a date shifted by your timezone offset. The files themselves
   are fine.
 * NOTE: The plugin’s PHP functions are no longer global. Everything now lives in`
   WP_DBManager_*` classes under `includes/`. The `wp_dbmanager_before_escapeshellcmd`
   action is unchanged.
 * NOTE: The bare “To”, “From” and “and” labels carry translator context now, because
   a single word out of context is not enough to translate from. Those three msgids
   changed, so existing translations of them fall back to English until they are
   retranslated

## Mêta

 *  Version **4.0.0**
 *  Last updated **4 hours ago**
 *  Active installations **60.000+**
 *  WordPress version ** 6.8 or higher **
 *  Tested up to **7.0.3**
 *  PHP version ** 8.2 or higher **
 *  Languages
 * [Chinese (Taiwan)](https://tw.wordpress.org/plugins/wp-dbmanager/), [Dutch](https://nl.wordpress.org/plugins/wp-dbmanager/),
   [English (Canada)](https://en-ca.wordpress.org/plugins/wp-dbmanager/), [English (US)](https://wordpress.org/plugins/wp-dbmanager/),
   [French (France)](https://fr.wordpress.org/plugins/wp-dbmanager/), [Greek](https://el.wordpress.org/plugins/wp-dbmanager/),
   [Japanese](https://ja.wordpress.org/plugins/wp-dbmanager/), [Russian](https://ru.wordpress.org/plugins/wp-dbmanager/),
   [Serbian](https://sr.wordpress.org/plugins/wp-dbmanager/), [Spanish (Chile)](https://cl.wordpress.org/plugins/wp-dbmanager/),
   [Spanish (Spain)](https://es.wordpress.org/plugins/wp-dbmanager/), e [Spanish (Venezuela)](https://ve.wordpress.org/plugins/wp-dbmanager/).
 *  [Translate into your language](https://translate.wordpress.org/projects/wp-plugins/wp-dbmanager)
 * Tags
 * [backup](https://lij.wordpress.org/plugins/tags/backup/)[database](https://lij.wordpress.org/plugins/tags/database/)
   [Optimize](https://lij.wordpress.org/plugins/tags/optimize/)[repair](https://lij.wordpress.org/plugins/tags/repair/)
   [restore](https://lij.wordpress.org/plugins/tags/restore/)
 *  [Advanced View](https://lij.wordpress.org/plugins/wp-dbmanager/advanced/)

## Ratings

 4.4 out of 5 stars.

 *  [  78 5-star reviews     ](https://wordpress.org/support/plugin/wp-dbmanager/reviews/?filter=5)
 *  [  3 4-star reviews     ](https://wordpress.org/support/plugin/wp-dbmanager/reviews/?filter=4)
 *  [  2 3-star reviews     ](https://wordpress.org/support/plugin/wp-dbmanager/reviews/?filter=3)
 *  [  0 2-star reviews     ](https://wordpress.org/support/plugin/wp-dbmanager/reviews/?filter=2)
 *  [  12 1-star reviews     ](https://wordpress.org/support/plugin/wp-dbmanager/reviews/?filter=1)

[Your review](https://wordpress.org/support/plugin/wp-dbmanager/reviews/#new-post)

[See all reviews](https://wordpress.org/support/plugin/wp-dbmanager/reviews/)

## Contributors

 *   [ Lester Chan ](https://profiles.wordpress.org/gamerz/)

## Supòrto

Got something to say? Need help?

 [View support forum](https://wordpress.org/support/plugin/wp-dbmanager/)

## Donate

Would you like to support the advancement of this plugin?

 [ Donate to this plugin ](https://lesterchan.net/site/donation/)