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 that could be used on multiple pages, like headers and footers. Dreamweaver, Macromedia’s popular content authoring system, provided templates as starting points. Page coding was no doubt complicated and tedious, but at least you always knew that for any particular page, there was a corresponding HTML file. A 1:1 relationship between page and file, in other words.
All that went away with CMS systems, which swept the market sometime 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 insert the appropriate HTML tags so the browser could read the page.
For a website with 1,000’s of pages, CMS’s made perfect sense. For websites with less than 10 or 20 pages, not so much. Yet millions of websites switched to CMS’s. It was hands-down easier for non-technical people to enter content compared with raw HTML sites or even content 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 Acuweather. In a dynamic site, users could be register and log in, be given access permissions, be trackable, and able to contribute content. CMS sites were quite capable of all this, since they could incorporate algorithms in the PHP code. Pages could be customized based on the user's individual cookies. Adding a site-wide search tool or email functionality became a relatively easy task compare with an old HTML site. The world of CMS’s had arrived in a big way and it seemed there was no going back.
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 if you had enough time and resources, often an entire team of programmers. There was no getting around the fact that CMS sites required a lot of expertise. Sure, there were plenty of free or low-cost modules and widgets produced by the user community, though they did not always work as intended. Developing open-source CMS’s 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 friendly and community based, for example. Open source had a cool factor that Microsoft, Oracle, or IBM did not. Think Sharepoint. Not cool.
Who knows what evil, sick minds created these bots. Just know they exist and want to destroy your site. If the 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 right, 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 the one 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 becomes very comfortable after a while, though maybe not immediately. In my case it required a lot of text editing (I prefer Sublime Text 2 on my Mac).
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 can be added to the 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, if I understand it correctly.
I don’t need to explain the joy of being able to upload a Grav site from the local dev environment directly to the 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 in my opinion. 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 option for enhanced security.
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.
I predict it will take a number of years before people wake up to the implications of flat-file CMS's. I believe that 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 staff. No more need for a MySQL or PHP programmer, for example, who do not come cheap! 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 great complexity. Thanks Andy! Job well done.