Moving from WordPress to Perch
When I first started writing this blog, the software was a custom Classic ASP solution that I put together running off an Access database. I believe the next incarnation of the site was running on Movable Type, and at some point I imported it all into WordPress. On WordPress it has remained until last week when I finally took the plunge and imported 10 years worth of blogposts into our Perch Blog App and started running it on our own software.
When we launched Perch we had no intention of developing a fully featured blog add-on. The original Blog App was a simple news app, mostly aimed at the sort of company website that just wants a way to post latest news. However, our Perchers really did want a proper blog for Perch. So the Perch 2 version of Blog has comments, and all of the functionality you might need for a blog. Almost as soon as we launched Perch 2 and the new Blog App we started to get requests for a WordPress importer. Using the export from my blog (a ten year old blog makes a pretty good test case) we set about creating one.
By this point my site was a hybrid of WordPress and Perch. I had taken the pages detailing my Presentations and Writing out of the cumbersome WordPress Pages feature a while ago and installed Perch to manage those. To move my blog I wanted to be sure I could import all of the posts and comments and preserve my rewritten URLs to remain as they were with WordPress. I think these things are pretty much what anyone would expect when moving from one piece of software to another.
I took a local copy of the site and database and installed the Perch Blog App. Importing the posts was easy due to the brilliant job Drew did on creating an importer. To import posts and comments you simply need to export the posts in WordPress, drop the text file into the import_data folder in the Blog App and run the importer from within the Perch Admin.
Installing the Blog App installs the admin side of Blog. So the WordPress posts were still showing on the front-end of my site. Perch has no concept of “themes” and doesn’t take over your entire site. To actually display Perch blog posts you need to create three PHP pages. One displays latest posts, one displays an individual post filtered on the post slug passed on the QueryString, and if you want to create archives you might want a third page that shows the correct data for the archive you are requesting – filtering on category for example.
In the Perch Blog App download zip you get a folder of example pages that can be used to create your blog pages, and in fact I used these, just removing the Perch default mark-up around the area where I wanted my listing and posts to display and adding my own.
My old blog posts lived in /archives and the homepage of my site was a full listing. I actually wanted to remove a big list of posts from my homepage and just display a single, latest post there. So I dropped the example pages into a folder named /archives – I then commented out in my .htaccess file the WordPress rules so that the WordPress posts did not display. If you want your posts to display on your homepage then you would simply add the tag
<?php perch_blog_recent_posts(10); ?> directly to the homepage.
As with everything in Perch the mark-up around my posts, listings and anything else displayed is completely up to me. Unlike WordPress you won’t find markup mixed in with PHP tags. So I edited some of the default HTML templates to produce the mark-up that matched my existing CSS – trying to make things easy for myself as I was doing all of this three hours before leaving for Future of Web Apps in London.
My posts now all displayed but the URL used a QueryString with a parameter of the post, category or tag slug. I wanted to make sure that the new URLs were identical to my old WordPress URLs. I achieved this with mod_rewrite rules in my .htaccess file as described in the Perch documentation. In order to make sure that my paging generated the correct URLs I used the new rewrite attribute added to Perch 2.0.7. The requirement for this rewrite attribute was the only factor missing from my initial test of the conversion and so we added it to the development build of Perch and pushed that out today as functionality for everyone.
I was now able to remove WordPress from my site and deploy the Perch version. As far as I can see so far everything converted smoothly. Part of the reason for doing this was that by “eating my own dogfood” I would be able to spot problems other users might have. When I’m posting to my blog I’m just another user of Perch. For that reason, I was determined that if I used Perch it would be stock Perch – hence when I came across the issue with rewriting paging we needed a solution we could ship.
I’m hoping that our efforts in making Perch super efficient for high traffic sites will prevent the endless problems I have had with WordPress under load. This blog is a great test of that scalability and anything I do discover will make it back into the product. I’m also very excited about how easy using Perch makes adding new information to posts and being able to integrate posts with the rest of the site, rather than standing alone.