WP-DBManager · Version history
WP-DBManager changelog and version history
- Latest version
- 4.0.0
- Aug 9, 2026 (3 months ago)
- Releases
- 39
- since 2007
- In the last year
- 2
- about one every 15 days
- Tested up to
- WordPress 7.0.8
- PHP 8.2 or later
Releases each year
- 200710 releases
- 20082 releases
- 20091 release
- 20111 release
- 20147 releases
- 20152 releases
- 20161 release
- 20172 releases
- 20181 release
- 20192 releases
- 20202 releases
- 20224 releases
- 20231 release
- 20241 release
- 20262 releases
20262 releases
WP-DBManager 4.0.0Latest
- 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 shi…
- 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.
WP-DBManager 3.0.0
20241 release
WP-DBManager 2.80.10
20231 release
WP-DBManager 2.80.9
20224 releases
WP-DBManager 2.80.8
WP-DBManager 2.80.7
WP-DBManager 2.80.6
WP-DBManager 2.80.5
20202 releases
WP-DBManager 2.80.3
WP-DBManager 2.80.2
20192 releases
WP-DBManager 2.80.1
WP-DBManager 2.80
20181 release
WP-DBManager 2.79.2
20172 releases
WP-DBManager 2.79.1
WP-DBManager 2.79
20161 release
WP-DBManager 2.78.1
20152 releases
WP-DBManager 2.78
WP-DBManager 2.76
20147 releases
WP-DBManager 2.75
WP-DBManager 2.74
WP-DBManager 2.73
WP-DBManager 2.72
WP-DBManager 2.71
WP-DBManager 2.70
WP-DBManager 2.65
20111 release
WP-DBManager 2.50
20091 release
WP-DBManager 2.40
20082 releases
WP-DBManager 2.31
WP-DBManager 2.30
200710 releases
WP-DBManager 2.20
WP-DBManager 2.11
WP-DBManager 2.10
WP-DBManager 2.05
WP-DBManager 2.04
WP-DBManager 2.03
WP-DBManager 2.02
WP-DBManager 2.01
WP-DBManager 2.00
WP-DBManager 1.00
Questions about WP-DBManager’s releases
What is the latest version of WP-DBManager?
4.0.0, released on Aug 9, 2026 (2 months ago). It’s tested up to WordPress 7.0.8 and needs PHP 8.2 or later.
How often is WP-DBManager updated?
2 releases in the last year, about one every 15 days. Its first release on WordPress.org dates from March 2007.
Know when your rivals ship
Track your plugin and its rivals: TrackWP sees each new release in the nightly snapshot and alerts you, with what it did to their rank.
Start freeRelease dates come from the day each version’s folder was made in WP-DBManager’s WordPress.org SVN repository; the notes from its readme’s changelog, as its authors wrote it.