10up / mu-migration

This WP-CLI plugin makes the process of moving sites from single WordPress sites to a Multisite instance (or vice-versa) much easier. It exports everything into a zip package which can be used to automatically import it within the desired Multisite installation.

MU-Migration

This WP-CLI plugin makes the process of moving sites from single WordPress sites to a Multisite instance (or vice-versa) much easier. It exports everything into a zip package which can be used to automatically import it within the desired Multisite installation.

Install

Requirements

• PHP >= 7.1
• WP-CLI >= 0.23

Via WP-CLI Package Manager (requires wp-cli >= 0.23)

Just run wp package install 10up/mu-migration.

If you run into memory issues when installing the package, it's a known WP-CLI issue. Check this out for a workaround.

Installing as a plugin

Clone this repo onto plugins/ folder, run composer install to fetch dependencies and activate the plugin.

You need to install this on both the site you're moving and the target Multisite installation.

Why do I need this?

Moving single WordPress sites to a Multisite environment (or the opposite) can be challenging, specially if you're moving more than one site to Multisite. You'd need to replace tables prefix, update post_author and wc_customer_user (if WooCommerce is installed) with the new users ID (Multisite has a shared users table, so if you're moving more than one site you can't guarantee that users will have the same IDs) and more.

There are also a few housekeeping tasks that needs to be done to make sure that the new site will work smoothly and without losing any data.

How it works

With a simple command you can export a whole site into a zip package.

$ wp mu-migration export all site.zip --plugins --themes --uploads

The above command will export users, tables, plugins folder, themes folder and the uploads folder to a unique zip file that you can move to the Multisite server in order to be imported with the import all command. The optional flags --plugins --themes --uploads, add the plugins folder, themes folder and uploads folder to the zip file respectively.

You can also export subsites from another multisite instance, to do so pass the --blog_id parameter. E.g:

$ wp mu-migration export all subsite.zip --blog_id=2

The following command can be used to import a site from a zip package.

$ wp mu-migration import all site.zip

If importing into Multisite, it will create a new site within your Multisite network based on the site you have just exported, if importing into a single install, it will override your single install with the exported subsite.

The import all command will take care of everything that needs to be done when moving a site to Multisite (replacing tables prefix, updating post_author IDs and etc).

If you need to set up a new url for the site you're importing (if importing into staging or local environments for example), you can pass it to the import all command.

$ wp mu-migration import all site.zip --new_url=multisite.dev/site

The import command also supports a --mysql-single-transaction parameter that will wrap the sql export into a single transaction to commit all changes from the import at one time preventing the write from overwhelming the database server, especially in clustered mysql enviroments.

You can also pass --blog_id to the import all command, in that case the import will override an existing subsite.

$ wp mu-migration import all site.zip --new_url=multisite.dev/site --blog_id=3

In some edge cases it's possible that MU-Migration won't be able to recognize all custom tables while doing the export of a subsite in multisite so if you need to move non-default tables, you can use --tables or --non-default-tables param. E.g

$ wp mu-migration export all subsite.zip --blog_id=1 --non-default-tables=wp_my_custom_table,wp_my_custom_table_2

If you pass --tables it will export only the tables you have passed. So if you use it make sure to pass all tables that you want to be exported, including the default tables.

After the migration you can also manage users password (reset passwords and/or force users to reset their passwords).

$ wp mu-migration update_passwords [<newpassword>] [--blog_id=<blog_id>] [--reset] [--send_email] [--include=<users_id>]  [--exclude=<users_id>]

E.g

The following command will update all users passwords of the site with ID 3 to new_weak_password.

$ wp mu-migration update_passwords 'new_weak_password' --blog_id=3

This next command will reset all users passwords to a random secure password and it will send a reset email to all users.

$ wp mu-migration update_passwords --reset --blog_id=3 --send_email

Notes

If your theme and plugins have been done in the WordPress way, you should not have major problem after the migration, keep in mind that some themes may experience incompatibilities issue if doing things in the wrong way. (E.g hardcoded links like '/contact' etc) Depending of the codebase of the site you're migrating you may need to push some fixes to your code.

Support Level

Stable: 10up is not planning to develop any new features for this, but will still respond to bug reports and security concerns. We welcome PRs, but any that include new features should be small and easy to integrate and should not include breaking changes. We otherwise intend to keep this tested up to the most recent version of WordPress.

Credits

Created by Nícholas André (@nicholas_io), at 10up.com.

Like what you see?

mu-migration's Issues

Upload import not working with older multisites

I'm trying to move a site between a couple multisites created prior to WP 3.5, meaning they store site uploads in blogs.dir. The uploads are stored correctly in the exported zip, but they aren't moved into the new site. The attachment posts are in the media library, but the directory structure isn't created within blogs.dir and the files aren't extracted.

Windows support

Is your enhancement related to a problem? Please describe.
I was able to install on Windows Server without errors but when trying to export then gave an error & didn't work:

