Menu Backup & Restore + Import/Export vs WP-DBManager

Menu Backup & Restore protects every WordPress menu, both classic nav_menu menus and block-theme wp_navigation posts edited in the Site Editor, with automatic backups, one-click restoration, and powerful import/export capabilities. Transfer menus between sites seamlessly with intelligent per-item mapping that rewrites page, post, and category references for the target site. Key Features Automatic backup of menus when they are updated Works with both classic menus (nav_menu) and block-theme menus (wp_navigation posts edited in the Site Editor) Site Editor inspector panel — back up, restore, rename, or apply a backup from another menu without leaving the editor, with a Navigation block selected In-place restore replaces the existing menu directly, no duplicate menus, theme locations stay assigned Import and export menus as JSON files for portability or locally saved backups Multi-menu export and import — select multiple menus or backups to export in a single file Transfer menus between sites with intelligent object mapping, can be used to update menus from development to production sites without full site migration Manual mapping interface to override automatic matches and map menu items to specific pages, posts, or taxonomies during import Preserves complete menu structure: hierarchy, theme locations, CSS classes, and third-party plugin data (post_meta) icons etc… Bulk actions — select multiple backups to export or delete at once Rename backups inline with a click Configurable maximum number of backups to keep See who saved and created the backup Tab-based interface for better organisation Simple and intuitive user interface No database modifications required Lightweight and fast How It Works The plugin automatically creates a backup whenever you update a menu Backups are stored in the WordPress options table with complete menu structure (hierarchy, locations, CSS classes, custom post_meta) Manage backups from the legacy Menus page (classic themes), the Appearance > Menu Backups page (block themes), or inline from the Site Editor inspector when editing a Navigation block — rename, export, delete, restore, or bulk-select Restore any previous version with a single click, the existing menu is updated in-place, keeping theme locations intact Export one or multiple menus as a single JSON file for portability or import to other sites Configure the maximum number of backups to keep in the settings Requirements WordPress 5.0 or higher PHP 7.2 or higher What Users Have to Say on Reddit “That’s a super useful idea! Menus are so easy to wipe out by accident, and restoring from a full backup always feels like overkill. Nice work!” “Really appreciate it, This will come in handy alot!” “Oh man, I’ve done this before too. Lost a big menu while trying to rearrange items and it was gone in a click. Ended up re-building from scratch. This plugin sounds like a lifesaver — surprised WordPress hasn’t built something like this in by default.” “Kind of an automatic backup vs having to schedule one.” “that’s a killer quality of life plugin wp’s missing so many of those “one click undo” features for common mistakes” “Great idea! I do this more often than I care to admit. This needs to be in Core!” “Dude I literally do this all the time and actually did it less than an hour ago. I hate how the WordPress menu isn’t stored normally. Thanks for this!”

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 --yes wp dbmanager delete ... --yes wp dbmanager email [email protected] --yes wp dbmanager optimize --all --yes wp dbmanager repair wp_options --yes wp dbmanager empty ... --yes wp dbmanager drop ... --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.