title: The year of the flat file CMS? link: https://onemoretech.wordpress.com/2014/04/02/the-year-of-the-flat-file-cms/ author: phil2nc description: post_id: 7248 created: 2014/04/02 13:56:14 created_gmt: 2014/04/02 17:56:14 comment_status: closed post_name: the-year-of-the-flat-file-cms status: publish post_type: post

The year of the flat file CMS?

There are a couple of articles I came across recently, Goodbye WordPress: 2014 Will Be the Year of the Flat-File CMS and 2014 Will Not Be the Year of Flat File Websites, that got me thinking. What if BBQ Iguana is right? What if "WordPress needs to die"? As those who have followed this blog for awhile may know, it was actually published using the FlatPress flat file publishing system for just over a year between 2010 and 2011. I was actually quite happy with it from a performance and ease-of-use perspective. It was also a lot easier to develop on. In fact the only reason I went through the painful process of porting everything back over to WordPress was that my host provider at the time blacked out my sites due to a debilitating spike in CPU usage traced back to the FlatPress application. Whether the problem was due to some inefficiency in the code that just got out of control or triggered by an external exploit was never determined. What I learned from that experience was that system stability always needs to trump programming ideology. Having worked with embedded nosql data stores (in the form of LDAP directory backends) for over a decade, I know quite a bit about their advantages and limitations compared to traditional SQL databases. Without re-hashing the whole SQL vs NoSQL (or in the case of the newer anti-WordPress upstarts, SQL vs "no DB") debate here, suffice to say that it mostly comes down to requirements and expectations. Hash tables work much better in some situations than database tables, in others a lot worse. The same can be said of flat files versus either hash or database tables. On first impression using a relational database for serving up web pages would appear to be overkill, even counter-productive from a resource utilization standpoint since hardware will have to service both a web and database server. Further, since WordPress and nearly all of its SQL database driven cousins store images and non-text content on the filesystem, any savings from storing article text in a database (assuming there is any savings at all) may be negligable (especially on graphics intensive sites). Having article text reside in files on a filesystem can be a huge benefit when you need to make bulk changes without the need for complex SQL query logic. It can also make it much easier to move them from one place to another. But using a database to store things like article text, links, and configuations (like subscriber lists) can be a benefit especially when trying to track usage and performance over time. It can also make integrating with exernal applications easier (or even possible). If you're using a blogging platform like WordPress as budget CMS, having everything keyed into a relational database allows you to provide versioning capabilities that are usually missing from flat file systems. Which takes us back to the current debate. Which is better, a flat file system or a database? My answer, as you've probably anticipated, is "it depends" -- because the sql vs. nosql, or db vs. no db, question isn't the only one that needs to be answered. For example, although the Ghost blog platform uses flat file storage, it is implemented as a Node.js server. Presumably you might want to use Apache or another enteprise-grade server as a proxy in front of it (the Ghost developers seem to have a preference for nginx, one that I am professionally ambivalent about at the moment), but that added layer of complexity gives me pause. Still, Ghost is free and open source, released under an MIT license (although there are paid options for hosted and premise installations). Kirby is more of a traditional php application. While its source is published, deployment is governed by a proprietary license that costs $39 per website, which is fair enough, I suppose, but makes it a no go for me (I'm happy to be given a paid support option, but given all the alternatives available find it hard to justify paying a fee just to host something on one of my servers). Jekyll's source is available, for free (as in beer) under an open source MIT license. But it is also nontraditional in the sense that it is implemented as a Ruby powered server. Clearly the additional complexity resulting from its implementation as a service, and its having been written in Ruby, are stumbling blocks for me. Statamic is less generous, although it only charges $29 per site it is entirely closed source and unfree (as in freedom to fork). Given that, it seems out of place among the others mentioned here, until you realize that the article that cites it was written by a Statamic theme developer. All of which makes me wonder if I should take some time to revisit FlatPress, at least for situations where things like versioning aren't needed (although I actually used versioning heavily during the composition of this post). In the end, however, as much as some of us might want to rid our lives of WordPress, for me it continues to be a useful, free and open source tool that solves more problems than it creates. And that's not something I'm willing to give up on just yet.

Copyright 2004-2019 Phil Lembo