Media Files addon 1.3 & CLI addon 1.1 Released

We’ve put a lot of work into these releases and are happy to be sharing them with you finally. For a brief list of the changes, see the Media Files addon changelog or the CLI addon changelog. For the details, checkout the video above or continue reading.

The Media Files addon has been almost entirely rewritten. Customers with very large media libraries (100,000+ attachments) were running into timeouts with certain web hosting configurations. We had to redesign the whole process of comparing remote and local filesystems to accommodate the limitations of these servers. It took several iterations, but Iain did some solid coding and hammered home a solution we’re very happy with.

In previous versions there was no feedback during the comparison stage of the media file migration. It just said “Determining which media files to migrate, please wait…” and had a spinner.

Database progress of a WP Migrate DB Pro push migration

Now, you can see the progress of the comparison stage as it goes through batches of attachments (500 by default — can be changed with a filter) and a second progress bar shows the upload/download progress.

Media files progress of a WP Migrate DB Pro push migration

The new CLI addon is a huge improvement over the barebones first release. We’ve renamed the command to be more readable and introduced new push and pull subcommands. In 1.0, the command was:

$ wp wpmdb

The extra “wp” seemed a bit awkward. We considered just dropping it and making the command mdb, but it seemed too short and cryptic. We finally settled on migratedb:

$ wp migratedb

We’ve made the old wpmdb command an alias of the new command, so it’s fully backward compatible.

In version 1.0, we had a single subcommand:

$ wp wpmdb migrate <profile_id>

As we were introducing push and pull subcommands in 1.1, a migrate subcommand seemed a bit ambiguous and confusing. We decided to replace it with a profile subcommand:

$ wp migratedb profile <profile_id>

We plan to extend the profile subcommand to enable managing of profiles (e.g. list, add, remove) as well.

In version 1.0, you still needed to use the UI to create a profile before you could run a migration via the CLI. With the new push and pull subcommands this is no longer the case.

WP Migrate DB Pro command line usage

All the push/pull options you’re familiar with in the UI are available on the CLI allowing you to run any kind of push/pull migration from the CLI that you can run from the UI. And we’ve fully documented the commands in WP-CLI’s help format so you can view a full man page with details about each subcommand.

WP Migrate DB Pro command line man page

In version 1.0 the only feedback you got was “Success”. Sometimes even if the migration wasn’t successful. We now provide lots of feedback about the progress of your migration, including the progress of the media files comparison, and when there are errors.

WP Migrate DB Pro migration progress on the command line

The CLI addon documentation has been updated with the changes and full documentation of the subcommands and their options.

We’ve also released a new version (1.4.5) of WP Migrate DB Pro as some minor changes were needed to make it compatible with these new addons.

Next up, we’ve actually started work on the Multisite Tools addon that we’ve been promising for a long time. The first release will allow you to extract a subsite as an SQL file to create a new single-site install, automating the manual steps in our doc. We’re also working on a pro version of our Amazon S3 & CloudFront plugin.

About the Author

Brad Touesnard

As founder of Delicious Brains Inc., Brad wears many hats; from coding and design, to marketing and partnerships. Before starting Delicious Brains, Brad was a busy freelance web developer, specializing in front-end development.

  • Love the updates, well done 🙂

  • This is awesome. Seriously, you guys deserve a huge pat on the back. This will make command line ninjas everywhere stoked to migrate databases like this.

  • Hell yes, this is such a really good news. Everything works fine for me, except one thing for which i’ve already mailed you, the –preserve-active-plugins option.
    Some months ago, i’ve sended you a mail about this option that was not working for me, and you told me that this was a known issue that would be fixed in the next release. Do you have any information about this ? Is this still an issue or am i the only one who got this problem ?

    After running my vagrant provisioning script (in which i use the shown command below), i go to, and i can’t see the proper last version of my website because plugins are not activated.
    If i go to admin -> plugins, i only see two plugins activated which are thoses activated by the TGM plugin bundled in my personal theme which managed some auto-activating hooks on some required plugins. Could this be a conflict with the TGM plugin ? is this option working for someone with or without TGM ?

    Here is the command i used in my provisionner, everything looks ok there :

    wp migratedb pull MY_SECRET_KEY –find=//,/var/www/path/to/web –replace=//,/srv/www/path/to/htdocs –preserve-active-plugins –include-transients –backup=prefix –media=remove-and-copy

    Any advice ?
    Thanks a lot.

  • I’m envious of you guys that can utilize WP-CLI. I’m on WP Engine, and they do not offer SSH access. They’re so good at everything else, I won’t consider switching.

    For those of us that do not have SSH, it would be nice to have some sort of code snippet we can copy and paste into WP Migrate DB Pro. So, let’s say I get the tables for a migration setup just the way I want it, all the settings, etc…. I would like to be able to copy that recipe as a code snippet. Maybe that code is setup in an XML format? Then I could store that code snippet and use it whenever I need to. I realize there are profiles now, but the profiles don’t seem to stick from one staging to production.