Website Relaunch

  • March 01, 2015

... The previous website created in 2011 was already version 2.0 using Joomla as the content managament system. There was nothing responsive about the page and it looked and reacted as pretty much all pages in the 90s of the last century. Technically, there was no need to update except for the Joomla installation and the design.

As my provider was going to update PHP to a new version which may impact my Joomla installation the question was: do we upgrade or go back to static pages?

The only reason for using Joomla was to have a common template for pages to work with and not having to deal with making sure the same navigation bar and footer is used for all pages. Creating links is no big deal and as long as the menu stays unchanged the only thing missing was the templating stuff and a responsive layout. My experience with installing Joomla was several days needed to get it to work and at least one failed try in creating a web page. Writing html is no big deal and there was no real need for a full content management system.

The layout was quickly found at Wrap Bootstrap and a license purchased. The example code for our choice, the Highland Theme was very nicely structured anyways so how hard could it be to implent a templating mechanism to generate our web page?

It turns out it is not difficult at all and takes about 3 hours using Java and could be easily reproduce in any other language providing functions to read text files and replace strings in strings. Ideally there is support for json parsing as well for additional configurations. The code was ready in about 30 minutes, most of the time was spent trying out different ways to generate the pages, deciding how to define the output and fixing bugs in the html.

Starting point was the index html file which was split into a header, navigation, content and footer part. Each of them ends up in a single html file and an additional html file defining how to tie the parts together. Each page is described in a single json file which is needed to define the target location as I am putting the templates in a subfolder. The json also defines the content for each element on the page so which content to use for the header, the navigation bar, ...

As the header, navigation and footer part are the same for all pages anyways these could be left out of the configuration and a standard used instead. Same for the target location as the output file name is normally the same as the name for the json files, just one level up in the folder hierarchy. This leaves only one tag in the file defining which file to use as content source. If you define the content file name is always the same as the definition file name plus a prefix you can leave this out of the configuration for all standard pages as well. At this point the configuration becomes empty as everything is defined by the file name and a bunch of conventions.

The drawback of this scheme is you add an additional compilation step between writing your page and looking at the results. On the other hand you can control the output more directly and there is no need for databases and the content is just a bunch of static pages which can be easily cached on the web server.

The additional benefit here is how easy it now becomes tracking the web site content using something like Mercurial or Git. This gives you version control and easy ways to create backups. Updating the page on the server is just uploading the new or updated files and deleting anything obsolete.

The effort to switch to a new website was not quite zero but the end result looks much better than the old version and uses a responsive design making the page work and look better on small screens. Editing the pages in Notepad++ seems a bit old-school but the additional control over the results is well worth it.