[Note (2020): This website is now run on the WordPress engine. This page describes the previous homebrew wiki-based engine that I wrote some 25 years ago, adapted from the public-domain WakkaWiki project, which ran on a now-deprecated version of PHP. It was a very successful system for its time, with some good features that I’ve never seen replicated elsewhere, but its technology has long been superseded, and the hosting-company’s withdrawal of support for that old version of PHP forced a move to WordPress.
The archive-text below, from 2002, describes the reasoning behind the underlying structure for the xio website of that time.]
As xio‘s ‘webmaster’, it’s my job to maintain the workings of the group’s web-site. Like many other small companies, we’d started off with Microsoft’s FrontPage: but whilst it’s simple to use at first, it’s hopelessly unwieldy with even a medium-sized site. By the time we reached 150 pages of actual content, it was already struggling with almost two thousand additional hidden files and graphics that it had created itself, and couldn’t upload without timing-out at least two or three times a session… a maintenance nightmare…
So we applied our own methodologies to our own web-site requirements:
- what did we want to do?
- what did we already have?
- how did we get here?
- how do we get from here to there?
- how do we stay on track?
We knew that what we really needed was something simple that would manage site-navigation automatically, that would work with any browser, and that would keep bandwidth-usage and general ‘clutter’ to the minimum practicable. We also wanted the option to include dynamic content. But none of the off-the-shelf tools such as Dreamweaver, DrumBeat or NetObjects Fusion seemed to do it at all well; and the large ‘application servers’ such as WebObjects and ColdFusion Spectra were priced way out of reach, and didn’t manage site-navigation anyway. So we settled on writing our own in PHP, a public-domain equivalent of Microsoft’s proprietary server-side scripting language ASP.
We’re pleased with the result: we hope you are too! It’s allowed us to use a single master-script to manage a database-driven navigation system, with multiple virtual sites (some of them with their own public domain-names) all packed within the same overall structure. It’s allowed us some nice features, such as an automatically-generated contents-list and keyword-search, and a number of self-updating lists (mainly for publications, but also for the ‘Toolbox’ on this site). Without FrontPage‘s excess clutter and over-use of graphics, downloads are quick; yet it’s still allowed us a navigation model which automatically shows each page’s ‘location’ within the overall structure, and constructs its own lists of appropriate links for each page. And it’s given us the option to turn any page into a kind of moderated discussion-list, allowing visitors to add their own comments to the content of the page. Yet the pages themselves are just straightforward HTML – unless we want to include some server-side code, which we can now do with any page.
At present our home-made site-maintenance system is a little more awkward to use than that so-desirable drag-and-drop in FrontPage and the like, but it’s a lot simpler than trying to maintain the site by hand (the classic alternative!), and it’s improving all the time. And we’re no longer tied in to another company’s marketing whims – or the random ‘upgrades’ and random bugs of their proprietary code. So ‘doing it your own way’ sometimes seems more expensive at first – particularly in terms of effort rather than up-front cost – but we think that in the long run it’s usually a better way to go.