Stop, I’ve already spent this headline, albeit on a different subject.
This time, however, I’d like to briefly discuss my first impressions of Octopress 3, the next evolution step of the static blogging engine I use for publishing this blog.
Octopress 3 has been around for a couple of weeks. As I write this, Octopress 3 can already look back to a rapid succession of bug fix releases ending up in the currently available 3.0.11.
Of course, as a user of Octopress 2, I’d be intrigued1 to see how the platform is making its way into the next major release.
When using Octopress 2, it does not become immediately visible that the heavy lifting of blog generation is actually done by Jekyll, and that Octopress 2 is basically a convenience wrapper around Jekyll that takes away some of the rough edges of directly using Jekyll for blog generation.
Octopress 3 takes a different approach in that it clearly separates its job to “logistics tasks” on top of Jekyll, and then let the user actually call Jekyll as part of the publishing workflow.
I don’t have a problem with this approach, as long as it’s working as advertised. Which it does, as far as I can tell.
At least, I was able to install Octopress 3 and further gems2 as well as to port my blog to the new engine quickly. Menaing: it took a short amount of time after having installed Octopress 3 until I got my site up and running served locally by Jekyll.
That’s not the end of the porting effort, though. The slugs generated by the combination of Octopress 3 and Jekyll are different than the ones generated by Octopress 2.
This is a bummer, and leaves the option to either tweak the new workflow to the point that it creates identical slugs as my existing engine, or else create
redirect permanent rules into a .htaccess file to accodate for the change.
Of course, the .htaccess file is sort of the last resort. And it would be nicer if the job could be done directly as part of the generation process.
And it turns out: the easiest way to generate the slugs as required is to drop all the categories from the blog. Which is OK, I have used the categories more or less halfheartedly and getting rid of them is not such a big deal.
The landing page that I end up with consists of a list of article headlines as opposed to a list of full articles, as I end up with in Octopress 2.
Customization will be necessary. This has been foreseen by Brandon Mathis, the main contributor to the Octopress project. It seems that it will be possible to define Themes as a measure of customizing a blog extensively.
There is a default theme available, called Octopress Genesis. According to its description, it is a “work in progress”. It is certainly possible to use the theme as is, but I unfortunately failed to find out how to apply any customization to it that was respected in the generation.
In principle, it should be possible to overwrite the default theme by putting the respective files into the _plugins directory. I tried several variations of putting the files into the directory, but to no avail.
Maybe this is part of being “work in progress”. I looked up how plugins are processed by Jekyll. I didn’ get the impression that themes are processed as plugins, but maybe that’s just me.
Anyway, the theme also does not generate a landing page that is a list of full article text either. On the bright side, it takes care of footnotes in the way I prefer footnotes to be taken care of: Bigfoot style. And, just to name another nice feature, it is possible to add pages to the site in a very simple way.
Granted, it would be possible to tweak the theme in its default installation location. But, frankly, that’s an evil hack. In conclusion, without being able to customize3 the theme Octopress 3 is not really usable.
So no, not ready for prime time so far. Not for me, at least. I’ll need to invest more time to better understand how the customization of Octopress 3 is supposed to work. But never mind, I can wait, no problem.