WP Migrate DB Pro 1.8 Released: Import SQL File & More

The WP Migrate DB Pro team is very excited to announce the release of version 1.8! We’ve packed in an awesome new feature and improved a bunch of existing functionality. So without further ado, let’s go over what’s new!

Import any SQL file

Remember in the old days you would export your file from WP Migrate DB Pro and then have to import said export through phpMyAdmin? Well no more! The biggest new feature in version 1.8 is the addition of the SQL Import functionality.

WP Migrate DB Pro can now import any MySQL exports generated by other tools and run a find and replace on the imported data. And if you import an export generated by WP Migrate DB Pro, it will pre-fill the find and replace fields automatically for you.

The pre-population magic is actually handled by some special SQL comments we now add to the header of a WP Migrate DB Pro export file. If these comments are absent, as with a phpMyAdmin export, there is no magic 😢 but you can still import just fine. You’ll just have to manually add your own find and replace values to run after the file is imported.

Current WP Migrate DB Pro users will notice the familiar migration progress interface when running imports. There are 2 new steps involved, the upload of the SQL file and the actual import of the SQL, after which the well-known find and replace is run.

We took extra care to make sure that even the largest files can be uploaded easily – the upload portion of the import uses the HTML5 FileReader API to split the export file up and upload it over multiple requests. This means that the import feature should work on any host, regardless of the upload limits or max request size.

We’ve also added a new CLI import sub-command to the CLI Addon. You can run it with the following command:

wp migratedb import <import-file> [--find=<strings>] [--replace=<strings>] [--backup=<prefix|selected|table_one,table_two,table_etc>]

If you’re into scripting your dev workflow (who isn’t?), this is an awesome addition. You could use this command to load in a starter WordPress database and have a new development environment set up in a flash!

This feature is an awesome complement to WP Migrate DB Pro’s Export functionality and will not only speed up the backup/restore process but allow you to run migrations around firewalls and complicated hosting setups where MDB is unable to make a connection between sites.

You can read more about Import migrations in the documentation. Hat tip to Matt for implementing this great new feature!

Plugins and Themes Disabled by Default

Another big change in this release is that plugins and themes are prevented from loading during WP Migrate DB Pro migration requests with Compatibility Mode.

Prior to version 1.8, Compatibility Mode was an optional setting that allowed you to control which WordPress plugins were loaded for requests made by WP Migrate DB Pro. This was done by adding an MU (must use) plugin. A regular WordPress plugin isn’t able to control which plugins are loaded and which aren’t. So what Compatibility Mode did was add an MU plugin when you toggled Compatibility Mode on.

As of version 1.8 Compatibility Mode still uses an MU plugin but is enabled by default when you install or upgrade WP Migrate DB Pro. We did this largely because in support requests we often ask ‘Have you tried enabling Compatibility Mode?’. Because of this, we figured why not disable themes and plugins by default? So that’s what we did.

How we do this is by unloading some options in the wp_options table using the option_{$option} filter, we never actually touch plugins or files.

In the unlikely event that you need to disable Compatibility Mode (remember, it’s on by default now), you can switch it off in the Settings tab:

Overall this should result in faster, more reliable migrations. For more details about Compatibility Mode, check out our documentation.

Reloading After Migrations

One of the things that always bothered us was having to refresh the WP Migrate DB Pro page after pulling in a another site. If you don’t reload you’ll often see invalid-nonce errors or strange behaviour if you try to run another migration or change settings before refreshing and logging back in.

To fix this we now reload the page if you pull in the wp_options, wp_users or wp_usermeta tables.

Handling of utf8mb4_unicode_520_ci

Have you seen this error on your site during a migration?

WordPress database error: [Unknown collation: 'utf8mb4_unicode_520_ci']

This can crop up in WordPress 4.6+ when you’re migrating from a site that’s using a certain type of MySQL multibyte encoding (utf8mb4_unicode_520_ci in MySQL 5.6+) to a site that isn’t (utf8_unicode_ci in < MySQL 5.5). In case you’re wondering, multibyte encoding allows for special characters like emojis (🍔) to be used in your post content without issue.

In version 1.8 we’re now checking if your MySQL server works with this multibyte encoding and doing some lower level compatibility checking to make sure content is migrated between these different versions.

This under the hood addition should help make sure your migrations run as smooth as 🥞^{(butter on pancakes)}.

And more

We’ve also included a bunch of other bug fixes and improvements:

Diagnostic Log – Added additional information to the diagnostic log to help us help you, should you run into trouble with WP Migrate DB Pro
Handling Invalid Characters – Helpful error message for migrations that fail due to invalid characters in the database with optional stripping of invalid characters provided by a new constant.
wp_site and wp_blogs tables – Find & Replace now runs on the wp_site and wp_blogs tables in multisite installs

You can see a full list of changes in the changelog.

Next up

Not to be outdone, but we’re planning our next version to be an even bigger release. It’s going introduce a brand new addon that will migrate theme and plugin files between sites.

