Here's the complete text of the entry you were just reading. To return to the whole blog, click thebutton at left.
Other than uploading plugin updates, I hadn't touched the site in almost a year; not too much bitrot, but a fair amount of cruft. No fixed abode has too often meant no modern Mac — making it increasingly difficult to test plugins with the site's hacked blosxom. So the first order of business was to convert the blog sections over to stock blosxom:
- configure and install a clean blosxom
- add entries_cache plugin to fake file modification times
- hack entries_cache to do what it should ;-)
- process entry files to proper blosxom format:
- title on first line (was date)
- mod time meta- tag on second line (was title)
- blank third line to conform to meta plugin standard (unneeded, but standard)
- modify story templates to use blosxom's
$yrvars (was my hacked $dato)
.dltemplates to mimic the old name-based hack
- write a
fulldatenamesplugin to get full month names
- fiddle with load order
It was all quite tedious, but I just kept tellin' myself, "This makes it easier. This makes it easier. This makes it...." Geez, this better make it easier! ;-)
It's amazing how much work was involved to replace the functionality of what was essentially a one-line hack to blosxom.
I had wanted to sort entries by name, not date, and I'd wanted to be able to control the date that each entry showed. To do this, I added one line to blosxom that read a line from the entry file into a var named
$dato, and then whipped up a plugin to sort by name; naming files by "date" –
040812.txt– took care of the rest.
Oh, there were a few other changes...declare the var, modify the built-in flavour bits, and add $dato to all the story templates, but the essence was just that one line that read in $dato.
On balance, it's more work to do it the "legitimate" way. I still have to add a line to entries to supply a date, and that line (
meta-creation_date: 08-12-04) is less-than-natural language. There are more variables to call in flavour templates, and it takes a plugin to give names to months. And, I have to remember to re-cache the entry files every time a new entry is uploaded.
Still, the big advantage is that I can now test plugins from the site, without contra-hacking the hacks, so it's all worth it (of course!).
(HyperCard to the rescue once again — figuring out what to edit took about an hour; coding HC took about 10 minutes; testing took about 5 minutes; editing about 100 files took less than a minute! What in the world was Apple thinking when it dropped HyperCard?)
I know it doesn't make much sense to think this way, but I don't like the idea of being dependent on entries_cache and a cache file; next project, I think, is a GUI-ized script to "touch" all the data files....
With blosxom running on an even keel, the next step was to get the HTML on a more-solid footing. These pages are mainly a testbed, and Waldo's templates had grown messy from late-night hacks and hurried uploads. With Mozilla, Safari, and Opera now providing adequate compliance, documentation clients could be safely moved away from Explorer, and Waldo could pursue the grail of separating content from structure.
Since documentation work doesn't really need a third column, the HTMl work turned out to be quite simple. The nuts'n'bolts are like this—
Two columns, set up as:
BODY #linkbar #textlogo - textual link to home, - OR - #logo - graphic link to home #linklist - text links to pages /linkbar #content_area #content - page content /content_area #footer -copyright, mail form link /BODY
Home link and navigation usually float to the left; content fills the main column. Very low bandwidth requirements (graphics-free at best), yet still easy to "brand" for each shop. For the rare job that requires a third column, adding two simple DIVs gets the job done.
A few .htaccess files and a wee bit of mod-rewrite to handle 404s and errors, and it's all cleaned up for another couple of years. Well, that and bringing it live... ;-)