UPDATE – April 9, 2012: The Boles Blogs Network is now back on WordPress.com! We will write another article explaining the why and how of moving back. We’re leaving this article online because it might benefit someone else seeking to export their WP.com blog to a standalone WordPress installation.
Welcome to my first new article since the Boles Blogs Network had to leave our hosting setup on WordPress.com because of a strange billing anomaly that threatened the viability of our publishing network core.
Here’s what happened…
Two years ago, when I moved my blogs from a self-hosted Movable Type installation over to WordPress.com, I had the expert help of Automattic employee Lloyd Dewolf (Budd) — who is no longer with the company — to get all my thousands of posts imported into WordPress.com blogs. As a blogs-warming gift, Lloyd waived the fee for domain mapping for the first year for all my imported blogs. We added a few other blogs during that first year, and I paid the domain mapping fees.
A year passed.
I paid for another year of domain mapping upgrades for all 14 blogs.
Another year passed.
I am now unable to renew, and pay for, my domain mapping upgrades as you can see in the screenshot below. There was a major “Upgrade” to the way WordPress.com now handles their shopping cart that somehow broke my ability to pay my way on the service. Notice there’s no “Renew Now” button for me to click for BolesBlues.com? The domain mapping says it was purchased by “wpcomvip” and not me and that’s a problem.
Easy solution, right? Contact WordPress.com support, tell them about the wrong billing association for my domains, pay for everything in one click, and live another year.
Not so fast.
On March 26, 2012, I contacted WordPress.com support via their online webpage. I received an automated email reply. I did not receive a support ticket number or a human reply. I waited a few days or so — I usually hear back from WP.com support within hours, if not minutes — but no reply was provided. I contacted support again. Same result. Automated email. No human response. I’m still waiting…
I began to panic a bit. I’ not a last minute sort of person, so even though my domain mapping would not expire for another month, I didn’t want to wait around not hearing anything and dreading bad news.
I decided if Automattic did not want my “No Ads” and “Domain Mapping” upgrade money for 14 public blogs, then I needed to find an alternate hosting solution because, without domain mapping, all my blogs would break. I had to think of Plans A, B, and C because my schedule is packed with teaching and consulting assignments right now and it would likely take me a couple of weeks to export and setup all the blogs elsewhere.
I also remembered when I first wanted to move to WordPress.com, Lloyd suggested that WordPress.org — the standalone software platform — would soon be offering an easier-to-use “multisite” setup that had only previously been found in “WordPress Multi-User.” Multisite would basically allow me to run my own “WordPress.com” on my own server using multiple blogs in a single installation using one database.
I started to do some research to figure out if WordPress multisite would be an option or not. I looked at my current Pair VPS server and, even though I’m on a virtually “shared server,” I did have some disk space and database overhead available to host the blogs network.
For the multisite migration from WordPress.com to Pair VPS, I decided to make 10.txt the base blog. It was the least busy of the 14 network blogs and I could play around with that content and URL without losing a lot of readers during the transition.
I purchased an IP address for 10txt.com on Pair and I set up the domain in my account center. I installed WordPress in the base public_html directory because multisite cannot be operated from a subfolder in the main domain.
I contacted Pair support to tell them my plan and to make sure my VPS could handle the load and to find out if there were any special pairNIC or Pair-specific issues I needed to be aware of for planning the move. I received some excellent advice about parking the blog domains in the Pair Account center and not on pairNIC, and I decided the subdomains for the blogs was better than using paths since Pair supports wildcard subdomains with my service level.
Next, I created a new database in my Pair account center. That was a simple and seamless experience.
I uploaded the latest version of WordPress, and the installation was quick and easy.
Then I added my users. Their Gravatars were pulled into my Pair VPS version of the blogs network without incident.
I had some permissions problems with WordPress. Pair support told me the issue was the way Pair configures their servers. They suggested I use cgiwrap to lock down my server and to identify my server username to WordPress as an “authorized” user. With some help from Pair and an SSH session, and after adding a few entries in my .htaccess file, I had cgiwrap running and my WordPress permissions problems were resolved.
I enabled the multisite network in WordPress and it was time to create my network blog subdomains. WordPress did not allow me to choose to use paths, so subdomains were the only way to go — and I’m glad that’s the way I wanted to go!
I used the same 2010 theme on Pair I used on WP.com. I set up my widgets and I installed some network plugins. I was getting up to speed and feeling the massive plan all coming together. I decided to press my time, not sleep, and to move forward at a much faster pace to make the move away from WordPress.com and get set up on Pair ASAP.
Next, it was time to export all my blogs content from WordPress.com and then import them to my Multisite setup. With the help of Tech Support at Pair, I was able to raise the default file upload limit in my Pair WordPress setup from 2MB to 25MB and that saved me hours and hours of import time.
The WordPress importer is much smarter in 2012 than it was in 2010 because 31 duplicate entries were found in the Urban Semiotic import and NOT imported. Since 2010, I had discovered over 20 duplicate posts that WERE imported on that same blog, and I had to remove those dupes from public view and place them in the trash. I’m surprised I missed 31 other duplicate posts! I also now have to fix all my YouTube calls in all my posts because now they only show the raw HTML and not the WP.com short codes.
I secret keyed and salted my WordPress setup, installed the Domain Mapping Plugin, and started moving all my domains from pointing at the WordPress.com servers and finding my Pair setup.
Akismet is active, but, for some reason, I cannot get to its setting pages. I’m getting a network error message that I don’t have “permission” to access that file. I’m using WP Super Cache and I love its seamless CDN setup for using Amazon CloudFront to help take the serving load off my VPS. The included “Recent Comments” widget has a curious behavior in that it shows comments from all the blogs in my multisite network and not just the one being visited. I removed that widget because of content confusion.
All my blog domains are now pointing to my WordPress installation on Pair and now I have to keep my eye on my files — .htaccess gets corrupted if you remove WP Super Cache because the automatic removal deletes your mod_rewrite settings, effectively killing all your blogs’ pretty URLs and replacing them with “Not Found” errors — and also watch my database, but so far, so good.
I’d love to know if the WordPress Jet Pack works properly on multisite installations or not. Google provides conflicting answers like “yes” and “no” and “we don’t know” and “we’re waiting to hear back from the Jet Pack developers on that there.”
It feels right to be back in the point-to-point publisher saddle again three years after giving up my original self-hosted WordPress installation that I started using to publish articles in 2005. Movable Type was a year-long self-hosted nightmare I never want to repeat, but being back with WordPress in standalone mode feels good and familiar as we continue to press our vision of the truth of the world into the future.