From WordPress to Jekyll/Octopress or Squarespace?

Justin Blanton -

Slowly, but surely, the migration is happening. To which platform, I’m not entirely sure just yet, and was hoping you might be able to help me make that decision.

As some of you might know from my Twitter comments the last few weeks, I’ve put a lot of time and energy into proving to myself that my 3000 posts can be migrated both to Squarespace and to a static, database-less site (in my case, Octopress). I’ve been able to migrate successfully to both of these, but both took a lot of work. (More below.)

The reasons for me wanting to make this move are legion. Currently, this site is hosted at Slicehost, where I have a VPS. This basically means that I have root access to a portion of a Linux machine that I share with a few other people, and have to maintain the entire web stack myself (e.g., Apache, MySQL, PHP, XCache, etc.), and other system-related stuff like SSH.

Frankly, I’m just tired of having to upgrade WordPress (and then make all of my little one-off modifications each time I upgrade), tired of having to manage memory on the web server, tired of having to think about whether something I do is going to break the site in some fatal way that I simply don’t have the time these days to fix. The list goes on and on and on. I just want to write.

One of the biggest concerns I have regarding transferring this site to another platform is maintaining the permalinks to the content I’ve worked so hard to create. This issue is two-fold for me: polymath.net links need to redirect to corresponding polymath.net links, and the permalink structure at the new place must be the same as the structure I’ve always used (i.e., /year/month/slug).

Regarding the first concern, moving from polymath.net to polymath.net last year wasn’t too bad, because I was able to handle the jb → hypertext redirect directly in Apache, but this time I might not have that ability (depending which route I take). It may be the case that I have to do some sort of registrar-level redirect, where the requested permalink would break, but the user would end up at the correct site, where he could maybe search for what he originally requested. Clearly that’s not ideal, but I might just have to bite the bullet at this point and give up my obsession with perpetual “backwards compatibility”.

Regarding the second concern, I’ve been able to take care of that through both potential hosting options; all permalinks will remain the same.

One last wrinkle is my photoblog, which is powered by a modified Pixelpost. I discuss this hurdle at the end of this post; I bet you don’t make it that far. 😉

Squarespace

Ideally, I think Squarespace is where I’d like to end up, because it would offer me the most peace of mind. I’d never have to worry about upgrading or maintaining anything. All I’d be in charge of is the design (which, as you guys know from reading my site, doesn’t change too often), and the words. That’s it.

Importing

For the past couple of years I’d create a throwaway account every few months and try to import my WordPress blog to Squarespace, and it always broke. Every time. (Not sure if that had to do with the volume of posts, or because I had a mix of post types.) The latest version of the importer doesn’t let you specify an export file to import—you have to point the importer to your WordPress site, where it uses WordPress’ xmlrpc.php to slurp down all of your content. This means you can’t cut your export file into smaller, date-delineated chunks, to better help you understand where and why the importer is choking. This, coupled with the fact that when the current importer fails, you might have no idea why, meant you were kind of screwed if the import broke for any reason.

After complaining about this on Twitter a couple of times, the CEO of Squarespace reached out to me directly to see if he could help. This blew me away. After some rather technical back-and-forths via email over the course of a few days, wherein I explained exactly how the importer should distinguish between regular posts and linked-list posts, and how each should get added to the Squarespace system, he emailed me and told me to give the importer another shot.

This time it worked like a charm. All ~3000 posts were sucked into Squarespace and I was rockin’ and rollin’. Incredible. Relatedly, I also explained to him, generally, how the DFLL plugin works (it’s similar to my homegrown linked-list solution, and is the most popular WP plugin for doing linked-list posts), and so the importer should now handle WP blogs that use it.

(No matter which system I end up using for this site, I’ll never forget the CEO reaching out to me, listening to my proposed solution, and having it implemented. I’ll be forever impressed by and appreciative of that level of support.)

Potential Issues

  • Squarespace 6 feels half-baked to me. The LayoutEngine is badass, but, at this point, kind of limited. There are only a few templates to choose from, and each can be modified only so much (and the modifications available for each template are different). It’s maddening. Yes, you can provide custom CSS, but it’s impossible to do without using Firebug (or similar) to dig around and figure out the selectors, and even then you still can’t control, for example, exactly what content gets shown in a sidebar. I’m fairly confident that their developer TDK will resolve most, if not all of these issues, but I don’t know for sure, and I’ve no idea when that’s going to be released.
  • There’s no publishing API just yet, which means I can’t use MarsEdit, the app I’ve used for the past ~five years to publish to this site.
  • I don’t think the iOS app lets you define a slug for a new post, and I don’t think it lets you create linked-list style posts.
  • You can’t type posts in HTML. Only Rich Text or Markdown.

Jekyll/Octopress

In the last year or so I’ve seen a lot of neck-beards make the move to Jekyll, and every time it’s caused me to pause and think about doing the same. Jekyll describes itself as follows:

