No-DB Content Management Systems

Posted: 2012-09-18

If you're following many designers on Twitter then you'll notice that they've just started noticing flat-file (or "No-DB") content management systems. The basic idea is you swap out the database and complicated admin panels for a simple file and folder structure and use Markdown files instead of clunky WYSIWYG boxes to manage your content.

This is a great idea as it means you can knock the database requirement out of your site, and run a blog and basic page structure with barely any effort what-so-ever.

Hitched to that bandwagon

Two notable projects I've worked on recently using flat-file CMS' are PHP The Right Way and PHP-FIG. Both of these sites are using the Ruby system Jekyll.

What now? PHP websites run using a Ruby CMS? Heresy!

Sssh there troll, it makes perfect sense. GitHub Pages support Jekyll, meaning we can make an entire website just by pushing some text-files to GitHub. We can therefore skip the process of working out who has admin access to the control panel, who looks after the root passwords, who is in charge of making changes, and people can send in pull requests to add new content or fix spelling mistakes. The best part is that all of the hosting is free. EPIC!

For a decreased workload like that I couldn't care less what language it was written in, even if it does seem a little ironic.

PHP is cool too

I know of a few that have been around in PHP for ages now:

  • Rick Ellis (from CodeIgniter, FileDriver)
  • Adam Fairholm (from PyroCMS, called Fizl)
  • Ian Lindsman (from Laravel, called Kudos)

Some have slightly different features and got to various different stages, but are for the most part the same as Jekyll.

I've been using Fizl for the PyroCMS Documentation as flat-files allow documentation to be distributed with ease, but Jekyll was out of the question as it needed to share most of the requirements as PyroCMS itself - therefore requiring PHP so folks could run it locally.

In both situations this is done so the content is easily accessable, can be modified via Git and skips the need for a database. This all makes sense so far.

New kids on the block

Two systems making waves right now are Statamic and Kirby. Both are closed-source with price-tags from $19 to $99. Kirby seems like a PHP port of Jekyll, no different from many of the ones listed above.

Kirby requires you to have hosting and a FTP client to send the code up, so you've paid for the software + a VPS, instead of running your site entirely free using GitHub Pages.

Well ok, we're not all nerds who love Git and they've said they are aimed at designers, but I know plenty of designers who are happily using Git with tools like SourceTree or GitHub for Mac.

So back to Statamic. This one has a Control Panel, which means instead of opening a FTP client you can drag and drop your navigation items around. This cuts out the need for a FTP client to move things, and the Control Panel does seem handy, but now we have to worry about user authentication - something I loved not having in flat-file content management systems. It looks like we've looped back around.

Blogging First

Well here we are with some tools that are getting a lot of hype from designers, which are very good at basic blogging and page management, but not a lot else. That sounds like...

Holy shitballs these guys just invented WordPress without a database!

WordPress has only recently got to a point where it's starting to get decent at doing things other than blogs and pages, and we've swung back around to square one.

The only difference this time, is what happens when you want to add in more? In the past you could install an addon, which would have access to a MySQL database and therefore could do pretty much anything. e-Commerce, Social Integration (storing tokens and whatnot), image galleries, whitepaper downloads and all of the other random things that clients decide they "need" a few months down the line?

Well the two suggestions from Statamic fans are:

  • Recode it with something else
  • Add a Database

Huh...

Use Cases

Choosing the CMS for the job - like everything - comes down to the project.

If you're happy with Git then you might as well do it for free using Jekyll and GitHub.

If you're a designer who wants to get something basic running on your favourite site and you're cool with Coda's FTP syncing then use something like Kirby - but that's going to suck as soon as you've got two people on the site, as FTP syncing is well known for wiping out changes when two folks edit a file.

If you're not going to be FTP syncing (headpat) then Statamic might make sense, and if you need more power under the hood then use a more classic CMS.

Summary

While this surely looks like I am just hating on any project not coded by me, my main point here is to think about which tool is right for the job and raise the questions you should be asking yourself during the selection process.

Don't make the mistake of falling into the "WordPress & Co." trap again where you have an awesome blog built on a trendy system but have to sacrifice a goat, install a bazillion add-ons or screw around with nasty code to make it do anything useful.

That said while it is great that different systems approach the same goal in different ways a lot of this does feel like buzzword bingo.

Next these guys will add a MongoDB database and act like that is some AWESOME new advance in CMS, which has a heap of its own quirks and use-cases too - and of course nullifies the primary benefit of using a flat-file system in the first place.

Try everything, use what you like, just don't fall victim to buzz-word bingo and try things out before you start putting clients on a product.

Comments

Gravatar
Bastian

2012-09-19

Hey Phil,

just a few things about Kirby:

1. It's not closed-source: http://getkirby.com/blog/free-trial
2. There's an optional admin panel for it as well: http://getkirby.com/docs/panel
3. It has built-in mysql support if you need it: http://getkirby.com/blog/database
4. It can be connected to dropbox if you don't like FTP: http://getkirby.com/blog/kirby-meets-dropbox
5. I consider Kirby a cms not a blogging tool in the first place and it's source and api has nothing to do with Jekyll

Cheers

Gravatar
Andrew

2012-09-19

Nice read, I think file based content management systems have a nice little niche market and I would like to think they not only have that but have some advantages over database based content management systems.

Imaging creating a static site in just HTML, then the client says they want to be able to update content on the website themselves while staying on their same old server (which doesn't support any database btw, yes servers like this still do exist), here comes Statamic to the rescue, I can now hand them a system which is file based, has a control panel and works on their existing server.

So there is the argument of Jekyll vs the paid solutions, personally as a developer I don't mind using Jekyll, but I guess from a designer/client perspective they wouldn't want to be jumping into the command line to start a new site, then having to setup Ruby also in order to get it to run, we know the old argument of PHP being more widely available on server than all other languages (except for Perl maybe).

But to close this off, yes its best the person choosing the CMS use what will suit their clients need and not choose because its popular, the new trend or just looks good.

Gravatar

2012-09-19

Thanks Bastian.

Andrew: I guess a lot of this post was me thinking "what is the use case?" for some of these. Are there really that many clients who don't have hosting without a database? They are either on a VPS or some hosted platform which will 99% of the time have a database, or they will have their own server so you can install software. I totally understand the whole "Just backing up files is easier than backing up files and database" situation, which is why I am building SQLite3 support into PyroCMS 2.3. That will work if they have PDO which pretty much any system over PHP 5.2 will have.

You seem to be suggesting that the use-case for Statamic is a band-aid solution for clients who don't want to move servers but want a blog, and it is only a temporary solution because at some point they will need a database (MySQL or Mongo). That is simply offsetting the point at which they need to move servers for a bit?

That seems like a bizarre niche to me but I am happy to be corrected.

Gravatar
Kiril

2012-09-19

Note: I'm a Statamic fan and license holder.

I appreciate such overviews, thanks for the interesting read.

What I like about Statamic:

It distills many of the good ideas from other systems - things like: data design, page rendering, configuration management, control panel design - and integrates them in such a way as to make the whole process much more efficient/simple/flexible(Pyro does something similar).
This and its breadth of features make it different from the rest, and justify its existence as an alternative to other CMS's.

Regarding ease of extend-ability:

It is based on the SlimPHP framework, which in v2 will be PSR-2 compliant. Such standards compliant code is to be preferred over framework/CMS specific addons/plugins/modules.
Plus, working within a framework makes developing features a breeze(lets not get too lazy!).







Posting comments after three months has been disabled.