WordPress - We LOVE It!
I absolutely love the WPMU type setup on my web servers. It allows me to quickly whip up a new website and test out things without a lot of installing and tweaking and all the other boring routine things that have to be done with a new WordPress install. Just pop in and a “New Site” later, I’m checking out wordpress themes, wordpress plugins that will be effective for that client and with a minimum of fuss. Besides, my dev people can do the same thing without having to get into httpd.conf files or mess with the .htaccess files.
That all said, what happens when one wants to move everything over to a production site? Well, in some cases, I’ve used domain mapping to just map stuff into the current locations. And under certain circumstances, that can work well. I think I’ve passed that though as I’ve gotten into slightly more complex setups on my webservers.
So the challenge? Moving a subsite out of WPMU into it’s own domain and location on a new server.
I could have done the “Export WP site” route and then reimported it, but that seems to leave all my plugin data loused up and in need of reconfiguring – not to mention reinstalling plugins to begin with. Little tweaks that have been made to misc files. Was not looking forward to that, particularly as we are churning out some serious sites these days – HAS to be a smooth way to do it.
BackupBuddy from the fine folks at iThemes seemed to be a step in the right direction. Be aware that while it can NOT separate a child site from the parent, it seemed as though it would be a good start. It can, without too much trouble, move a whole WPMU and allow you to reinstall the same elsewhere. But what I wanted to do was separate the child site from parent.
I started by backing up the entire site via Backup Buddy and then moving it to the new webserver. Slid it into place after making the proper configs in the httpd.conf file. Backup Buddy says to not even install WordPress but to let the Backup Buddy script do it for you. Basically you just move the backup and an import script to the new location, run the import script and you should be up and running. It has a nice step through process to allow some mods during the reinstall, but you are not able to make a whole lot of changes.
In my case, where it is NOT compatible with WPMU surfaced immediately – it went to the right domain but then started pulling content from the old dyndns development environment – NOT what we wanted. And all links still pointed to the dyndns addy. Ugh. So, made a change to the wp_config.php file. And that was just the start. My child site was actually id 4, so I removed all files associated with any other child site, all unused themes, dropped all tables that were anything other than root and child site 4. That was a good start.
I strongly urge you to have your phpMyAdmin setup working nicely before you begin this operation. Because there are a number of ways of setting up the WPMU environment with a bunch of different locations that addresses and pointers are stored, without a complete and total understanding of the WHOLE app, I decided to modify all table data that contained, “myoldsite.dyndns.org” locations in it. They were found in the following tables (and I think I gave up writing them all down after a while – so there may yet be more):
- wp_blogs
- wp_site
- wp_usermeta
- wp_4_posts
- wp_4_options
- wp_4_postmeta
I actually exported the data from phpMyAdmin and worked on it locally in UltraEdit text editor. Deleted the tables in the original db and then imported the modified files. Do the export/import in the suggested SQL format and all tables will be recreated as expected when the import process is done. My mindset was to modify everything possible to repoint to the child site 4 and use the new mapped domain name. There was a bit of residual tweaking required after all this to repoint some directories to the right locations in the data fields as the actual paths to files HAD changed in the new setup.
AND you will likely need to change your MD5 password encryptions in the user table. For some reason that does not survive the transfer. I just went into an online MD5 hasher with my password and then got the hash and reentered it into the users table. After that I was able to login as the admin.
So, did it work? Yes, it did. It was a pain in the *ss to do though. I would say if you don’t have root access (I use RDP connections as my server is Windows based – odd yes, but for my needs it works well), that it would be a REAL pain to pull off though there is probably a true Linux person out there that would find this all child’s play. As it was, I blew about 8 hours trying several different ways to do this thinking that there MUST be a repeatable way to do this and I really did NOT find a way to do this in a clear or concise manner – which is probably why BackuBuddy CAN’T do this. I methodically made one change to one location, then tested – with less than favorable results. Made another change, tested, etc to find that pattern, but finally I just did mass find/replace operations and it did work at the end of it.
How can I improve the WordPress port process for my own needs? First and foremost, probably REALLY dig into the tables and the function code to UNDERSTAND exactly what each table is holding and how the deeper functions interact. This is probably beyond the average user, but would just take some time if you’re one of those uber-geeks like me. I probably changed some tables that were NOT needed. Thinking about it this morning, there may actually be a way to point the base site at child 4 (in this case) without a whole lot of tweaking or affecting the rest of the site – that is a path that must be explored.
I’m sure I’ll do battle with WPMU again and will be posting on it again.
Anyone have any experiences that they want to share or advice, helpful tips?
Follow