[A] simple, blog aware, static site generator. It takes a template directory (representing the raw form of a website), runs it through Textile or Markdown and Liquid converters, and spits out a complete, static website suitable for serving with Apache or your favorite web server.

Octopress, which is built on top of Jekyll, describes itself as a “Blogging framework for hackers”, and as you might imagine, this appeals to me greatly.

One of the big draws of this system for me is that maintenance would be minimal and I could serve the files from damn near anywhere, including, for example, Github Pages (totally free) and Amazon S3 (super cheap); in other words, I wouldn’t even have to have a proper web host. Moreover, to publish a new post I simply create a new file, supply the relevant YAML Front Matter, write the post, save the file, and execute rake deploy and rake generate. Those commands cause Octopress to re-build (on my personal machine) the site’s pages and upload them to the server. Slick.

Another big draw for me is the templating system. Implementing your custom design is fairly straightforward once you’ve spent a little time snooping around the files that control the way your site looks, and you can do nearly all your modifications on “custom” template and CSS files that don’t get overwritten each time you upgrade Octopress. Relatedly, distinguishing between regular posts and linked-list type posts is as simple as having an if statement in your template file(s) check for the existence of a particular line in the YAML Front Matter (in my case, a line that begins with “external-link:”).

From the WordPress DB to 3000 files

With Jekyll, and similar systems, each post is contained in a file, where the filename controls the publish date and slug attributes of the post. As you can imagine then, the biggest hurdle to having a static site like this work at all is exporting my huge WordPress database—which includes both regular posts and linked-list posts—into the individual files required by Jekyll.

I tried a slew of different import/export scripts, but every damn one of them broke, some violently. I eventually settled on exitwp.py from Thomas Frossman. I ran into a ton of unicode issues, which I ended up having to sort out by loading my massive WP export file into BBEdit, and doing a lot of finding/replacing.

The biggest issue, though, was getting the importer to make a distinction between regular posts and linked-list posts, and having that distinction reflected in the YAML Front Matter of each post’s file. It’s embarassing how long it took me to get this working (in my defense, had I been at all familar with the libraries used by exitwp.py, it would have taken a lot less time), and it required not only a not insignificant modification of the source code (I’ll post this for others if there’s any interest), but also a modification of the XML in the WP export file. (Having multiple <postmeta> entries for each post is kind of a nightmare.)

Potential Issues

  • I worry a lot about how difficult it may be to get all of this stuff back into some sort of database in the future should I decide to move to a non-static system.
  • Might be a little overkill to completely rebuild/upload the entire site each time you publish a new post. (Yes, there are ways to avoid this, but I haven’t spent much time looking into it at this point.)
  • I probably could figure out a way to post from iOS, but there’s no way it wouldn’t be incredibly kludgy and likely more effort than it’s worth. (Related: there’s a project called OctoMars that would let me use my beloved MarsEdit to post from my Mac.)
  • Explaining to people how the site works. 😉

The photoblog

My photoblog is very important to me, and so it’s weighing heavily on my mind as I try to figure out where to go. Unfortunately, neither place is ideal, and ultimately, the “solution” I go with likely will be implemented the same way no matter the system. (See last section below.)

When I first started thinking about getting away from WordPress, I actually thought about going to WordPress Multisite. Huh? Let me explain. I was entertaining the idea of converting my photoblog from Pixelpost to WordPress, and setting up WP Multisite (which, as the name implies, allows you to have multiple WP blogs in one WP install) at WP Engine. The upside to WP Engine is that it basically is a fully-managed solution (and I’d be using WP, which I know quite well), but I wasn’t totally sold on it being around for the long haul, and its damn expensive.

I’ve thought a bit about not hosting the photoblog myself, and maybe going to something like 500px, but I’m just not sure I like the idea of that kind of site (with likes, comments, etc.) where I can’t control fully its look.

Photoblog at Squarespace

Ideally, I’d just create a separate blog at Squarespace, point it to /photos, and have the index show the posts in a grid, where each post has associated with it a thumbnail of that post’s photo. Unfortunately, I just don’t see that that’s an option right now with SS 6, but maybe eventually with the developer TDK? I just don’t know.

Likely solution (using either Squarespace or Octopress)

I think I’ll probably end up creating a “photoblog” category, put all of my photoblog posts into the regular blog, and then just filter them out when viewing anything other than the /category/photos page. (I’m not entirely sure if that’s even possible with Squarespace.) If I did this, I could create a page that would live at /photos, which would contain a grid of thumbnails that each linked to the respective photoblog post. Of course, this would have to be done completely manually, but I don’t post to the photoblog that often, so it’s definitely doable.

Help?

If you’ve any thoughts on this, I’d love to hear them. Reach out to me either on Twitter or via email. Thanks.