I’ve never really loved WordPress. There. I said it.
But it is very powerful, well supported, particularly suited for blogging, and widely deployed, so was a natural choice for this website.
It does come with its own baggage, however. For one thing, it’s not so easy to develop locally and deploy remotely; having to keep the MySQL databases in sync is a mess trying not to hose something up on one end or the other. Tools like iTheme’s BackupBuddy help a lot, but you still end up having to manually blast your development database over the remote database for each deployment. That’s OK, I suppose, for the main live site, as the updates shouldn’t be happening all that often. But it’s less fun on a remote staging server that sees more development work.
Don’t forget the darned wp-config.php file. Overwriting the remote version with the local version kills the site and requires some hand-editing to get it going again. The whole business is not as easy and clean as I would like.
And, really, WordPress can often be overkill. Take, as an example, my Bob Rockefeller Photography website. It has a simple blog (that is well overdue for some new content), about and contact pages, portfolio galleries, and an area for clients to view their proofs. Hardly an application for an enterprise-scale CMS (Content Management System).
What About Kirby?
There are a number of NoDB (no database) CMSs around from static site generators such as Hammer for Mac and Jekyll to a group of dynamic site creation tools lead by Kirby and Statamic. I decided to move Bob Rockefeller Photography from WordPress to Kirby as a test of Kirby’s abilities and as a way to make development and deployment easier. I have plans to upgrade the client areas of the site and I want to get set up for that work.
What made me look to Kirby? In no special order, I like:
No Database – nothing to sync, nothing to migrate, nothing to query, nothing to mess up. The structure of the site is defined by the organization of the file structure. Metadata is stored inside files as simple text.
Your File Structure Is Your Site’s Structure
Plain Text – use either plain text, HTML or Markdown for content. I really like writing blog posts in Markdown; I can do it on any device, with nearly any program, do it anywhere and then just save it as part of the site when it’s done. And Kirby (through its kirbytext() function) understands Markdown Extra for more formatting power than John Gruber designed into the original Markdown. If that’s still not enough, you can create your own extensions to kirbytext() in a file named kirbytext.extended.php added to you plugin folder.
PHP Templates – no need to learn yet another template language. The rest of the framework is written in PHP, PHP is a natural language for web developers to use anyway, and it’s perfectly good for creating templates of any complexity. Sticking with JavaScript, HTML, PHP and Markdown works for me.
Dead Simple Sync – just upload any changed files right over the existing ones. The local site is exactly the same as the remote site. I use MAMP Pro for local development and then Transmit to sync the local directory to the remote directory.
Expressive Syntax – so clean as to be nearly self documenting. Kirby is really a simple (but not simplistic) PHP development framework (think a much lighter weight CodeIgnitor or Laravel). Want to return an object loaded with all the articles in the blog?
|
1 |
$page->children()->visible(); |
Need to create a paginated list of blog posts in reverse alphabetical order?
|
1 |
$page->children()->visible()->flip()->paginate(10); |
Handy Toolkit Included – get more utility functions in the Kirby Toolkit, the underpinning for Kirby itself. This will be important to me as I work on the new client area features. Having a PHP framework to build with is a good thing.
Documentation – there is a lot of it on the Kirby home site. And tutorials, too.
Support – a must have and it’s there. On the web is a forum frequented by Kirby users. And there is access via email to Kirby’s developer Bastain Allgeier; I’ve had several help email exchanges with him as I got myself up to speed.
If I were to write down a couple of my admittedly few gripes with Kirby, I would wish for a much better tool for moving WordPress content to Kirby and a tutorial on hooking into Kirby with AJAX. But, understanding that Kirby’s intent is to be lightweight, these are probably just nits to pick.
So there you have it. I would recommend that you take a look at Kirby (go see the FAQ, first) if you would like to simplify your blog or need to develop websites with something a little more lightweight than WordPress, but don’t want to have to start from scratch.
At first I was put off by the 
I had been using 
Let me tell you about the second part first. I had been using 
Where does CodeKit fall in? Its kind of a junk box of handy tools, but I use it mainly for its ability to update a browser window whenever you save a file its been tracking. So as soon as you hit save for the CSS file you’re editing, it updates your browser. Nice! And one of these days I’m going to get serious about Sass or Less, and both of those are compiled on save by CodeKit.
My sites are all accessible via FTP, so something with the power and features of 
Chrome is my web development browser, but not my day-to-day browser. I like Safari’s interface, iCloud connections, and general feel much better for my usual surfing. And it used to be my web development browser, too, because it added web inspector features; but then came version 6. For some reason the developers decided to change the web inspector and dropped the ability to easily find which CSS rule was overwriting which; it used to be in the Computed Style when exposed by the little down arrow.
I’m a photographer and a Macintosh user who shoots what catches my eye and tries to remember David duChemin’s credo: “Gear is Good. Vision is Better.” I also dabble in HTML, CSS and WordPress coding. [