Migrating from Pelican to Wordpress

Planning

I’ve migrated my main blog from Pelican to Wordpress. (Pelican is a static blog generator.)

The main reason for changing is that I to make some changes in my webpage layout, or add some feature like a landing page, but don’t want to make (program) all the changes myself.

Using Wordpress will add complexity to my publishing workflow, but things like implementing landing pages and writing custom page archives can be quickly done in Wordpress by using the appropriate plugin. Also, I don’t have time to make sure my Pelican template/theme/skin stays responsive web-wise each time I need to change something.

My Pelican setup used a combination of Pelican, the program, installed on a Linode server, that generated my blog from a folder in the same server. The folder was kept in sync with my laptop using Dropbox. (More about this setup here.

Every Rose has Its Thorne

Installing Wordpress from scratch in my Linode server, choosing a theme, and installing some basic plugins took around an hour. The most time consuming step, however, was migrating the content to Wordpress.

Markdown Issues

I’ve been writing my posts in Markdown for some years now. The idea is that I can take my content everywhere, because Markdown is close to an universal jargon, so to speak. The idea is to “own” your content so you can take it with you to whatever blogging platform you use, and the content being as close to human writing as possible (which HTML is not).

In reality, however, the Markdown flavor Pelican uses is not 100% compatible with the flavor Wordpress uses (I’m using the one provided with Jetpack). The main difference is how you specify html attributes like classes to your markdown.

For example, my book reviews include a image of the book. It’s format is specified using a class="imagebook" attribute, which in Pelican looks something like this:

![Deep Work](http://.../bookcover.jpg){: class="bookimage" }

In Wordpress’ Markdown, the same line should look like this:

![Deep Work](http://.../bookcover.jpg){.bookimage}

Also, while I could add attributes like {: target="_blank" } to any link, Wordpress’ Markdown doesn’t provide (as far as I know) anything similar. (This is just a consequence of Markdown extensions not being standardized.)

My solution for this was simple:

Use a text editor (Atom, in my case) and open the folder containing all my content. Then, use Find/Replace project-wise to replace Pelican markup for Wordpress’ flavor. (Forget about `{: target=”_blank” }, just settle down for external links to open in the same browser window.)

Lesson learned:

Disqus Comments

The second pain was migrating Disqus to Wordpress.

Disqus uses your Disqus shortcode (a sort of username) for identifying your account. Then, it uses a unique identifier to identify the comment thread for each of your posts. This identifier is passed as the disqus_identifier variable in the Javascript code that actually load the comments on the web page.

In my Pelican setup, the unique identifiers for each post were created using the one thing that is unique for each post: it’s permalink, without the domain. Like in /2014/02/25/pelican-dropbox-automatic-blog-regeneration/ My idea behind this was, again, to be able to take the comments with me to whatever blogging platform I choose.

Wordpress’ Disqus plugin, however, has another idea of what constitutes a unique identifier. It uses Wordpress’ unique post ID to build it:

1119 http://zoia.org/?p=1119

The problem is that the 1119 is unique to Wordpress, and there was no easy way to convert my existing Disqus IDs to that format.

My solution was to hack the Disqus’ plugin code so that it generated the unique identifier in my own format:

function dsq_identifier_for_post($post) {
    // return $post->ID . ' ' . $post->guid;
    return rtrim(parse_url(get_permalink($post), PHP_URL_PATH),'/');
}

The problem: I’ll need to patch the code every time the plugin is updated. The benefit: I keep my more logical (to me) identifier structure.

Migrating content itself

I tried several plugins to import my content directly into Wordpress, without success. Pelican is not widely used, so there is no direct way to migrate your content to Wordpress.

Being my posts a bunch of text files with YAML headers residing in a folder on my laptop, at first I thought of writing a Python script that read every file, extracted the post’s metadata from the YAML header, and injected it into Wordpress using the Wordpress API and an appropriate Python library. (Which there are plenty.)

For every post, I would have to check for links to local image files. If found, the image file would be uploaded to Wordpress, and its new URL would replace the original one in the post.

This is not a difficult script to write, but I’m sure it won’t be without it’s pitfalls. And then, knowing myself, I would still want to check every post to see if it rendered OK.

So, I opted for a more manual procedure: copy each post manually. (Yes, I know what you are thinking…) I did this in 30 minutes chunks, for several days. Not the fastest thing, but it did get the work done. The third day, I became tired of this manual procedure and wrote a Pelican exporter. (You can download it from Github.)

Template tweaking

I’m using Genesis as the base theme. I used the Genesis Sample Child theme as a base to customize my blog’s appearance to mimic its previous incarnation. Almost 100% of this was done by adding to the CSS file. Genesis is a good alternative, and not being a CSS specialist, it’s structure is clear and relatively easy to adapt to your needs.

Lessons learned

For me having my content in a format portable enough that allows me to republish it wherever I need is an important requirement. Using Markdown is a good way to do it. Actually migrating the content is not as simple as it sounds, however, but it can be done.

Link: Shawn Blanc interviews John Gruber

This is interview is from 2008, by I’ve just re-read it and thought it was worth linking for my future reference: John Gruber: A Mix of the Technical, the Artful, the Thoughtful, and the Absurd.

Tags: daring fireball

Link: This is GIT

This is GIT

Link: What is Code?

Excellent long article by Paul Ford: What is Code?.

Link: Brandon Sanderson Creative Writing 2013

I recently found this [great] 2013 course on Creative Writing by Brandon Sanderson (!!). I’m posting it here for future reference.

Tags: writing

Link: Simplify: move code into database functions

Interesting article by Derek Sivers. What if the code for some basic operations were coded in the database itself, instead of in the server-side or client-side layer?

What is a Hacker?

Steven Levy: What is a Hacker?

The Parallel between Chess and Programming

I found this quote I wrote down some time ago from an interview with Victoria Livschitz, serial entrepreneur, a founder of Grid Dynamics and more recently, a technology start-up Qubell1.

Chess, like any other complex intellectual activity, involves a combination of knowledge, creative vision, and technique. Good chess players are able to acquire and store a lot of information — classic and trendy opening systems, standard endgame positions, novelties specific to their repertoire, and so forth. The creative vision of a master comes through his or her ability to discover patterns hidden in the position, then correctly interpret the competing (and often incomplete) patterns as either more or less relevant to their goals — and finally choose the best option. Also, it requires flawless technique to see the well-played game through to its logical conclusion, in the face of the creative resistance put up by a skilled opponent. This combination of knowledge, creativity, and technique is what has been attracting people to chess for over 4,000 years.

The parallel between chess and programming is rather obvious. Programming is also about knowledge, creativity, and technique. Good programmers must have a vast body of knowledge at their fingertips: the programming syntax of one or more languages, standard and special-purpose data structures, typical (as well as advanced) coding techniques, many kinds of libraries and APIs, a multitude of design patterns, and so on. Good programmers use their creative vision to recognize many patterns that may be relevant to the solution of the specific design problem at hand, and correctly choose the best approach. Finally, no matter how good the architecture and design are, to deliver bug-free software with optimal performance and reliability, the implementation technique must be flawless.”

(Victoria Livschitz)


  1. The interview was originally published on Sun Microsystems’ page but thanks to Oracle it’s no longer there. 

On Markdown and how to fork a project

Markdown and its syntax specification were developed by John Gruber as a text-to-HTML conversion tool for webwriters. Over the years, it has been widely adopted by sites likes GitHub and StackExchange. Most programming languages have some kind of Markdown library available, always developed not by Gruber but by some third party.

The syntax for Markdown hasn’t been updated in years. Different implementations implement Markdown different… and output different HTML code for the same markdown. Jeff Atwood (Coding Horror), John MacFarlane and others have launched an initiative to work around the limits of the current Markdown specification. Jeff Atwood explains their motivations in his post standard flavored markdown.

The ‘problem’ is they chose to name their project Standard Markdown. After a mail from John Gruber stating that he found the name inappropiate, they renamed it to Common Markdown, which doesn’t seem adequate either.

I think standarizing Markdown is the correct thing to do. But if the initiative does not come from the project owner, the way to standarize an open source project is to fork it and change its name to whatever you want.

Tags: markdown

Marco Arment on Overcast

Just finished listening to Episode 43 of Debug, where Guy English and Rene Ritchie interview Marco Arment about the recent launch of Overcast, his podcasting app for iPhone.

The episode is great. It is around three hours long but worth the time if you are interested in iOS development and the app ecosystem. Marco explains some of the problems he found while implementing the app and how he solved them, and his product design decisions.

Link: Debug Episode 43.

Tags: ios

Page 1 / 5 »