Exporting site meta data...
Exporting users...
Exporting tables
'grep' is not recognized as an internal or external command,
operable program or batch file.
Zipping files....
Warning: Unable to create archive

Describe the solution you'd like
Either implement full Windows support or do a simple test first before allowing it to be installed

I'm not that surprised that it isn't compatible but Windows is certainly used for development/staging of sites and using MU-Migration & WP-CLI to migrate between different dev environments would be great for multiple reasons.

Consider adding functional tests to this project

Functional tests are an integral ingredient of highly-quality, maintainable commands. WP-CLI tries to make it as easy as possible to add functional tests to your package with its wp scaffold package-tests command:

https://github.com/wp-cli/scaffold-package-command#wp-scaffold-package-tests

I'd encourage you to consider adding functional tests to your package :) By starting your functional tests early on, it also makes it much easier to maintain your project over time.

Imported subsite is not working

I export a subsite from a live system:

wp mu-migration export all subsite.zip --blog_id=2 --path=/var/www/html/wordpress --plugins --themes --uploads

I then import into a new (clean, multisite) Wordpress installation:

wp mu-migration import all subsite.zip --new_url=mynewsite.com/wordpress/subsite --blog_id=2

When finished, the site appears in the list of sites in the Network Admin, but if I try to Visit Site or show the Dashboard, I get a connection timeout error in my browser.

One curious thing is that during the import, I see the following messages:
Extracting zip package...
Importing tables...
Warning: Something went wrong while running sed
Warning: Something went wrong while running sed
Warning: Something went wrong while running sed
Warning: Something went wrong while running sed
Warning: Something went wrong while running sed
Warning: Something went wrong while running sed
Warning: Something went wrong while running sed
Warning: Something went wrong while running sed
Moving files...
etc...

Any ideas on why this is not working? Anything I can try to help track down the issue? Note that the default site continues to work, and I can still access the Network Admin pages, just not my imported subsite.

p.s. this is a new Wordpress install, so I can easily delete Wordpress and database, and set it up again - takes me less than 5 minutes!

Child theme from site of network install not exported ?

Hello,

(First of all, your package is awesome :) )

A feedback of a migration I've just made : I exported a site from a network install. When importing the zip file (as a single site install), I saw the child theme had not been imported (child theme of TwentyThirteen).

Hope this helps

Use JSON instead of CSV for users

And use a JSON stream parser to read/write https://github.com/salsify/jsonstreamingparser/

Zip file is damage with folders

Hello Team

I have use MU-Migration in windows. When i am creating zip file then all the folders are blank in wp-content folder.

You can see attached screenshot and tell me know what am i missing?

Thanks in advanced.

Cannot use composer on WP Engine

I needed this on a client's site hosted on WP Engine, and they don't support composer (or just about anything else for that matter!).

Is there a way to get this working without installing dependencies on the WP Engine server?

Project still active?

Trying to add MU-migration via command line, and continue to get this error. In my vagrant box I was able to allot more memory via VirtualBox. On a real life server I have limited knowledge (but sudo privileges), yet I keep running into roadblocks. The most common error:

PHP Fatal error: Allowed memory size of 536870912 bytes exhausted (tried to allocate 33554432 bytes) in phar:///usr/local/bin/wp/vendor/composer/composer/src/Composer/DependencyResolver/RuleSetGenerator.php on line 126

readme updates

It's not obvious the level of support provided for this repo, so let's add some clarification.

• add support level section and badge
• add license badge

Flush all caches after the import process is done

Posted in error

Sorry, can't figure out how to delete this.

can I use it for multisite WP to other multisite wordpress migration???

Hi, good day, I need migrate a whole multisite wp to other server with other domain, would I use this plugin for achieve that???

other small question, I notice than there is an import command, do this create the db and tables or do I need create the db and then import the tables??? I ask because I'd prefer the second way because I think use other db name...

thank you...

Fails when using `wp --path`

When using wp-cli with the --path flag, the import of content fails (themes, plugins and uploads), because the zip file contains the file structure of the --path parameter too.

i.e.
Without --path

mu-migration-127809963mysite-com.csv
mu-migration-127809963mysite-com.json
mu-migration-127809963mysite-com.sql
wp-content/{plugins,themes,uploads}

With --path="mysite.com"

mu-migration-127809963mysite-com.csv
mu-migration-127809963mysite-com.json
mu-migration-127809963mysite-com.sql
mysite.com/wp-content/{plugins,themes,uploads}

So as you can see, the mysite.com folder is an extra step when using --path, so the proper folders can't be found in class-mu-migration-import.php:all().

I guess the question now is, should the extra folder depth be there or now.
If not, then the code would need to take --path into account.
If yes, then the search for the wp-content folder needs to be adjusted.

Either way, I'm happy to PR this.

Search-replace of uploads paths is innefective when importing from multi-site into single-site

Describe the bug

