Moving a weblog to a WP3 Multisite Weblog System (on MediaTemple)

At one point or another you will start thinking to move several older weblogs or even some domains you have to one weblog system. This has the advantage that you only need to administrate 1 WP installation (and the disadvantage that if one system fails they all fail).

I moved 20 smaller sites to one central weblog system. Those were pretty simple:


For Simple Sites

Simple sites are sites that have a low amount of content, no content outside the regular WordPress directories and no cronjobs or interfaces running that pumps data specific in the website’s database.

on your old blog (myoldblog.com):

  • Make a safety backup of the old site like you are already doing (…)
  • Make a note of all settings from the diverse plugins and widgets and other settings in “mysettings.txt”
  • Delete all Spam Comments
  • Delete all Other Stuff you do not want to transport such as e.g. revisions (see plugins / http://wordpress.stackexchange.com)
  • Use the regular Tools > Export to make an export of <myoldblog.com>

on the WP3 Multisite (my_multisite.com):

  • Install the WordPress MU Domain Mapping plugin.  This plugin makes it possible that the <some_blog.my_multisite.com> is now/still <myoldblog.com>, download it here: http://wordpress.org/extend/plugins/wordpress-mu-domain-mapping/  The instructions are excellent and the exceptions are discussed on http://wordpress.stackexchange.com so you will manage to do this. (read here: http://ottopress.com/2010/wordpress-3-0-multisite-domain-mapping-tutorial/ for a large walkthrough).
  • Install all plugins that you have installed on your old blog
  • Install all themes that you had installed on your old blog
  • Install the WordPress importer: http://wordpress.org/extend/plugins/wordpress-importer/
  • Now create a NEW site and make a note of the ID of that new website
  • Go to the Admin back-end of that new site
  • Use the WP MU Domain Tools (under Tools) to tie that site ID to <myoldblog.com> and set it as primary
  • In your webroot (via the shell) rename the old weblog directory under /domains/ (for MediaTemple)
  • run “ln –s my_multisite.com myoldblog.com” (for MediaTemple) to make a link to the new location instead of a physical directory (under /domains/)
  • Use the WordPress Import under Tools > Import
  • Activate plugins needed
  • Choose Theme
  • And re-apply manually the settings you wrote down in “mysettings.txt” :)

For Larger Sites

