print 

Mara flatfile CMS

Origins

and why we wrote our own site frontend

At one time we had a bunch of client sites which had been built on the most popular CMS at that time. The use of a CMS seemed to offer several advantages over a static site, especially that clients could edit their own webpages, and that we had a huge collection of plugins to choose from. The downsides, as we were to discover, were two related issues: Weak security, and galloping version-changes.

A feature of virtually all database-backed CMS is the need to continually update in order to close code-injection vulnerabilities. Fail to do so regularly, and you betcha the site gets hacked in a very short time. Now, this raises multiple  issues. One is that continual updating creates a very significant workload for the site maintainer. The labour cost of this continual updating can be very considerable, especially for webdesign companies maintaining numerous client sites.

Perhaps most significantly though, is that the neverending stream of updates may break functionality, or may require you to radically change the ways in which you do things such as designing themes or templates. This one is the real killer because as a website pro you've probably invested  hundreds of hours in your template collection, and finding that you suddenly cannot use any of your existing work is nothing short of a mission-critical catastrophe.   

We hit this one with a very popular database-backed CMS we were using a while ago, in that the new version had been changed so much that the templates we had so painstakingly built for our clients' sites just wouldn't work with it. The only option seemed to be to start from scratch with a blank slate, and build a completely new website. Unsurprisingly, some of the affected clients balked at the cost of replacing a (to them) perfectly serviceable website with another identical site. After thinking about it, we decided that the issue wasn't so much the amount of work required to convert our templates for the new version, but that the same amount of work could suddenly recur at any point in the future, unannounced. The sensible alternative seemed to be to investigate other CMS products with fewer of these issues. 

Looking around for a replacement, an associate pointed-out to me a lesser-known product which offered a very nice and well-ordered admin interface, and which seemed to be remarkably easy to use. This was a database-backed product, however the publishers assured us that every effort had been put into ensuring security, and this claim did seem to be borne-out by both Secunia intrusion reports and security updates being rare. Thus, we were very enthusiastic about this product.

Issues that could not have easily been predicted in a product appraisal soon started to emerge, though. Firstly, there was enormous difficulty with trying to understand the template structure, being that this used a highly idiosyncratic language of its own. After spending the time needed to learn the template language, we then hit a major issue: Once a new object had been added to a template, its removal crashed the CMS completely. Even restoring the files exactly to how they were, would not get the thing running again. I can only assume that the new object was somehow automatically registered in the SQL database, after which the system became dependent on its presence, junkie-like. After a brief foray into debugging this problem, made especially hard by the authors' use of deeply-nested code objects referenced across numerous include files, I decided to give up on the package. It had seemed so good from the outset, but had proved so catastrophically lacking in the robustness needed for real-world use.

To cut a long story short, the answer to the security issues seemed to be a purely file-based approach, and to the relearn-it-all-over-again template timewaster issue, to use industry standard languages such as html and javascript instead of idiosyncratic markup. Unfortunately the file-based CMS then available all used nonstandard content markup, which to me, ruled them out.

Mara cms is the result of several years of ongoing work on producing our own inhouse frontend. Over time and a couple of name changes , it's grown from a very basic php page-loader script to a package which includes all of the features most often needed in the typical small to medium business website.

The design principles are, naturally, based on our previous experiences with other packages, and try to promote what we would consider to be desirable properties of a good CMS framework. It is quite correctly said that there is no substitute for experience, and negative experiences are an important part of understanding why things should NOT be done in certain ways, ways which might seem attractive and highly standards compliant, but which harbour a number of lurking gotchas.  So, to list a few things we've learned to avoid:

SQL databases, because of their infamously weak security. Not that we've anything against databases in principle. I used to code xBase apps for a previous employer. We'd love to use a database, but few webservers provide any that are not SQL-based, and we need our CMS to be widely compatible with hosting company offerings. It's SQL that's the no-no. So in practice that means no database.

Nonstandard markup languages, for the same reason no-one makes round billiard tables.

Deeply nested OOP programming. -For the same reasons that nested HTML tables are bad practice, but also because it is effectively a form of code obfuscation that makes it hard for the less-experienced programmer to understand and customise your work. (Possibly in some cases the intention, I say cynically.)

Excessive use of code libraries. -In some cases code libraries can save a lot of work, but the problem is that they are typically a very inefficient way of providing just one or two features which on their own could be expressed in perhaps a hundredth the size of the library. The problems manifest themselves when multiple libraries are loaded for the sake of only a handful of their numerous features. Therefore, better to write fresh code than to load a large library for just one of its components, the rest unused and only serving to bloat the product into slowness. 

OK, that's the negative out of the way. On the design principles page you can see how we have implemented our ideas of how a CMS should work.

Powered by Mara cms