and why we wrote our own site frontend
After having client sites built with a traditional CMS repeatedly broken-into by hackers, we decided to look for something better.
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.
After a while some sites started to get hacked, and we found that we needed to update the CMS itself to close the vulnerabilities being exploited. Issue was, the new versions had been changed so much that the templates we had so painstakingly built for our clients' sites just wouldn't work with them. 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.
Furthermore, when we asked-around as to what value-added features of the CMS were regularly used by these clients, the answer was.. Zero. None. They said that the online editing functions were so bewilderingly complex that no-one dared try to use them for fear of breaking something. As for the multitude of plugins, these were business sites, and as far as special features goes such sites might typically need a contact form, and possibly a forum, but the rest of these gadgets served little purpose. The siteowners just wanted a straightforward and attractive presentation of their products.
If that were not enough, the most popular CMS products have become steadily more and more bloated with unneeded features, and this leads to sluggish performance even on fast servers. Speed of page loading is one of those subsconsciously satisfying factors which make one website stand-out from its rivals, and given other factors being equal, a customer is likely to opt for the product on the fast-loading site as opposed to the sluggish one.
It became apparent that using a heavyweight, database-backed CMS to construct typical small business or personal websites is almost all pain, for very little gain.
This situation got us to thinking that (a) we don't actually need a hugely feature-rich frontend system where standard business websites are concerned, a straightforward one might actually do the job better. And, (b) that since the most popular existing CMS packages store content in an SQL database, all of these are intrinsically vulnerable to code-injection hacks. The only way to properly eliminate the code-injection risk is to stop using SQL. The way out of this security impasse is to use a file-based CMS.
At this point you may ask, if CMS features are unneeded, why not just use static webpages? To explain why that is a none-too-good option, we need to appreciate one or two of the shortcomings of the HTML language in which webpages are coded. Probably the most serious of these shortcomings is that HTML provides no straightforward way of placing a navigation menu on a page. Likewise, it does not provide any easy way of adding banners, sidebars or footers, at least not without having to hand-modify each page. CMS systems do provide these functions, and in fact these are the only features of a CMS which are typically required for a business Web-presence.
So, faced with this Hobson's choice if we stuck to mainstream products, we decided to have a try at coding our own. The most fundamental design choice was that for security reasons, pages should not be stored in a database. The project has since grown over three-or-so years from humble beginnings as a bespoke utility purely for our own site, into the makings of a distributable product.
-Why the '!CMS' tag?
Some content management systems have an exclamation mark as the last character of of their name or trademark. An exclamation mark placed before a term, however, indicates 'NOT' in many programming languages. Here, the exclamation mark denotes that Hyperframe is not a traditional CMS, in the sense that it does not store its content in a database.