History

The name Archimedes is new, however Archimedes is the 5th major iteration of a content management system dating back to 2002.
A time in which WordPress didn’t even exist.

CMS 0 – 2002

CMS0 was the prequel to CMS1 in 2002.

It allowed the import of .DBF files from the POS system for a computer store.
It displayed the products on the site.
It was possible to see very crude visitor stats (this was before Google Analytics even existed).

But it was not possible to change any other content.
You could log in, but that was it.
It was my our very first project in PHP 3.

CMS 0.5 – 2002/2003

I did an internship at a company that built websites.
For that company I build the website of the computer store I worked as a weekend job.

This was an entire website with CMS, but built in MS ASP and Access (yes, the old ASP, not ASP.net) and MS Webserver.

CMS 1 – 2003

The ASP code from CMS0.5 belonged to the company I did an internship for.
With the things I learned from CMS0.5, I created CMS1, but in PHP to use on my own websites.

CMS 1 stored data with MySQL (which didn’t even support foreign keys at the time).
Some code of CMS1 is still present in some libraries of CMS5.
CMS 1 used standard centralised function libraries.

The system was able to manage texts on sites.
CMS1 was used for my company in POS systems (programmed in Delphi b.t.w.)
CMS1 was a major milestone and foundation for what was to come…

CMS 2 – 2004

CMS 2 is the follow-up of CMS1.
CMS2 is basically CMS1 but with one key difference: plug and play modules (if you didn’t count the database).
Copy module files into the module directory and you where done. (if you didn’t count the database).

I used CMS2 for 20 years, it was that good and that freakin’ fast.
I used to power the sites of my event company and even later my blogs that supported my YouTube channel.

CMS 2 was completely procedural PHP, instead of object oriented.
The development was slow, especially modules with a lot of form elements.

CMS 2.5

In 2003/2004 I did another internship with a company that builds websites, but this time with PHP.
Here I developed the ultimate CMS, which was more a webapplication framework used for CRM.
It could do a wider range of things than just manage websites.

Some innovations:

• an application framework instead of a CMS
• object oriented php
• plugin module system
• multi lingual
• multiple function libraries (lib_inet, lib_string etc instead of only lib_std & lib_cust )
• separation of Model, View, Controller
• URL router
• connecting to database with objects
• template engine with Smarty

In hindsight, the framework was good, but way too slow.
It did way too many database requests for example.

The source code belonged to the company, so I couldn’t use it.
In hindsight: they ditched the framework after a couple of years, so it wouldn’t have been a big problem to use it.

CMS 3 – 2010

From everything that I learned about developing the CRM1 (CMS2.5), I wanted to create the ultimate web application.
But I wanted to do it better.
I could start from 0 and leave all the mistakes from CRM1 behind me.

Innovations:

• clear model/view/controller separation
• controller objects
• simple but powerful template engine
• increased security
• URL router
• connect to database with objects
• SQL builder to allow database independent querying (whether it is MS Access or Mysql, the code is the same)
• database field names are dynamically defined with constants
• database knows its own fields/field-types and can create and update database tables, which allows for easier database refactoring.
• Multi website management
• authentication system (switching on and off permissions based on user roles)
• form generation and HTML DOM elements (with support for form errors)
• building menus dynamically
• caching functionality is standard integrated in controllers, just enable it with 1 line of code
• cronjob.php executes regular maintenance tasks

A lot of these ideas were implemented before WordPress and PHP frameworks were even a thing.

Slowness

A website was an application, so I thought, and I approached it as such (a decision that still hunts me in my darkest nightmares).
PHP is not a compiled language, thus very slow with object oriented programming.

I took the Java approach: everything was an object!
I asked everything I wanted to know from the TApplication object for example.
Every object used TObject as a parent, while the benefits where little.
TObjectlist and TObjectListHash where basically array into an OOP jacket with unnessary overhead.

Needless to say, but CMS3 was slow, not even a little bit.
I started to simplify components, flatten classes, but it was still slow.
It did go the same route as the CRM system developed for my internship company.

Complicated

Another downside arose: the project has become quite complicated and therefore hard to maintain.
It was hard to find stuff: what was where.

For example: for security reasons, it separated the business logic (the framework) from the GUI.
The idea was that you stored the framework in a private directory on the server, out of reach for the website user.
So the framework had it’s own code base, then on top of that, there were 2 websites with their own code bases:

• The CMS was a website and
• the public website itself was a website.

The CMS was meant to run on a subdomain (to prevent bots from adding “/admin” to the url).
The website was meant to run on the “www” subdomain.
The fragmentation of these component was hair-puller to maintain.

From a programmatic and abstraction standpoint, CMS3 was a great project.
But the “application-for-the-web” approach made it weird and awkward to maintain.
It just wasn’t “PHP” enough for a web based approach.

The Bug

What made me eventually quit the project was a very annoying bug.
I’ve spent weeks on end to find it, but couldn’t, even with xdebug.

It was a header redirection bug that was related to the authentication system.
Sometimes it redirected once, sometimes 5, sometimes 3, sometimes 10, sometimes it timed out.
Because I could not find any logical pattern in this behavior, the inconsistency made it impossible to replicate the bug.

Header redirection bugs are insanely hard to debug as you might know.
It drove me crazy.
I was absolutely devastated: by now, I had put years of my life into this project and had nothing to show for.

CMS 4 – 2015

CMS4 was a short-lived project of a couple of weeks.
It was an attempt to salvage all the work that went into CMS3.
I started over by reusing components of CMS3, reprogram them (flatten objects, simplify)

But it did not fix its major speed problems: it was still slow.
To start over, I need to reprogram so much, I had given up at this point.
CMS2 worked for years on my existing sites, it was the only working system I had.

CMS 5 – 2016 – “Archimedes was born”

Then it dawned on me:
“what if I take CMS2 as a basis and start adding components of CMS3 which I know for 100% sure they are fast and do not cause redirection issues.
And slowly I can add more and more components to get the functionality”.
This had the added benefit: that I am 100% compatible with CMS2 (remember that all my websites were running CMS2 at this point), because it is literally a layer on top of CMS2.

CMS3 was not compatible with CMS2.
It worked!

Reused components

• the “lib_” procedural libraries
• database objects
• form generators + HTML DOM elements
• language file handling
• rendering templates

While the system is built from the ground up.
You are still able to find old components dating back to the 2010’s, with some CMS2 code even dating back to 2003.
The legacy code to support CMS 2, I hope to remove some day.

Some focus points for CMS5:

• Speed, speed, speed → faster than wordpress
  • flat classes
  • less database queries
  • no classes where not needed. (the URL router is a perfect example)
• Mobile compatible and response design
• PHP 7/8 compatible.

New components

• very simple url router → by design
• login flood detection and login sessions
• notification system
• form generator with:
  • auto flood detection
  • honeypot to prevent spam
  • CSRF token support
  • ReCaptcha support
• database:
  • support for joining tables
  • support for encrypting and decrypting database fields
• rewritten authentication and authorisation system
  • it supports user accounts: users, user accounts and user roles

Archimedes was born

By now, the project was known mainly as “CMS 5”, or “dragonfly”.
Regretfully the name “dragonfly” was already in use for a CMS.

Until I stumbled upon the name: “Achimedes”, the Greek mathematician and physicist.
At that time, I was in talks with the computer store where I worked years ago about developing a new POS system for them.
For a POS system, you have to calculate the total of an invoice.
So the name “Archimedes” fits this project perfectly.