If a blog is exported from a multi-site installation without passing --blog_id and then imported into a single-site installation with a --new_url, then the search-replace command for uploads paths does not effectivelly replace wp-content/uploads/sites/$blog_id for wp-content/uploads.

Steps to Reproduce

Export the website from a multi-site installation using exactly the following command line options:

wp mu-migration export all myblog.zip --url=myblog.example.com

Then import it into a single-site installation using exactly the following command line options:

wp mu-migration import all myblog.zip --new_url=example.com/myblog

In our case, we noticed that the logo was not showing up after migration. It so happens that the theme we're using stores logo info in the wp_options table and the path was not replaced at all (note that the URL was replaced correctly):

MariaDB [myblog]> select option_name, option_value from wp_options where option_name = 'theme_mods_morning';
+--------------------+---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
| option_name        | option_value                                                                                                                                                                                                                                |
+--------------------+---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
| theme_mods_morning | a:5:{i:0;b:0;s:18:"nav_menu_locations";a:1:{s:7:"primary";i:2;}s:11:"logo_upload";s:71:"https://example.com/myblog/wp-content/uploads/sites/30/2019/10/mama.png";s:10:"search_bar";s:4:"show";s:18:"custom_css_post_id";i:-1;} |
+--------------------+---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
1 row in set (0.00 sec)

Expected behavior

Uploads paths should have been replaced correctly throughout the database (and the logo should appear in our blog).

Environment information

