Mara CMS performs a similar core function to 'Content management systems' such as Joomla!, Drupal or Wordpress, - although it differs in many fundamental aspects from those packages. Probably the most significant difference is its being file based instead of database dependent.

Probably the most notable difference is that being a flat-file CMS, content is stored as conventional HTML webpages rather than in an SQL database. This arrangement was chosen primarily for security, since it eliminates the issue of SQL code injection, which is at the root of the vast majority of CMS-based website hackings. It has other advantages, notably that it is very easy to import existing static webpages into a Mara site.

A further innovation is the use of what we term reflex page loading, instead of the parametric URLs favoured by most CMS. With reflex loading, the URL you see in the browser bar is the actual location of the page you are viewing, just as if it were a non-CMS static page. This makes things tidy and simple, both for site visitors wanting to quote the location of a page, and just as importantly, for searchengines trying to rank your site.

As a brief outline of its design principles:

  • Host requirements are recent versions of Apache and php

  • Pages are stored as conventional HTML files, as opposed to in an SQL database

  • Pages are loaded by native URL, instead of an untidy parameter-string or confusing URL rewrite

  • A reliable and substantially quirk-free online editor, plus the ability to upload pages the traditional way

  • Configuration is by way of text files rather than browser dialogs

  • Common styles and elements are stored in a theme, which is highly customisable

  • Menus are cascading, independent of page location, and do not require page refresh to show sublevels

  • Page loading should be near-instant, and should not involve 'shuggling' of content as it loads

  • Mara websites should be location-agnostic, and easily relocatable to a new domain

  • A site can use HTML5 or HTML4 as desired (and the editor semantics adjust accordingly)

  • Disasters should be rare, but always be recoverable by simply replacing the affected files

  • System programming should be understandable by a coder of average ability

  • Your site should not 'look like a Mara site' or even be identifiable as one unless you wish it

  • Near-complete flexibility to modify the system itself, if existing controls don't meet your needs

  • Simplest method that does the job satisfactorily, is best