4 minutes, 3 seconds

I’ve recently achieved the life long dream of having one single WordPress instance for all my blogs and blogs I host. No more days of upgrading 15 different instances, but the forgetting that one rarely used instance and having that one instance get hacked. No more uploading the best new plugin to every which directory on the server. One install to rule them all!

However, as part of this, it meant exporting and importing a lot of content. I got pretty good at this as well as figuring out a lot of tricks along the way. Here’s some of my knowledge I gleaned that might help you if you’re faced with the same task!

Backups – Before starting down the path of any major code or data transfer, you should be sure you have backups of all your data. But, this isn’t a big deal for you, right? Right! That’s because you already back up all your blogs both on site and off. If you need help, check out WordPress Backups in the codex. Don’t forget, your backups are only as good as your restores. Be sure you test your backups to make sure they’re good!

Easy testing – Let’s say you have your WordPress network install for your fancy pants website at: http://wp.fancypants.com.  This means that, by default, to create a new site called “eatatjoes” you’ll need to:

• Create the new “Eat At Joes” WordPress instance in the network admin site
• Add a new ServerAlias in your apache vhost:

  ServerAlias eatatjoes.wp.fancypants.com

• Add a new DNS entry:

  eatatjoes.wp.fancypants.com. 60 IN CNAME wp.fancypants.com.

• And finally, don’t forget to restart apache:

  apachectl graceful

That’s a whole lot of work just for an instance that you’ll likely move to eatatjoes.com and do all the steps above again.  Instead, what I did was:

• Create a wildcard DNS entry for *.wp.fancypants.com.  For me this was easy to do in Namecheap, my registrar and DNS host.
• Create a wildcard server alias in your apache vhost:

  ServerAlias *.wp.fancypants.com

• And finally, again, don’t forget to restart apache:

  apachectl graceful

Now, any time you create a instance, say irockaroundtheclock, in the network admin <BAM!> it will just work at irockaroundtheclock.wp.fancypants.com.  No editing of apache files, no updating DNS and no forgetting to bounce apache.  When testing instances and needing to delete failed import attempts to start from scratch with a different sub-domain, this made things very easy. This does assume you’re using name based hosting.

Good Prep – I’ve found that this is the checklist for successfully importing of a blog:

• Using your new easy-to-test-a-new-instance set up from above, be sure you know how to create a new instance in the network admin interface.  You don’t want to cut your teeth learning how to create a site for the first time and then realize you’ve lost hours of work because you made a first timers mistake. Create and delete ’til you get it right!
• Inventory all your plugins and themes on your old sites and add them to you new network site. Watch out for incompatible plugins from old sites which might throw a wrench in the works.
• The first plugin you install in each new instance will need to be WP’s own Importer. While we’re on the topic, read up on the codex entry.
• Create all your users before hand.  This way when you’re creating a new site or importing it’s easy to assign the existing user to be the owner. I choose to uncheck the “Send this password to new user via email” and disseminate passwords via one time secret instead.
• You may also opt to communicate to your users that you’ll be doing some testing.  If you fat finger an import, it can email each of the authors that you just created an account for in the new instance.  See prior step as well!

Loss-less Data Imports – Having written a WordPress plugin or two, I know that plugins store their data in either the posts database table, along with your existing posts, or their own table created when the plugin was installed. If your importing data for a plugin that follows the “use the posts table” model, then you need to activate and configure this plugin before you import.  If you don’t, you’ll either lose the data for the plugin or it might be missing pieces or be corrupted. The bummer is if your plugin has its own tables outside of the posts table, it will then need to have its own export/import features.

Import Problems – If you’re having problems running the importer because it won’t finish because of errors, try turning on the debug output.  In the WordPress Importer plugin directory (WPHOME/wp-content/plugins/wordpress-importer) find the wordpress-importer.php file.  Edit this line:

/** Display verbose errors */
define( 'IMPORT_DEBUG', false);

To be true:

/** Display verbose errors */
define( 'IMPORT_DEBUG', true);

In my case the plugin complained that images imported didn’t match the size of the original:

Remote file is incorrect size

Imports failed :( When I ran strings on the imported image I saw this at the very end:

<!-- WP Super Cache is installed but broken. The constant WPCACHEHOME must be set in the file wp-config.php and point at the WP Super Cache plugin directory. -->

Going to the original, old site and disabling the Super Cache plugin fixed my import problems.  Yippee!