• Plugin and version: MU-Migration 0.3.2
• Theme and version: Morning 1.02 (https://www.competethemes.com/morning)

Additional context

I did some investigation and I found that:

• Despite in the original installation blog_id = 30, the exported .json file contains blog_id = 1, and thus this line was never executed when importing.
• The above happens because if --blog_id is not passed when exporting, this line is never executed and then the .json file ends up with blog_id = 1.
• I don't really understand if this is an expected behavior of the export command (and then passing --blog_id when exporting is "mandatory" for the export/import case described here) or if it is a bug and this whole bug report should've actually been about this specific behavior.
• If I add --blog_id=30 to the command line when exporting, the issue described in this bug report does not manifest itself.

Remove vendor directory from repository

The git repository currently includes a vendor/ directory, which should be excluded via the .gitignore file, as otherwise we're storing duplicates of third-party libraries that should be pulled in via Composer.

Consider adding `--blog_url` or `--blog_name` as an alternate to `--blog_id`

One issue that I have is that my local multisite blog_id is out of sync with my remote multisite blog_id. It would be much easier to reference the site slug (which is the same in both) instead of the ID which will required an extra call.

blog_id="$(site_url=http://example.test/sitename/; wp site list | awk -v site_url=$site_url '{ if( $2 == site_url ) print $1; }')"; 
echo $blog_id;

For example:

$ wp mu-migration export all subsite.zip --blog_url=http://example.test/sitename/

$ wp mu-migration export all subsite.zip --blog_name=sitename

Images rename PHP error

PHP Warning: rename(mu-migration1575829182//wp-content/uploads/wp-clone/index.html,/opt/bitnami/apps/wordpress/htdocs/wp-content/uploads/sites/3/wp-clone/index.html): No such file or directory in /home/bitnami/.wp-cli/packages/vendor/10up/mu-migration/includes/helpers.php on line 114

Some Images dont show up , I think its becasue of the rename failure during Import,

Error: Unable to get the list of tables to be exported

When issuing this command (wp mu-migration export all site.zip --plugins --themes --uploads) on any site I have tried, I get the following
Exporting site meta data...
Exporting users...
Exporting tables
Error: Unable to get the list of tables to be exported

A CSV file and JSON file are created and have a lot of data.
wp db export does export the whole database with no problem
wp db tables lists all of the WP tables

replacing $tables = \WP_CLI::launch_self( with $tables = \WP_CLI::runcommand( on line 104 of class-mu-migration-export.php lets it continue if you manually specify the tables but then I get
"Something went wrong while trying to export the database" but an .sql file is created with all of the tables and data.

I tried using $export = \WP_CLI::runcommand('db export', array('return' => true)); that I found in another post with that error message but I still get the same error.

IIS/My SQL 5.6/PHP 7.1.11

Cloning a subsite using export/import --new_url affects the source subsite domain

Describe the bug

When cloning a subsite in a multisite install using export/import, the source subsite domain is updated to the target subsite URL.

Steps to Reproduce

1. wp mu-migration export all --blog_id=8 /tmp/blog_template.zip --themes --plugins --uploads
2. wp mu-migration import all /tmp/blog_template.zip --new_url="https://mynew.url"
3. blog_id=8 gets https://mynew.url as domain in DB

Expected behavior

source subsite is not affected by the creation of a new subsite when using export/import with --new_url

Search-Replace for uploads path when moving a subsite to another multisite network is incorrect

Overriding the main site of a network might break MU-Migration

Overriding the main site of a network with a url other than the one set in wp-config.php breaks MU-Migration.

E.g:

wp mu-migration import all site.zip --new_url=http://newdomain.com

If the domain set in wp-config.php for the network is not newdomain.com MU-Migration will not work properly because the main site will become inaccessible by WP-CLI. We should either warn the user about this or try to update the constant in wp-config as a first step.

Plugins are not moved to their proper destination when importing.

$plugin_folder = basename( $plugin_name );

Basename does not return the directory name, which is what we need. Should be using dirname instead.

Warning: Unable to create the zip file

Getting this warning and the zip file is not generated.

I change includes/commands/class-mu-migration-export.php to print the exception, get this error:

Warning: exception 'Alchemy\Zippy\Exception\InvalidArgumentException' with message 'Invalid path mu-migration-430119266ananda-events.sql' in /home/pg20619/.wp-cli/packages/vendor/10up/mu-migration/vendor/alchemy/zippy/src/Resource/Teleporter/LocalTeleporter.php:56
Stack trace:
#0 /home/pg20619/.wp-cli/packages/vendor/10up/mu-migration/vendor/alchemy/zippy/src/Resource/ResourceTeleporter.php(41): Alchemy\Zippy\Resource\Teleporter\LocalTeleporter->teleport(Object(Alchemy\Zippy\Resource\Resource), '/tmp/zippy_5bf2...')
#1 /home/pg20619/.wp-cli/packages/vendor/10up/mu-migration/vendor/alchemy/zippy/src/Resource/ResourceManager.php(67): Alchemy\Zippy\Resource\ResourceTeleporter->teleport('/tmp/zippy_5bf2...', Object(Alchemy\Zippy\Resource\Resource))
#2 /home/pg20619/.wp-cli/packages/vendor/10up/mu-migration/vendor/alchemy/zippy/src/Adapter/ZipExtensionAdapter.php(247): Alchemy\Zippy\Resource\ResourceManager->handle('/home/pg20619/p...', Array)
#3 /home/pg20619/.wp-cli/packages/vendor/10up/mu-migration/vendor/alchemy/zippy/src/Adapter/ZipExtensionAdapter.php(207): Alchemy\Zippy\Adapter\ZipExtensionAdapter->addEntries(Object(Alchemy\Zippy\Adapter\Resource\ZipArchiveResource), Array, true)
#4 /home/pg20619/.wp-cli/packages/vendor/10up/mu-migration/vendor/alchemy/zippy/src/Adapter/AbstractAdapter.php(58): Alchemy\Zippy\Adapter\ZipExtensionAdapter->doCreate('/home/pg20619/p...', Array, true)
#5 /home/pg20619/.wp-cli/packages/vendor/10up/mu-migration/includes/commands/class-mu-migration-export.php(513): Alchemy\Zippy\Adapter\AbstractAdapter->create('events.zip', Array, true)
#6 [internal function]: TenUp\MU_Migration\Commands\ExportCommand->all(Array, Array)
#7 phar:///home/pg20619/wp-cli/wp-cli.phar/vendor/wp-cli/wp-cli/php/WP_CLI/Dispatcher/CommandFactory.php(89): call_user_func(Array, Array, Array)
#8 [internal function]: WP_CLI\Dispatcher\CommandFactory::WP_CLI\Dispatcher{closure}(Array, Array)
#9 phar:///home/pg20619/wp-cli/wp-cli.phar/vendor/wp-cli/wp-cli/php/WP_CLI/Dispatcher/Subcommand.php(425): call_user_func(Object(Closure), Array, Array)
#10 phar:///home/pg20619/wp-cli/wp-cli.phar/vendor/wp-cli/wp-cli/php/WP_CLI/Runner.php(365): WP_CLI\Dispatcher\Subcommand->invoke(Array, Array, Array)
#11 phar:///home/pg20619/wp-cli/wp-cli.phar/vendor/wp-cli/wp-cli/php/WP_CLI/Runner.php(388): WP_CLI\Runner->run_command(Array, Array)
#12 phar:///home/pg20619/wp-cli/wp-cli.phar/vendor/wp-cli/wp-cli/php/WP_CLI/Runner.php(1113): WP_CLI\Runner->_run_command_and_exit()
#13 phar:///home/pg20619/wp-cli/wp-cli.phar/vendor/wp-cli/wp-cli/php/WP_CLI/Bootstrap/LaunchRunner.php(23): WP_CLI\Runner->start()
#14 phar:///home/pg20619/wp-cli/wp-cli.phar/vendor/wp-cli/wp-cli/php/bootstrap.php(74): WP_CLI\Bootstrap\LaunchRunner->process(Object(WP_CLI\Bootstrap\BootstrapState))
#15 phar:///home/pg20619/wp-cli/wp-cli.phar/vendor/wp-cli/wp-cli/php/wp-cli.php(23): WP_CLI\bootstrap()
#16 phar:///home/pg20619/wp-cli/wp-cli.phar/php/boot-phar.php(11): include('phar:///home/pg...')
#17 /home/pg20619/wp-cli/wp-cli.phar(4): include('phar:///home/pg...')
#18 {main}Unable to create the zip file

exporting small subsite(s) with basic wp_ tables: Error: Something went wrong while trying to export the database

wp mu-migration export all site.zip --plugins --themes --uploads --blog_id=2
Exporting site meta data...
Exporting users...
Exporting tables
Error: Something went wrong while trying to export the database

The above command is an attempt to export the tiniest of subsites , yet it produces this error. Other blog_id numbers do the same thing. This is a multisite w/subdomains, php 5.6 and CentOS 5.X- or 6.X

What commonly triggers this message?

User Friendly

Hi,

We can make the plugin more interactive by showing messages on each step.
E.G Upon export if you do not pass any flag it will only export users by default. So it should be interactive if you like to add themes, plugins uploads? some suggestions like if a site is big we do not recommend to import the uploads as they can be synced later.

Housekeeping

I really like this plugin/package and am super grateful for your work on it!
Has been so incredibly helpful to me.

Would you be open for a general housekeeping of the code? I love nice-looking code and would love to contribute more.

The functionality would obviously stay the same, this is mainly for the visual poetry part of the code 😇 (with some extras of slight optimisations)

• #21 Fix typos and grammar
• #22 Clean up and complete docblocks
• #23 Clean up code to comply with WordPress coding standards
• #24 Slight code optimisations/modifications

I set the points up as checkboxes, as I'd be making a PR for each one, to keep it manageable and easy for you to check the changes.

What do you say?

Error: 'mu-migration' is not a registered wp command. See 'wp help' for available commands.

When i try to export a subsite from a multisite network using: wp mu-migration export all subsite.zip --blog_id=2, it's given that error.

I am running wp_cli in a Local/Flywheel virtual machine with SSH prompt.

Thanks in advance.

Create a clone of multisite

Hi,
I want to create a preprod environment of my network. (clone of porduction environment)
Is it possible with your plugin or we can just export one to one the subsites ?

Regards

import into a single site

Can I use this to import into a single site, i.e. export a subsite and then import it into a single site?

While importing, search and replace on db should be done without protocol

I'm trying to import/export a blog from a multisite to a multisite. I have to change the url of the site, so I'm using the --new_url param.
Search and replace is running (it writes the correct new url in wp_blogs table), but I think that search and replace should be done without protocol, to upload (at least) homeurl and siteurl in wp_options table. In that table, the urls are stored without protocols.

export all doesn't, export all that is

Describe the bug
export all doesn't, export all that is it just create a zip without uploads, plugins and themes.

Steps to Reproduce

1. go to /public
2. enter on 'wp mu-migration export all sitename.zip
3. result:Exporting site meta data...
   Exporting users...
   Exporting tables
   Zipping files....
   Success: A zip file named sitename.zip has been created

Expected behavior

I expect ALL to be exported, as if I enter --themes --plugins --uploads as params too

Screenshots

Environment information

• Device:
• OS:
• Browser and version:
• WordPress version:

• Plugins and version:
• Theme and version:

• Site Health Info:

Additional context

Importing site does not completely rewrite table data.

Running:

PHP 7.2.10
WP-CLI 2.0.0-alpha-d0fe445

We have a blog that is part of a multisite that I exported, and the export went fine.

When I imported the site into a different multisite install on another server, setting a specific blog_id and new_url option, it did not correctly complete the rewrite, and did not add the site to the wp_blogs table correctly. The intent was to keep the same blog_id, and that there was no blog with this ID on the destination multisite install. Here is the command run (with URL made generic):

user@my-website:/var/www/html$ wp mu-migration import all ~/subsite-2.zip --new_url=my-website.com/program1 --blog_id=2
Extracting zip package...
Importing tables...
Moving files...
Moving Uploads...
Importing Users...
PHP Notice:  Trying to get property 'domain' of non-object in /home/ubuntu/.wp-cli/packages/vendor/10up/mu-migration/includes/helpers.php on line 176
Notice: Trying to get property 'domain' of non-object in /home/ubuntu/.wp-cli/packages/vendor/10up/mu-migration/includes/helpers.php on line 176
[316] Updating posts authors  100% [============================================================================================================================] 0:27 / 0:26Flushing rewrite rules...
Removing temporary files....
Success: All done, your new site is available at http://my-website.com/program1. Remember to flush the cache (memcache, redis etc).

Please note the two PHP Notices, not sure if this affected the import or not. Also, I specified the blog_id in the command run, but there was no existing blog with that ID; not sure if this affected the process or not.

After the import, I can see that the content was correctly set up in the various wp_2_* tables, but it was not added to the wp_blogs table:

mysql> select * from wp_blogs;
+---------+---------+---------------------------+------------------+---------------------+---------------------+--------+----------+--------+------+---------+---------+
| blog_id | site_id | domain                    | path             | registered          | last_updated        | public | archived | mature | spam | deleted | lang_id |
+---------+---------+---------------------------+------------------+---------------------+---------------------+--------+----------+--------+------+---------+---------+
|       1 |       1 | my-website.com| /                | 2018-05-30 09:16:32 | 2018-11-09 01:14:08 |      1 |        0 |      0 |    0 |       0 |       0 |
|       3 |       1 | my-website.com | /program-master/ | 2018-05-30 09:53:06 | 2018-05-30 19:53:15 |      1 |        0 |      0 |    0 |       0 |       0 |
|       4 |       1 | my-website.com | /some-site/           | 2018-06-26 14:37:39 | 2018-11-15 22:52:49 |      1 |        0 |      0 |    0 |       0 |       0 |
|       5 |       1 | my-website.com | /some-other/         | 2018-10-01 09:33:50 | 2018-11-10 02:18:53 |      1 |        0 |      0 |    0 |       0 |       0 |
+---------+---------+---------------------------+------------------+---------------------+---------------------+--------+----------+--------+------+---------+---------+
4 rows in set (0.00 sec)

Additionally, checking the wp_2_options table shows that none of the existing URL strings were rewritten during the import.

|         1 | siteurl | http://dev-site-url.org/program1 | yes |
|         2 | home  | http://dev-site-url.org/program1 | yes |

Is there a step that I'm missing? Does exporting from a Multisite install, and then importing into another Multisite install with this tool work correctly?

Or is it simply the case that if the blog_id option is used, but an existing site does not exist, it will not properly import? If this is so, then it would be useful to halt execution instead of creating all of the tables that will not properly function.

Properly map Content Audit plugin Owner field [enhancement]

The Content Audit plugin stores a metadata field per post indicating the "owner" of the content. The current user mapping functionality could be easily extended, I think -- and this might even be an opportunity to make that functionality more flexible and/or broader, to include other cases where the user id is stored by a plugin. If the maintainer is open to this enhancement I will be happy to work on a pull request.

Export sub-sites to ZIP files

Is your enhancement related to a problem? Please describe.
This request came in via Twitter in terms of how to further improve MU Migration.

Describe the solution you'd like

The one thing I would love to see would help bypass my script would be the ability to export all of the sub sites into their own .zip file.

Designs

n/a

Describe alternatives you've considered

n/a

Additional context

n/a

Remove {$taxonomy}_children from options tables after importing DB

n00b issue: Unable to create archive

Running into an issue trying to create my first archive.

On Ubuntu 18.04.4 LTS with php 7.2, when I run:

wp mu-migration export all single-site.zip --themes --plugins --uploads --verbose

I get

Exporting site meta data...
Exporting users...
Success: 2 users have been exported
Exporting tables
Success: The export is now complete
Zipping files....
Warning: Unable to create archive

Could be something on my end, so I was hoping there would be a way to get better debug information. I would expect it to create the archive next.

Sorry if this question has been answered previously, but I've only found one similar reference and that user was on Windows.

Error during import: db tables created but no site/files/plugin/theme

This is a pretty cool tool, and even with the error I ran into saved me tons of time, thanks!

I ran the following on my single site:

$ wp mu-migration export all site.zip --plugins --themes --uploads

Then moved the zip over to my new server where the multisite is set up and ran this:

$ wp mu-migration import all site.zip

It spit out a bunch of MySQL errors:

crop@themeofthecrop-ubuntu-2gb-nyc3-01:/var/www/demo.themeofthecrop.com/htdocs$ wp mu-migration import all ~/plateup-site.zip 
Extracting zip package...
WordPress database error Table 'demo_themeofthecrop_com.wp_3_options' doesn't exist for query SELECT option_value FROM wp_3_options WHERE option_name = 'wp_3_user_roles' LIMIT 1 made by include('phar:///usr/local/bin/wp/php/boot-phar.php'), include('phar:///usr/local/bin/wp/php/wp-cli.php'), WP_CLI\Runner->start, WP_CLI\Runner->_run_command, WP_CLI\Runner->run_command, WP_CLI\Dispatcher\Subcommand->invoke, call_user_func, WP_CLI\Dispatcher\CommandFactory::WP_CLI\Dispatcher\{closure}, call_user_func, TenUp\MU_Migration\Commands\ImportCommand->all, TenUp\MU_Migration\Commands\ImportCommand->create_new_site, switch_to_blog, WP_Roles->reinit, get_option
WordPress database error Table 'demo_themeofthecrop_com.wp_3_options' doesn't exist for query SELECT option_value FROM wp_3_options WHERE option_name = 'blog_charset' LIMIT 1 made by include('phar:///usr/local/bin/wp/php/boot-phar.php'), include('phar:///usr/local/bin/wp/php/wp-cli.php'), WP_CLI\Runner->start, WP_CLI\Runner->_run_command, WP_CLI\Runner->run_command, WP_CLI\Dispatcher\Subcommand->invoke, call_user_func, WP_CLI\Dispatcher\CommandFactory::WP_CLI\Dispatcher\{closure}, call_user_func, TenUp\MU_Migration\Commands\ImportCommand->all, TenUp\MU_Migration\Commands\ImportCommand->create_new_site, sanitize_text_field, wp_check_invalid_utf8, get_option
WordPress database error Table 'demo_themeofthecrop_com.wp_3_options' doesn't exist for query SELECT option_value FROM wp_3_options WHERE option_name = 'blogname' LIMIT 1 made by include('phar:///usr/local/bin/wp/php/boot-phar.php'), include('phar:///usr/local/bin/wp/php/wp-cli.php'), WP_CLI\Runner->start, WP_CLI\Runner->_run_command, WP_CLI\Runner->run_command, WP_CLI\Dispatcher\Subcommand->invoke, call_user_func, WP_CLI\Dispatcher\CommandFactory::WP_CLI\Dispatcher\{closure}, call_user_func, TenUp\MU_Migration\Commands\ImportCommand->all, TenUp\MU_Migration\Commands\ImportCommand->create_new_site, install_blog, get_blogaddress_by_id, get_blog_details, get_option
WordPress database error Table 'demo_themeofthecrop_com.wp_3_options' doesn't exist for query SELECT option_value FROM wp_3_options WHERE option_name = 'siteurl' LIMIT 1 made by include('phar:///usr/local/bin/wp/php/boot-phar.php'), include('phar:///usr/local/bin/wp/php/wp-cli.php'), WP_CLI\Runner->start, WP_CLI\Runner->_run_command, WP_CLI\Runner->run_command, WP_CLI\Dispatcher\Subcommand->invoke, call_user_func, WP_CLI\Dispatcher\CommandFactory::WP_CLI\Dispatcher\{closure}, call_user_func, TenUp\MU_Migration\Commands\ImportCommand->all, TenUp\MU_Migration\Commands\ImportCommand->create_new_site, install_blog, get_blogaddress_by_id, get_blog_details, get_option
WordPress database error Table 'demo_themeofthecrop_com.wp_3_options' doesn't exist for query SELECT option_value FROM wp_3_options WHERE option_name = 'post_count' LIMIT 1 made by include('phar:///usr/local/bin/wp/php/boot-phar.php'), include('phar:///usr/local/bin/wp/php/wp-cli.php'), WP_CLI\Runner->start, WP_CLI\Runner->_run_command, WP_CLI\Runner->run_command, WP_CLI\Dispatcher\Subcommand->invoke, call_user_func, WP_CLI\Dispatcher\CommandFactory::WP_CLI\Dispatcher\{closure}, call_user_func, TenUp\MU_Migration\Commands\ImportCommand->all, TenUp\MU_Migration\Commands\ImportCommand->create_new_site, install_blog, get_blogaddress_by_id, get_blog_details, get_option
WordPress database error Table 'demo_themeofthecrop_com.wp_3_options' doesn't exist for query SELECT option_value FROM wp_3_options WHERE option_name = 'home' LIMIT 1 made by include('phar:///usr/local/bin/wp/php/boot-phar.php'), include('phar:///usr/local/bin/wp/php/wp-cli.php'), WP_CLI\Runner->start, WP_CLI\Runner->_run_command, WP_CLI\Runner->run_command, WP_CLI\Dispatcher\Subcommand->invoke, call_user_func, WP_CLI\Dispatcher\CommandFactory::WP_CLI\Dispatcher\{closure}, call_user_func, TenUp\MU_Migration\Commands\ImportCommand->all, TenUp\MU_Migration\Commands\ImportCommand->create_new_site, install_blog, get_blogaddress_by_id, get_blog_details, get_option
Importing Users...
Importing tables...
Updating post_author...
Error: Invalid input file
crop@themeofthecrop-ubuntu-2gb-nyc3-01:/var/www/demo.themeofthecrop.com/htdocs$ ls
index.html              wp-blog-header.php    wp-load.php
index.php               wp-comments-post.php  wp-login.php
license.txt             wp-config-sample.php  wp-mail.php
mu-migration1461340848  wp-content            wp-settings.php
readme.html             wp-cron.php           wp-signup.php
wp-activate.php         wp-includes           wp-trackback.php
wp-admin                wp-links-opml.php     xmlrpc.php

I may have made a mistake in that I didn't re-map the domain name when I ran the import command. When I realized, I popped into the wp_blogs table and updated the record there. The site then appeared in my list of sites, and from there it was fairly easy to run a wp search-replace command to update the URLs properly.

However, none of my plugins, themes or files transferred over. I was able to work it all out by moving files from the mu-migration146134970848 directory it created in my wp root.

But I'm wondering if you have any idea what went wrong. I have two more sites to do in the coming weeks so would love to iron out any quirks with my setup if needed.

Thanks, this is a huge time saver for me!

Update the "Garbage Collector" to work on WordPress 4.7

See why here: 10up/ElasticPress#654

https://github.com/10up/MU-Migration/blob/master/includes/commands/class-mu-migration-base.php#L88

Active plugins after importing

When exporting a subsite and importing somewhere else, network activated plugins don't get activated. We need some post-import routine to activate these plugins.

Users import from Multisite into a single Site

Hi,

I have noticed if I try to import from a subsite within a multi-site network into a single site the users that are setup network wide are messed up. They do not get any roles and they are unable to login using the login credentials they have at the source. So I have to update the user role.

Add filter and optional parameter to specify additional fields where users ids needs to be updated.

After import, MU-Migration replaces the old user id with the new user id on post_author and _customer_user (if WooCommerce is enabled) fields. Some themes/plugins might also store user's IDs on some non-default places and therefore they also needs to be updated on import.

Plugins Status Import

Hi,

Currently when restoring from Zip a message appears that "plugins is activating" But all the plugins are deactivated upon import the approach is safe to keep all plugins inactive. But ideal case would be that the zip should also save the status of the plugins on the source at the time of export and Activate them upon import to the destination. The plugins that are activated on source should also be activated on destination. The plugins that are inactivate on source should remain inactive.

Error establishing a database connection

Just trying this tool for the first time. I have successfully exported my multi-site Wordpress to a zip file. I have copied the zip file to a (completely) new Wordpress installation. I run the command

wp mu-migration import all site.zip --new_url=dev.xxxxxxxx.com/wordpress --path=/var/public/sites/wordpress

and get the message
Error establishing a database connection

Any ideas how I can investigate the issue? I have checked usernames etc using phpMyAdmin

Test against WordPress 5.9

Is your enhancement related to a problem? Please describe.
Once WordPress 5.9 is released, we'll want to test MU Migration to see if any incompatibility issues arise.

Describe the solution you'd like

• test MU Migration on WordPress 5.9
• open issues for any incompatibilities noted in testing
• resolve issues identified in testing
• bump "tested up to" version
• if code changes needed due to incompatibilities, ship a release

Designs
n/a

Describe alternatives you've considered
none

Additional context
none

`check_for_sed_presence()` false negative on OS X

check_for_sed_presence() calls sed --version to test if sed is installed on the system. That works for GNU sed in most Linux distributions, but OS X ships with FreeBSD's version, which doesn't support the --version argument.

> wp mu-migration import tables example.sql --blog_id=3 --old_prefix=wp_ --new_prefix=wp_3_ --old_url=example.net --new_url=example.localhost
Error: sed not present, please install sed

> which sed
/usr/bin/sed

> sed --version
sed: illegal option -- -
usage: sed script [-Ealn] [-i extension] [file ...]
       sed [-Ealn] [-i extension] [-e script] ... [-f script_file] ... [file ...]

export current theme(s) only

Had a scenario with hundreds of themes installed in a big multisite installation.

export all exports all themes of the network wich ends in a 6 GB Zip-File for a single site.

Travis builds exploding

This is an issue identified in both pull requests #50 and #53. I've tracked the failure down to the fact that wp-cli removed most of the command requirements from composer.json in versions greater than 1.5.1. Therefore, simply requiring wp-cli/wp-cli results in only the commands cli and help being available.

Possible solutions:

1. Stick with v1.5.1
2. Manually require all needed wp commands, e.g. in .travis.yml:

install:
  - composer require wp-cli/wp-cli:dev-master
  - composer require wp-cli/core-command:dev-master
  - composer require wp-cli/config-command:dev-master
  - composer update
  - composer install
  - bash bin/install-package-tests.sh

3. Use a different method of installing wp-cli, like curling the .phar file.

Installation fails?

Hi! I had no trouble installing wp-cli and mu-migration on the target server, or of doing a test zip of one of the dummy subsites on the target server, but now that I'm trying to install it on the source server, I'm having problems. When I enter wp package install 10up/mu-migration, I get this error:

Error: The "https://wp-cli.org/package-index/packages.json" file could not be downloaded: SSL operation failed with code 1. OpenSSL Error messages: error:1407742E:SSL routines: SSL23_GET_SERVER_HELLO:tlsv1 alert protocol version
Failed to enable crypto
Failed to open stream: operation failed

From Googling, I see this is not an issue exclusive to mu-migration, but I also don't know how to solve it.

Any ideas? Thanks in advance - I'm very excited to use this extension!

Windows 10 + Local by Flywheel - Can't locate the .zip

Hi!

I've managed to install MU-migration without problems on my win10 + local by flywheel setup.

The export works fine, tells me a .zip has been generated. However, I can't find it, anywhere.

Been using different types of windows search applications, included hidden folders/files etc.

Any ideas?