11

I'm looking for the best and most secure way to develop locally a numbers of subsite using multisite and moving them to the production environment when they are ready.

I've already migrated the full multisite install with the first subsite which is now live. I would prefer to develop the other sites on the local server so I leave the production server alone but obviously I can't do a full migration again.

I looked for a solution but everything I found is about moving a single site to a multisite or the other way around, no "move subsite from multisite to multisite".

I would like to keep everything: settings, widgets and so on.

  • 1
    I think commercial BackupBuddy plugin is able to do this, but I would be interested in seeing more generic answers to this. – Rarst Jan 31 '14 at 16:50
  • Due to the serialised strings in the database it is not that easy to do it. I haven't seen a plugin for a pure migration so far, but that absolutely something that should be done. The only was of moving "most" parts of one blog to another is through the XML export/import mechanism, but you still have to fix a lot of paths afterwards. – 2ndkauboy Jan 31 '14 at 17:14
  • 1
    The best option you have is to do that with a direct sql query . I have done it more than once, and it works just fine if you are careful enough . – krembo99 Feb 3 '14 at 10:10
  • @krembo99, could you explain a little more your tecnique? – molokom Feb 3 '14 at 10:18
  • @Rarst, as far as BackupBuddy is concerned this is from their FAQ: "No. BackupBuddy Multisite support is experimental. It is not recommended for production sites and is not officially supported." – molokom Feb 3 '14 at 10:42
3
+25

This can be somewhat tedious, but hopefully this helps. The less that changes from one environment to the next, the less painful this process will be. Particularly, if the domain, site id, file paths remain the same, the less painful this process will be.

This post assumes some knowledge of database management. It is not a complete step by step because you should search the forums and possibly create a thread specific to whichever step you are having trouble with, e.g., if you need help with exporting a database table.

The most important thing to do is backup your entire database and files for both the local dev site and the new location in case something goes wrong. Expect something to go wrong. Be pleasantly surprised if it doesn't.

Moving your theme files should be pretty straightforward. Upload your theme files to the wp-content/themes directory and activate it as usual. I'm assuming this is a shared theme that all blogs have access to.

Upload plugin files to wp-content/plugins at the new location. Don't activate them yet.

Note that any content exclusive to the blog you are migrating will be located in a directory that looks like wp-content/blogs.dir/2/files where 2 is the site id. If it is possible to maintain this site ID at the new location, it should help to minimize conflicts in the database after migrating to the new location. Otherwise, you will have to update your database to reflect the new path.

You will need to export the multisite tables related to the blog you are trying to migrate and import them to the new location. You will have to edit the tables which store data related to the blog you are migrating. Make sure that the prefix of these tables is the same at the new location.

For example, the wp_blogs table for your blog contains the blog id, site id, domain and path that allows WordPress multisite to recognize and work with your blog. Edit any of these that are no longer correct to reflect the new location, but please read the rest of this post before attempting to do so.

See Multisite Table Overview

To migrate your WordPress and plugin settings for the blog to be transfered, you will need to deactivate all plugins locally, then export your site specific tables (codex reference), including those for your plugins. Import these tables to the new location's database.

Make sure the new location uses the same database prefix as the tables you are importing. The prefix will contain the site id for your blog and look something like wp_2_options, wp_2_posts, wp_2_postmeta.
See Exploring WordPress Multisite by Lisa Sabin-Wilson

I'm assuming you know how to import/export via phpmyAdmin or with the mysqldump command in your terminal. That's a bit beyond the scope of this post, but here is an export example that should help.

From How do you mysqldump specific table(s)? (Syntax edited slightly to be more clear.):

If you are dumping tables t1, t2, and t3 from database named mydb

mysqldump -u <username> -p <password> mydb t1 t2 t3 > mydb_tables.sql

Before activating plugins on the new site, go to your permalink settings in admin cp and save the settings to update the database files to the new site url. Activate your plugins and see if there are any issues.

One issue you may run into is with data serialization in your tables.

"[...]References to the old domain name or location will remain in the database, and that can cause issues with links or theme display.

If you do a search and replace on your entire database to change the URLs, you can cause issues with data serialization, due to the fact that some themes and widgets store values with the length of your URL marked." When Your Domain Name or URLs Change

Keep in mind that data serialization may cause a conflict in database tables relating to your plugins as well. Rather than performing a manual search and replace on the url stored in the database, use the database search and replace script recommended in the previous codex link. If there are only a few instances of serialization in the database, you can just edit them manually via phpMyAdmin or whatever your preference is for managing your database.

One more issue that you may encounter is that any incorrect file paths stored in database tables will need to be updated to reflect the new location. This could be the case for media directories or directories used by plugins depending on how the plugin was designed. Again, you will want to use the search and replace script to ensure there are no serialization conflicts while updating the file paths. Alternatively, you can go through your tables and update them manually.

  • Thanks! So it seems there is no actual benefit on working this way: it's a bag of hurt. It would be better develop local single site and migrate into the multisite environment? – molokom Feb 10 '14 at 9:21
  • You may run into a lot of the same problems, but it should require less tables that you need to migrate. Just to give you an idea, here's a decent guide for that called Move an Existing Blog into WordPress Multi-Site. I'll leave it to you to determine which is more efficient for you as a developer. – iyrin Feb 10 '14 at 12:55
0

Couldn't you use the built in Export and Import features of WordPress? Then it's just a matter of moving the theme from one install to the next via FTP. It goes fairly quickly and you can migrate a site between installs in less than 5 minutes.

You can sync user credentials using a nifty plugin called User Syncronization.

I haven't used it, but ManageWP has a user friendly deploy and clone tool to go from an existing site to a new one...it's worth looking into.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.