Under the FAQ bonnet
There is more to maintaining a detailed FAQ than dumping a bunch of text online.
So for all you geeks and script-jockeys out there, the following is a brief discussion of the different coding strategies used in this project.
Towards the end of 2004, the HTML code on this site was slowly re-written to use modern XHTML and Web Standards (W3C) methodology.
There are many advantages to doing this, but one which interests us most is "accessibility conformance". Since many visitors to this FAQ are… erm… older people with failing eyesight, having fully compliant pages means people can easily change the font-size to suit their needs.
Most importantly, XHTML is more future-proof & also lets us use fancy CSS effects for page layout and the nav buttons at the top of each page :?)
Most web-coders use Server Side Includes. Here I use them with a twist, in that their content adapts itself to the content of the HTML page into which they are embedded.
So here they are used to generate individually customised TITLE tags, filepaths & mod-dates for each page within a standard header. On other projects I have used Active SSIs to read cookies and then switch on or off CSS includes, or indeed enable or disable entire blocks of HTML text.
The beauty of this approach is that the PHP and HTML code is kept completely separate: say goodbye to incomprehensible spaghetti-tangles where PHP is randomly dispersed throughout the HTML!
Needless to say, this approach makes it much easier to maintain HTML & scripts and keep the bugs down.
I grew sick of spammer web-bots harvesting people's email addresses, so in Q1 2004 I wrote a custom "Whos-Who" script, which Blocks These Bastards Forever. Details are now stored in secure MySQL tables, which can only be accessed by the FAQ.
The actual FAQ content is still kept in separate HTML files, mainly for portability and maintenance reasons. Plain text HTML files can be easily moved around, globally altered, chopped or copied onto different servers without hassle. Doing MySQL dumps and reloads can also get tricky if your MySQL versions are out of sync. Then having to do MySQL updates just to fix a link or typo is a PITA!
High speed XML parsing
Before moving the XML "Whos-who" and "Hits-metrics" stuff to MySQL, it used to be based on a XML object-oriented parser I wrote to work around PHP Expat's limitations.
Although the parser isn't needed for the FAQ anymore, I still use a portion of it to crunch the FAQ RSS file. Forty lines of code (including comments), a couple of nested regexps, and the whole thing runs with blinding speed and no overhead. C.f. the "traditional" way of parsing RSS!
Continuing the anti-spoofing theme, all binary content (jpeg, zip, pdf etc.) is htaccess locked. As are the PHP includes (to stop smarties from reading them and flinching the code). Yes I know some hackers can fake referrers, but don't imagine ref-checking is the only security feature I use :?)
From June 2004 onward, you will find a panel containing "specifically targeted" Google Ads discreetly tucked away at the bottom of each page.
A lot of other sites use Google advertising of course, but IMO it can be really overbearing. One site I regularly visit has ads along the top, down both sides and - in case you missed 'em - along the bottom as well. If that wasn't enough, the ads all have the "flash enabled" flag set, resulting in a winking, twitching, squirming mess. Yeech.
I get a (tiny) payment every time a user clicks on one of these things. It isn't much of course, but it's enough to pay my server hosting costs. Remains to be seen what effect Adblock (and the like) will have on the income stream…