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.
MIT License
329
stars
47
forks
source link
Search-replace of uploads paths is innefective when importing from multi-site into single-site #73
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).
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.
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 replacewp-content/uploads/sites/$blog_id
forwp-content/uploads
.Steps to Reproduce
Export the website from a multi-site installation using exactly the following command line options:
Then import it into a single-site installation using exactly the following command line options:
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):Expected behavior
Uploads paths should have been replaced correctly throughout the database (and the logo should appear in our blog).
Environment information
Additional context
I did some investigation and I found that:
blog_id = 30
, the exported.json
file containsblog_id = 1
, and thus this line was never executed when importing.--blog_id
is not passed when exporting, this line is never executed and then the.json
file ends up withblog_id = 1
.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.--blog_id=30
to the command line when exporting, the issue described in this bug report does not manifest itself.