Choosing Between Kirby & WordPress

My Touchstone Project

Soon after completing the first version of Jony.io, I started to realize the potential of having my own corner of the internet. I immediately wanted to share more content than the previous infrastructure could support, and began analyzing the designs of some of my favorite sites. I had an idea of what I wanted to accomplish: a more open and less structured homepage that featured a number of unique post types. My goal was to create a set of standards that could evolve over time, without affecting the content. This resulted in a few minor design trade-offs, but if I wanted to create a new post type or make significant changes to the template, doing so would not interfere with what's already been published.

The Dissolution of WordPress

Every website I had been involved with up to this point used WordPress for the site's backend, and because I had been working with the CMS for years, I was never worried about implementing my designs. From the inexhaustible list of plugins to covetous themes, WordPress is infinitely scalable and grows as your site grows. There are so many benefits to using WordPress, not to mention the wealth of amassed knowledge and tutorials for just about any problem you might come across; if I encounter an issue, I know that somewhere in the depths of the internet is a solution.

When the time came to start developing the second version of Jony.io, I had to make a few architectural decisions — namely how will posts be uploaded, categorized, and subsequently styled?

There are many ways to accomplish a multi-post system with WordPress, but none of them are perfect. You can use the default Post Formats, but the thought of labeling a "Project" as an "Aside" was going to drive me crazy. Another option was to use Categories to style posts, but this would severely limit sorting options should the site grow to any modicum of success. The third option was to create custom Post Types that would style posts based on how they were sorted. There are even more choices (not to mention plugins), but each one felt like another hack that I would regret in the short term.

The Terrifying Release of Calypso

I was really excited when Automattic announced Calypso, a re-imagination of WordPress' front-end interface. Calypso is an open source JavaScript application built from the ground up as a replacement to WordPress' aging MySQL and PHP codebase. It is fast, page loading happens nearly instantly, and all changes are made in real time. Calling Calypso an improvement to traditional WordPress installations is an absolute understatement.

Before going further, it is important to point out that there is a very big difference between the fully hosted WordPress.com and the self-hosted WordPress.org. Though it isn't advertised as such, WordPress.com is essentially a stripped-down version of its .org counterpart, which is more suited for "techies that prefer to maintain full control over their code." You can read more about the differences here. I'm bringing this up, because Calypso introduced an anomaly in the WordPress release cycle; notable features were missing from the .org interface — namely custom fields. This made me pause, because I wasn't certain whether or not Automattic planned on phasing the feature out, if custom fields just didn't make it into the initial release, or if the Calypso interface was never intended for .org installations.

Despite the excitement, speed improvements, and more attractive interface, Calypso terrified me.

It was at this point I started questioning whether or not I wanted to use WordPress. Ultimately my goal was to make it as easy as possible to publish content, and any hurdles to getting things online was a possible deterrent to posting things in the future. WordPress' implementation of custom fields is powerful, but if you use more than one or two, things quickly get out of hand. Combined with the unsettling release of Calypso, it was time to explore other solutions.

Enter Kirby

With a deadline looming over my decision, I consulted with Google to find the "best CMS." Kirby had been on my radar for some time now, but I noticed the name appearing more and more throughout my search. A number of respected professionals had made the switch to Kirby. Ivo Mynttinen had been using Kirby for various client projects, and now uses it for his personal site as well. Chris Bowler was an early adopter, migrating from ExpressionEngine to Kirby in 2013. I also took notice of Kirby's Showcase, a collection of websites powered by Kirby that featured several design portfolios and a number creative projects. All of this was building the case for Kirby as a serious web publishing platform.

Kirby is a file-based CMS by Bastian Allgeier that's gives you the freedom to structure your content in the manner that suits you best. It's extremely fast, and does not require a database, which means everything is stored as files and organized by folders: content, templates, plugins, etc. Moreover, Bastian's licensing policy is extremely tolerant: try Kirby on any local installation before paying a nickel. From purchasing, to installation, to daily use, Kirby is just as simple as it sounds. For information on pricing, please visit the Kirby Store.

First Impression of Kirby

This all sounds extremely positive, because I'm writing this from hindsight's perspective, but in the moment, my unfamiliarity with Kirby's backend and template structure was unsettling.

Kirby's homepage is adorned with the masthead, "Kirby is a file-based CMS. Easy to setup. Easy to use. Flexible as hell." The folder-based structure is consistently touted as its best feature, but file-based organization does not appeal to me in the slightest. It immediately felt like Kirby was built by developers, for developers. Maybe it's the designer in me, but give me a UI over the filesystem any day. I don't want to worry about numbers before folder names, nesting folders to create the URL structure I like, or using name-semicolon for the different fields in a plain-text document.