on your old blog (myoldblog.com):

  • Make a safety backup of the old site like you are already doing (…)
  • Make a note of all settings from the diverse plugins and widgets and other settings in “mysettings.txt”
  • Delete all Spam Comments
  • Delete all Other Stuff you do not want to transport such as e.g. revisions (see plugins / http://wordpress.stackexchange.com)
  • Export the database in SQL format and possibly already skip some tables left over from plugins (those that you wanted to delete for a long time)

The following diagram shows you what tables you minimally need (so 11 tables) and possibly even only 10 if you skip the options table and re-enter settings by hand to start clean all over.

image

I actually made 11 separate SQL exports to do some editing by hand and some editing and cleaning in my local database before exporting a new SQL file to be really exported (this is a nice chance to correct all kinds of things grin).

General things to do are:

  • change the TABLE NAME in the SQL Files to the table name in your WordPress Multisite Installation e.g. change wp_posts to wp_21_posts if the new site you created has ID=21 (and check that the prefix of the tables is the same)
  • change all references to hard coded paths to the new location e.g. if your old image files were in the “root” so /images (as were mine in this case) move those images to <my_multisite.com/html/wp-content/blogs.dir/50/wp-content/uploads/images> because in the multisite environment each blog has its own file directory.
  • your users and metadata are kept centrally so the ID’s assigned to posts versus users SHOULD align, in the worst case do a renumbering in the SQL files. (if you have only 1 user it is simple but if user 73 is owner of blogpost 6 and 9 etc… it’s more complex).
wp_posts

This was my biggest file, in the first example 20 Mb (13.487 sql lines), things todo:

  • search replace `wp_posts` with `wp_21_posts` (448 replacements) (with all the inserts)
  • `post_category` int(4) NOT NULL default ’0′, is no longer used so you can delete that one from the local SQL import of the table (easiest)
  • as said image location moved to e.g. /wp-content/uploads/2010/12/whatever.jpg so i give some examples of what I did, not all applicable to you, i now wanted to make all links relative to, handy:
  1. /wp-content/uploads/2010/10/whatever.gif” should be “/wp-content/uploads/2010/10/whatever.gif” = search and replace in sql file (in my case 3058 replacements) so SEARCH AND REPLACE “/wp-content/uploads/” with “/files”.
  2. and now the followup “http://myoldblog/wp-content/uploads/ –> “/wp-content/uploads/ (1260 replacements)
  3. “/images  –> “/wp-content/uploads/images (245 replacements), interesting because I might later on move those to another place to attach them to posts.
  4. “http://myoldblog/images/ –> “/wp-content/uploads/images/  (except for one post where I had this as example in code…) (2266 replacements)
  5. The Remote Image Caching plugin gave me a list 5 pages of images that are no longer working such as a gigya counter, xara online generated fonts, images and promotions from sites that no longer exist and so on, so it was easy to find them in the text file and replace them
  6. I had to replace stuff from /books, /videos, /kmz, /mp3, etc…

I also wanted to paste a “no follow” on every href in the  file AND dump all URL’s and run them through a 404 check… but I decided I would do that later. (and must remember to dump the core control http logs from the posts table

wp_postmeta
  • search replace `wp_postmeta` with `wp_21_postmeta` (50 replacements)

2 MB and 18287 lines of SQL

A lot of stuff in there that can be deleted, rest-overs from plugins. Weird stuff like “(11473, 5242, ‘_oembed_c81bdda6667ab7746c008cfb35c8df32′, ‘{{unknown}}’),” ??
but…also custom fields with the old link, and although we should all rely on the “featured image” … handy to keep for the old stuff:

  • replace http://myoldblog/wp-content/uploads/ (8432 replacements)
  • replace http://edward.de.leau.net/images (764 replacements)

I also noticed some other weirder files that I had to keep

wp_options I’m not going to transfer this file. Saves me cleaning this up from old plugin data. However, its handy to keep around when setting the new values.
wp_comments
  • search replace `wp_comments` with `wp_21_comments`

On database level I need to keep here the field “comment_subscribe” because it probably contains the info which users subscribed via the comment subscribe plugin

It only reminded me to blacklist AND whitelist some IP’s

wp_commentmeta
  • search replace `wp_commentmeta` with `wp_21_commentmeta`

A LOT of Akismet history, I don’t know if I can delete this, lets keep it there.

wp_term_relationships all relations so only replaced the table names
wp_term_taxonomy idem
wp_terms idem , but it reminds me to remove or repair those bad tags. Cant do it now since the same terms might exist
wp_usermeta in WP3/Multisite there is a central user table, so I fiddle it in manually and not by importing (I assigned about everything to user number “1″ in the SQL Files)
wp_users in WP3/Multisite there is a central user table, so I fiddle it in manually and not by importing
wp_links idem
  • You can now run the SQL scripts for importing. The statement “if not exist drop table” should be in there: we want to replace the existing tables, so in my case:

- wp_posts : since this SQL file is 20 Mb (or larger)… do not try to copy and past it in e.g. phpmyadmin.. instead run the “IMPORT” option in phpmyadmin, if that does not work, you can upload the file to your server and run it from the commandline there or… if you have EXTERNAL access, just run this batchfile:

c:tempxampmysqlbinmysql.exe –h YourHost –u UserName -pPassWord yourdatabase < wp_posts.sql
c:tempxampmysqlbinmysql.exe –h YourHost –u UserName -pPassWord yourdatabase < wp_postmeta.sql 
c:tempxampmysqlbinmysql.exe –h YourHost –u UserName -pPassWord yourdatabase < wp_comments.sql 
c:tempxampmysqlbinmysql.exe –h YourHost –u UserName -pPassWord yourdatabase < wp_commentmeta.sql
c:tempxampmysqlbinmysql.exe –h YourHost –u UserName -pPassWord yourdatabase < wp_term_relationships.sql 
c:tempxampmysqlbinmysql.exe –h YourHost –u UserName -pPassWord yourdatabase < wp_term_taxonomy.sql 
c:tempxampmysqlbinmysql.exe –h YourHost –u UserName -pPassWord yourdatabase < wp_terms.sql 

(ofcourse that requires that you have MySQL installed locally, e.g. with Xampp)
(and notice there is no space between “p” and the actual Password)

If you have additional tables e.g. containing plugin data ofcourse you need to add those too.

If you got errors, correct them, probably you forgot to rename some table entries in the new format

  • Now go the the new Multisite imported site (wp-admin) and just check if everything imported ok, you do not need to switch … yet.
  • Put your old site in maintenance modus
  • NOW move (or better copy) over ALL images, videos, etc… physically from the old weblog directory to the new “files” directory
  • Possibly activate themes or plugins ONLY for your site not “network enable”
  • Enter your old settings for plugins / Akismet key etc…
  • Use the WP MU Domain Tools (under Tools) to tie that site ID to <myoldblog.com> and set it as primary
  • In your webroot (via the shell) rename the old weblog directory under /domains/ (for MediaTemple)
  • run “ln –s my_multisite.com myoldblog.com” (for MediaTemple) to make a link to the new location instead of a physical directory (under /domains/)

And you are done!

One thought on “Moving a weblog to a WP3 Multisite Weblog System (on MediaTemple)

Leave a Reply