This latest iteration of my site is powered by Kirby, a lovely CMS created by Bastian Allgeier. Kirby has no database and is folder based, so its simplicity is felt in managing the site and, more importantly, in publishing your content.
EE can be set up to work with MarsEdit, a great tool. This would have made it much more palatable, but with my complex set up of multiple channels for different post types, it never worked correctly.
EE is a wonderful tool, powerful and wonderfully flexible. It's perfect for running my church’s website. But it was more than I needed for my own site and had two bits of friction that got old quickly. Getting your content in requires logging in to the web based administration panel. Secondly, the update process is cumbersome, at least compared to tools like WordPress. And every time I would log in to publish an article, there was my reminder that an update was available. And when it comes to writing, any friction at all is a serious problem.
Enter Kirby. I’ve had my eye on the tool for some time and had heard good things from some dot comrades. The migration from EE went very smoothly, partly because Kirby is straight forward, but also largely due to the good documentation that Bastian has created.
If you're considering using or moving to Kirby, be sure to read through the available documentation. Specifically, the tutorial on building a blog. This will give a good overview of how Kirby is structured and how you can adapt it to work for you.
My first step was to decide on the content for my site (and that should be the first step of any web project). Then I could read the documentation and evaluate how Kirby would provide the structure to build out my content. For my needs, Bastian’s example of building a blog fit perfectly.
I wanted to ensure that older incoming links still worked and to do so without any .htaccess skulduggery. This meant that I had to ensure that the URLs were the same as the previous iteration. With Kirby, I simply created a structure of pages, plus a journal. With the folder based structure, it looks like this:
And that is the basic structure of my content. Pages get a folder, and all articles are contained within the Journal folder. Each new article is a text file within a sub-folder. Simple.
Once you’ve established your content and how you think it will fit within Kirby, you really dig into the CMS itself. Again, pretty simple. It's also fairly similar to ExpressionEngine, making use of templates and snippets. The basic structure:
I haven't touched the Kirby folder itself. You’ll spend most of your time in these folders:
The site folder has subfolders, specifically templates and snippets. There's also the plugins and config folders, which you'll use slightly less.
Templates are just that. They are the building blocks for the various types of content structures you'll need. You can see from my setup that most pages have their own template:
Snippets are pieces of code that are shared throughout the site. In the default setup, Kirby comes with snippets for the header, footer and nav (titled menu). I simply use one for the header and footer.
At the end of the day, you could create a blog, portfolio, or e-commerce site with Kirby. It's flexible enough to meet various needs and the template structure allows you to build in a manner that fits for you.
As mentioned above, the documentation was quite helpful and the migration smoother for it. Whenever I hit a snag, a read through the tutorials or a bit of searching in the Kirby forum resulted in an answer.
A good example was the archives page. I simply wanted a page that offered the reader some of the more popular pieces, then a nicely styled list of all articles in reverse chronological order. A my PHP knowledge is sorely lacking, it took me a bit of digging to find the solution.
Another example is the pagination. There's a tutorial on how to add pagination to a list of posts, but not for adding pagination to a single post. The two code snippets are very similar. For pagination on a list of posts:
And for adding pagination to a single article:
And while the first snippet was detailed in a tutorial on the site, the second snippet was available on github, linked to by Bastian in a comment on the Kirby site. So the documentation and knowledge are all there, but you will have to search for an answer on occasion.
The most important piece of this transition for me was how easy was publishing. Friction or complication not welcome. Here's how I've been posting articles in the first several weeks.
On my MBP, I use Transmit almost every day. With posting my articles, I launch a Transmit drive to my server, create a new folder, then drop in my article.txt file that I created when writing the content. That's it.
I do most of my writing on my iPad.
So my drafts are sitting in iA Writer, ready for posting on either my iPad or my MBP. To publish, I use Diet Coda. Opening my site, I again simply create the folder, then add a new text file (article.txt). I then copy and paste the contents of the draft from iA Writer.
As I mentioned recently, migrating the content from one CMS to another can be tedious. In my case, there was no database queries or other technical work to pull content from ExpressionEngine. Rather, I reviewed all my articles one at a time and moved them to the new structure.
This is not a piece of work that everyone would care to take on. But I enjoy it and embrace the opportunity to review the writing. In this case, I decided that my link list style of posts are needless noise, content that I can share on Twitter rather than my personal site. So simple copy and paste of each article, plus a review and formatting tweak, were the totality of my migration. It took several days, but I consider it time well spent.
Although relatively few, the migration was not without issues. The primary issue I found was with the formatting of content. Because Kirby is intended to be used with Markdown, there are a few consequences to how the CMS parses and displays your content.
Kirby will automatically detect line breaks and paragraphs, then wrap the content in the appropriate tags. Most of the time this is not an issue, but some of your CSS styles may be affected. A good example for me was post images. All the content in an article has a left margin of 200px, in order to create room for the aside element. But I wanted post images to take up the full width.
However, Kirby sees the images in the article and wraps them in a paragraph. That means the left margin is applied to the paragraph, while the max-width: 100% declaration on the image results in the image taking the full width of the paragraph rather than the .article parent div.
I'm still looking for a better solution. A parent selector declaration in CSS would be nice, but that's still not possible.
In this situation, I simply wrap the image in a div tag. When Kirby sees this, the paragraph element is not applied.
Overall, this is a minor issue to deal with. Before you make the move to Kirby, be sure to understand how the tool formats the content. Read the formatting text document as well as the text formatting 101 tutorial.
To this point, the performance of Kirby has been excellent as well. However, you may want to give this consideration if you have an extremely large site with a lot of content. With no database, there is less configuration hassles, but there is also no indexing or other methods of enhancing performance. Kirby will parse through all your content with various queries.
For writing and publishing though, the move was very much worth it. I heartily recommend it.