Mobile publishing isn't promoted or advertised anywhere on Kirby's site or in the docs. I live on my iPhone, and maintain that the main reason I have been unable to develop a consistent blogging habit is because of how difficult it is to get things online from a mobile device. Despite reading what feels like every article about "posting to Kirby from iOS," the process seems to involve multiple apps and devices. Some use a Dropbox account that periodically syncs with their server (which isn't possible on my Media Temple Grid), while others rely on their Macs at home and a Hazel script. There are solutions, but they all pale in comparison to Federico Viticci's WordPress Workflow, which can post to MacStories with one tap. If you know of any solution that uses Ulysses, Workflow, and Transmit, please get in touch.

There were also little quirks that I wasn't sure I was willing to overlook. For example, I personally like Daring Fireball's approach to URLs, /category/year/month/title, which makes it highly unlikely two posts would ever compete for the same URL. With WordPress, this is a simple thing to change – just go to your settings and WordPress will handle all of the routing for you. It looks like this is possible with Kirby, but it requires some advanced techniques and willingness to experiment with the backend. Another example: most link-blogs only show the date once-per-day. WordPress has a built-in syntax, that handles this for you, but with Kirby this is more complicated than I would like. I created a thread about this in the Kirby Forum, but the proposed solution was too complicated for such a simple result.

If you use what's advertised, you shouldn't have any issues, but if you plan on implementing custom details, things quickly get complicated.

In the end, "my goal was to make it easy to post content," and so details like these would have to take a backseat to Kirby's superior publishing workflow.

Benefits of Kirby

Introduced with Kirby 2.0, the Panel is the UI component to getting things online. You can manage your content, add or remove users, interact with plugins, and so much more. The Panel is extremely simple to use and has a very shallow learning curve, meaning it's great for our less tech savvy brethren (aka clients). There are a few minor oddities; not everything can be accomplished with the Panel. For example, it is very difficult to move content to another section once it has been published. This is rectified by Kirby's infinitely malleable backend, but if you are at all uncomfortable with code, this might affect your decision substantially.

Blueprints create the individual form fields in the Panel. You can have a different Blueprint for each post type, page, template, etc. Think of Blueprints as Custom Fields on steroids. I am using unique Blueprints for articles, links, quotes, projects, pages, and more. This allows me to see only the fields that matter for a given post. For example, a Quote only needs two fields, the quoteText and author, whereas a Project will use substantially more. These are not the identifiers I'm using personally, but this gives you an idea of the power of Blueprints.

Kirbytags allow you to extend Kirbytext, which is an extension of Markdown. Think about that for a second; you can create your own (modified) Markdown syntax to create content or format text. Some examples include automatically linking to a Wikipedia article, adding links to Twitter profiles, or listing all downloadable files for the current page. Phillip Gruneich from One Tap Less wrote a custom Kirbytag to embed actions, workflows, and scripts into his articles. You can see an example of Gruneich's Kirbytag in action here.

On a more philosophical and personal note, Kirby offered what I wanted out of the box. What was considered a "hack" in WordPress is a feature in Kirby. For personal sites, I had never planned for longevity, which meant very little care was given to archives, backups, and organization. Kirby handles the organizational part for you, storing all content as plaintext files, using standards like Markdown, which means you can migrate the site pretty easily if you decide Kirby isn't for you.

Victor Ludorum

I've only just started using Kirby, but I've gotten very comfortable with both the template structure and publishing workflow. I was worried I was going to encounter unreconcilable issues during development, but even with my limited programming experience, I was surprised at how much I was able to do on my own. Though it may not look like it, I am doing a lot of custom things in the background that won't be obvious without diving into the code. I would say that the site is about 95% of what I wanted it to be, and the remainder can be attributed to my own mistakes, changes during development, or details like forgoing my preferred URL structure. If I were to ever ditch Kirby, it would be in favor of a superior mobile publishing workflow.

I would be remiss not to mention the friendly and accommodating support I received from the Kirby community. The Kirby Forum is absolutely invaluable to help answer questions or solve any issues that you come across. The forum is extremely vibrant, and eager to help you accomplish your goals. The Kirby Docs are also extremely detailed, and guide you through all of the basic setup for getting your project online. I wouldn't have been able to create what you see here without their help – kudos and beers are definitely in order.

I built this site with the hopes of developing a blogging habit; the things we share (both in-person and digitally) say a lot about what matters to each of us as individuals. I imagine my personal filter will cover design and technology, but it is my hope that these topics will be sprinkled with social commentary, politics, and general chit-chat. I've been working on this update for months, and still some features and content I had planned didn't make it into the first release. Luckily the web has developed into an ever evolving stream of content, and the foundation I've set should last for a very long time.