You read that right.

The goal is to allow you to move a complete site, database, media AND theme/plugin files between WordPress installs. It’s a tall order, but we’ve got a head start on planning and have a path forward.

We increased the WP Migrate DB Pro team's crayon budget 🎨 #comingsoon #plugindevelopment #webdev pic.twitter.com/T0hWfSX2Ec
— Delicious Brains Inc (@dliciousbrains) August 30, 2017

The plan is for all of us on #team-mdb ( ) to work on this addon together – at the same time. We might even put together a new base transfer module for the entire plugin. No sweat…

Phew! That was a big release. Excuse me while I take a breather. Cheers!

This entry was posted in WP Migrate DB Pro and tagged WP Migrate DB Pro, WordPress, New Release, Migration Tools, New Features, Compatibility, SQL Import.

.replybox-fallback, .replybox-fallback ul { list-style: none; }

Mary-Ann says:

September 14, 2017 at 1:38 pm

Very excited to see the next big release with the plugin/theme file migration. Awesome stuff!

Adam Silverman says:

September 14, 2017 at 1:48 pm

Very exciting stuff. Love it – Thank you for all your hard work. It allows me to focus more on the code we’re writing and less on deploying and syncing with live environments. We all appreciate it! Adam Silverman Silverbox Development

Joe Fletcher says:

September 14, 2017 at 1:52 pm

Importing sql files – yes! I was just wondering why I couldn’t do that via Migrate DB. This really helps. Migrating theme/plugin files = totally awesome. Can’t wait. My input – it would be great if you can selectively choose files within the themes and plugins. For example, I use Roots Sage with WP Engine and push my dev changes via git EXCEPT for the theme asset files that are created in a ‘dist’ dir that I do not commit to the git repo. The only way I can get those files onto WP Engine is thru sftp. If I could migrate the dist dir with Migrate DB Pro, that would save me a step. I wouldn’t want to use Migrate DB Pro to migrate the entire theme b/c that is managed via git.

Alex says:

September 14, 2017 at 3:17 pm

I 100% support this ^. I have the same issue with git push to WP Engine. I have to push the entire repo when I’d much rather use gulp dist to generate only the necessary files. git + WP Engine can’t do this.

Reply
- Joe Fletcher says:
  
  September 14, 2017 at 3:30 pm
  
  Glad to hear I’m not alone 🙂
  
  Reply
  - Alex says:
    
    September 14, 2017 at 3:48 pm
    
    For sure! Part of me doesn’t mind it because I’m in git all day and it’s easy and who cares if all kinds of unnecessary files are pushed to the production server, but part of me wishes that only the gulp dist directory could be routed directly to the theme directory and that’s it. Each has advantages. I’d love to see another option.
    
    Reply
Brad says:

September 14, 2017 at 9:08 pm

Yup, we have a git deployment system setup for the deliciousbrains.com site and we just commit the generated assets but we do end up with those generated assets conflicting all the time, so it’s far from the best solution. Since we have control of the server, we’re planning on just building the assets on the server at deploy time. Not exactly a solution suitable for a WP Engine account though.

Reply

Steve says:

September 14, 2017 at 2:19 pm

Very nice… and just in time! 🙂 I’m hoping to try and bring back a site where the server is gone and I just have some backup files and an SQL dump. Yay!

Jay Miller says:

September 14, 2017 at 2:27 pm

Thank you! I’ve spent countless hours using phpMyAdmin or creating a inbetween site to transfer a live site to a new live site with the same domain. It’s such a mess and a pain, this will be incredibly helpful.

Alex says:

September 14, 2017 at 3:16 pm

The import tool will be really useful setting up developers on local installs for new projects. There are a lot of steps needed to set up a local install – git for version controlled files, zip import for all non-version-controlled WordPress core files, and then the local databases. Using the import tool, I can directly send each developer a custom sql file based on their local environment and have them import it via the plugin rather than Sequel Pro etc. Good stuff!

Alex says:

September 14, 2017 at 3:51 pm

I’d do that but I have to share the repo with other developers. I tried using a separate repo in the dist directory. But this wouldn’t work (that I know of) as WP Engine has the repo associated with the root of the install, not the theme folder. So (that I know of) it’s not possible to push just the theme directory. Anyone know of a different solution?

Joe Fletcher says:

September 14, 2017 at 4:49 pm

The 2 solutions I’ve tried: 1) scp the dist dir. I forget exactly how I did this, but since it uses the sftp protocol, WP Engine allowed it. But this was buggy and unpredictable. 2) I automate Transmit with Automator to FTP the dist dir. I trigger that along with my deploy command lines. I script this, but the steps are: gulp –production open upload-dist.app (my Automator for Transmit to FTP the dist dir) git push production master wp migratedb push yada yada The Transmit solution is buggy and not elegant, and you can see why using WP Migrate DB Pro instead would eliminate this unpleasant step.

Reply