Flat-file Content Management Systems
For anyone who has tried to move a content-managed site from one server to another, or experienced the pain of watching their CMS site taken down by attack bots only to find that the site's backup function didn’t work, or has become tired of entering content through a control panel, help has arrived.
Drupal, Wordpress, and Joomla people know what I’m talking about: Building and maintaining websites in a Content Management System (CMS), usually running in a LAMP stack (Linux, Apache, MySQL, and PHP), is usually a tedious endeavor where all sorts of things can and will go wrong.
Pause for a moment and recall what the Web was all about in the first place. It was originally designed to move data and messages from server to browser and vice versa. Pages were constructed similar to a word processor and transported with HTTP protocol. (Emails and scientific data could be transported using other protocols.) Before long, software engineers were coming up with more efficient ways to build pages, using things such as “include” files, which were blocks of text such as headers and footers that could be used on multiple pages. Dreamweaver, Macromedia’s popular content authoring system, provided HTML templates as starting points. Page coding was no doubt complicated and tedious but at least you had the comfort of knowing there was a 1:1 relationship between page and file. Every page lived in a file that could be moved from one folder to another.
All that went away with CMS systems, which swept the web starting in the early 2000’s, gradually bringing about the near-extinction of websites composed in pure HTML. A CMS had a “rendering engine” which generated “rendered arrays” in response to an HTTP Page Request. Each HTTP request was routed by the CMS to the database to check which templates and content were associated with a particular URL. A page building routine would then plug the content into the appropriate page templates, run some functions to see if anything else was needed, and finally "render" the page into the appropriate HTML tags that browsers could read.
For a website with 1,000’s of pages and a hierarchy of user types, CMS’s made perfect sense. For websites with less than 10 or 20 pages and one or two administrators, not so much. Yet millions of websites switched to CMS’s. True, it was hands-down easier for non-technical people to enter content compared with constructing raw HTML pages or even using authoring packages such as Dreamweaver. Plus, Wordpress and other CMS’s were “free” open-source software. What’s not to like?
Also driving the push toward open-source CMS’s was the trend toward “dynamic” content. Pages that simply showed text and pictures were derisively called “brochureware.” Serious websites were supposed to have “dynamic” features that pulled in remote data, such as Google Maps, or weather information from Accuweather. A dynamic site allowed users to register and log in, contribute content, and be tracked. CMS sites were quite capable of all this. A vast library of modules developed by the user community became available, allowing you to download hundreds or thousands of standard tools such as an email handler, calendar, scheduler, traffic monitor, etc. The world of CMS’s had arrived in a big way and there was no going back.
However, this new world of easy features and free open source software came at a price. When web developers encountered problems, sometimes severe problems, they simply had to bite the bullet and work long hours to fix it. There was always a solution, as long you had a team of programmers or hours of time to research and test. There was no getting around the fact that CMS sites required a lot of coding expertise. Sure, there were plenty of free modules, but they often took a long time to set up, did not always work as intended, and were poorly documented. Developing an open-source CMS website was wide-open territory, supported by a community of enthusiastic users and volunteers who had lots of meetups and conferences all over the world. In contrast, the world of Microsoft Dot Net was far less community based, for example, but you could always pay for technical support for specific answers, which was not as easily done in the open source world. On the other hand, open source had a cool factor that Microsoft, Oracle, and IBM did not. Think Sharepoint. Not cool. (I've never attended a Sharepoint conference, or heard of one, for example.)
If bots successfully breach your kingdom, you needed to have your backup ready to restore. And restoring the backup requires a fair bit of careful planning, since you don’t just copy a CMS site from one folder to another. You have to make sure the database is synced to the site, the base URL is properly set, and that all folders have the correct permissions to prevent any tampering from the outside. You also have to make sure the CMS engine can write to the folders it needs to. There are literally thousands of conditions that need to be correct, and no single support system can offer a neatly organized guide. This may be the bread and butter of web developers, but an expensive burden on website owners. Think federal government.
Enter the “flat-file” CMS. No database required! Yet these sites offer many of the advantages of CMS’s. There are at least a dozen of these platforms available in 2018, most of them open source. My experience is limited to Grav, so that’s what I’ll discuss.
Grav is the brainchild of Andy Miller, co-founder of Joomla, one of the leading CMS platforms dating to the early 2000’s. In 2016 Grav won a People's Choice Award for Best Open Source CMS. Miller also runs RocketTheme, a Wordpress theme publisher, which explains why Grav comes in several nicely designed themes and has a nifty admin panel.
Most importantly, Grav is intelligently organized. For example, registered users are each assigned a .yml file, which is kept in the user/accounts folder. Each user .yml files stores username, email, password, access level, and language. No database required!
Pages do not have their own HTML file, but instead have a dedicated folder with a template file such as default.md, which contains the actual content. This template file may also reference a library of common elements, such as footers and headers. The folder also usually contains all images specific to the page. The folder must be carefully named if you want it to be picked up by a menu. A folder named 01.blog, for example, will be picked up by the Main Menu with the title specified in the Title field in the .md file.
I’ve spent perhaps thousands of hours working in Wordpress, Joomla, and Drupal, and maybe 40 hours working in Grav. I will say that the workflow in Grav became very comfortable after a while, though maybe not immediately.
One of the beauties of Grav is that everything you need to work with is right there in the root folder. Everything has a proper place, whether a template file, folder, or configuration file. Having everything contained in one folder, arranged hierarchically, lends a certain coherence to the site not found in database-driven CMS platforms.
Grav also uses something called “markdown” for page markup. No paragraph tags are needed. Two carriage returns in a row is automatically picked up by Grav’s templating engine as a paragraph tag. Images are typically placed in the page's root folder so the image will be added to a page with these simple tags:
![Dr John Martin](Martin-Portrait1.png?classes=float-right)
Text inside the brackets is of course alt text. In some cases when I was tempted to solve a layout problem with custom CSS, I found that adding new classes or in-line CSS caused trouble. If you need to do anything fancy with the CSS, you will most likely have to abandon the simple markdown style and opt for full HTML coding. There’s no way to mix the two, as I understand it.
I don’t need to explain the joy of being able to upload a Grav site from the local dev environment directly to a live server by using basic FTP. Likewise, installing Grav is not hard, particularly if you use Composer:
$ composer create-project getgrav/grav ~/webroot/grav
Grav does require PHP, although I could only find two PHP files in the install package.
Installing from Gihub is also easy:
$ cd ~/webroot
$ git clone -b master https://github.com/getgrav/grav.git
You can then install vendor dependencies with Composer:
$ cd ~/webroot/grav
$ composer install --no-dev -o
Backing up a Grav site is no more complex than backing up your personal photos. Restoring the site is also a simple copy. With this type of fluid backup and restore, site security is infinitely easier.
If you were particularly concerned about security, you can remove the admin panel plugin (in the config/plugins folder) from the live server, and just use the admin panel on your local dev site. This is sheer genius. The admin panel is entirely optional anyway, something a power user may skip entirely. In any case, being able to run the live site without an admin panel is a great security enhancement.
Documentation is clear and helpful. The documentation is actually a Grav site with a particular Grav theme designed for eLearning. Be prepared to spend some time learning Grav, but also expect to have some fun, as Grav bills itself as the platform that “puts the fun back into” web development.
Grav is friendly, yet very sophisticated in that it uses state-of-the-art technologies such as Yaml, Twig, and Composer. It is also fully responsive if you incorporate Foundation or Bootstrap. I’ve not completely wrapped my head around how Grav handles CSS, but that’s my own fault for not taking the time to investigate. In many ways Grav is a hybrid system, part old-school, part cutting edge. It is sure to gain followers as more and more of a site's functionality can be offloaded into REST services, taking a load off the web platform itself.
I predict it will take a number of years before flat-file CMS's take off in a big way. As this type of web technology continues to grow and develop, it will make sense to convert ever larger sites to these platforms. Even sites with 100 or 200 pages might easily be accommodated, with a tremendously reduced technical overhead. No more need for a MySQL or PHP programmer, for example (unless you needed REST services). That could save the federal government and other big enterprise sites millions.
I for one am quite happy to have Grav in my toolbox for sites that don’t require a lot of users, pages, or features. Andy Miller and his team deserve a lot of credit for putting this excellent open-source package together, at a time when almost everything seems to be moving in the direction of greater complexity. Thanks Andy! Job well done.