Migrating from Drupal to Middleman
Drupal.org finally moved from Drupal 6 to Drupal 7. I figured it was
time for me to get this site migrated off of D6, too. But Drupal 7 was
not the best option for me. Here are some of the reasons I decided to
switch from Drupal:
- Converting from Drupal 6 to 7 is a huge, huge task. It's much more work than I want to undertake.
- Drupal is resource hungry. Most of my recent website issues have boiled down to this. And D7 is notoriously heavier than D6.
- Maintaining a Drupal site is too much work. Module updates, security patches, and just regular admin takes more time than I want to spend.
- Drupal is just more complicated than a blog needs to be. Making simple changes (like adding a Twitter widget) can take hours of my time.
Choices, choices
Not wanting to repeat my Drupal experience on another similar platform, I looked hard at what I really wanted in a blog. Here's my blog feature "wishlist":
- Posts can be written in Markdown (with code syntax highlighting)
- Theming is easy and low maintenance
- Few or no security updates and/or administrative tasks
- Easy management of images and other files
- Simple integration with Disqus (comments) and Google Ads
Very clearly, these requirements pointed me toward using a static site generator. I've already built sites with Jekyll, but I never felt totally comfortable with it. I tried several alternatives, including PHP, Node.js, and Python alternatives. I even started writing a Go static site generator.
But then I discovered Middleman. Middleman is similar in many regards to Jekyll, but it is designed to be a little more generic. (It's not blog specific). It provided the core features I was looking for, and I found the general architecture appealing. So I ran with it.
The new TechnoSophos.Com is built on Middleman with Twitter Bootstrap and Bootswatch.
Then Comes the Content
The only difficult part of migrating the site has been working with the content. Getting anything out of Drupal is a formidable challenge. While I started with established Drupal export tools, I soon realized that it was easier to just write a stand-alone exporter. Exporting Drupal nodes is no walk in the park, but the biggest hassle was actually working with images and tags. I was hoping to build a general-purpose exporter that I could share with others, but in the end it was so specific to my own use case that I figure there is no reason to post it.
One of the most important parts of the content migration was generating a series of 301 redirect rules (all tucked away in an htaccess file). This step is vital for two reasons: First, it keeps old bookmarks and such from leading to 404 pages. Second, it helps other tools (like the Google crawler and the Disqus comments) to understand the new site. I built that into the exporter, too.
The Publishing Process
My old cycle of creating an article was like this:
- Use Mou (my favorite Markdown editor) to write my content
- Login to Drupal as an admin
- Create a new Drupal blog post
- Copy my content from Mou into Drupal
- Add title and tags in special Drupal fields, since Drupal can't extract that from the markdown
- Add whatever Drupal-specific markup I needed (for filters and so on)
- Preview in Drupal
- Fix any filter-related problems
- Publish
My new cycle is like this: - Write content in Mou - Check the content on my local middleman server - Fix any issues - Run a script that compiles the content and pushes it to the site
I'm happy with the new process. The focus is more on writing than on filling out form fields, and I never have to edit content in a web browser.
Concluding Thoughts
Drupal is a good CMS, but I have learned well that running a stand-alone blog site on Drupal means plenty of administrivia. It's also a resource-hungry system. I don't want to focus on maintaining the blog code. I want to focus on writing blog posts.
I'm hoping that this new solution makes that a reality.
