Mar 2006
So far I had found two blosxom plugins that will generate a menu
from the directory hierarchy. Both work perfectly well in dynamically
generated pages, but when static pages are generated by the blosxom
perl script, the same script is iterating over every single post,
causing these plugins to be called again and again, raising their
counters to astronomic heights.
One fix would be to disable the use of these counters which is
configurable with both plugins, another was to place a locking
variable to avoid duplicate counting of posts.
There may be a more elegant solution, such as calling this kind of
plugins only once instead of once for every post, but I failed to find out
if this is possible.
RSS seems to work now, but since the old default had been to archive by date rather than by filename, the individual files aren’t found. I’m off for about 24 hours, so I’m afraid I won’t be able to fix RSS before then. Everything else should be unaffected
Update: Hope this now works as intended. I’ll have to sort out how to handle the level of detail put into the feed - advocates I’ve seen range from “headlines only” to “full content”. I’ll also have to test if articles evolving from my backlog in non-chronological order will confuse aggregators.
Update #2: New weirdness - duplicate entries in the feed for feed and “normal” version of individual articles. Mergel.
The default configuration of the Markdown plugin interprets semicapitalized spelling as “WikiWords”, and tries to link to Wiki pages that didn’t exist. This broke Links to OpenSolaris.org and others. Struggling to disable.
The first “fix” was to “cheat” and redirect those Wikilinks to Wikipedia. The article on OpenSolaris there is well worth reading, and certainly a better user experience than a “page not found” error.
I don’t understand the Meta-Markdown script too well yet. There’s a set of variables that seems to be supposed to control if semicapitalized words get parsed as wiki links. All my tweaking has been to no avail though:
# For use with WikiWords and [[Wiki Links]] $g_use_wiki_links = 0; $g_base_url = "http://en.wikipedia.org/wiki/"; # base url for WikiLinks my $g_temp_no_wikiwords = 1;
This did work for some articles, but not for others. - may be yet another problem with static page generation?
Somewhere else in the file it reads:
# Can now process Wiki Links again $g_temp_no_wikiwords = 0;
Setting this to 1 stopped those WikiLinks from popping up, but that really didn’t look like what the programmer intended. Digging a bit deeper, I found out that the variable “Use WikiLinks: true” in the header of one article activated the whole thing for all subsequent articles, even if they explicitely disabled that setting in their own header.
Most of the text on the temporary page has been converted to blosxom,
which makes writing content a fast and easy process to the user (me).
As with most
systems, it took me a while and a handful of examples to understand
how to configure it. There’s a backlog of notes from CeBIT and
Events held by Sun in Berlin which I’ll be adding during the next
days, and also, the long awaited Contents pages of the book (in
German, I’m afraid) should be downloadable soon.
Oops. I just
noticed that statically generated pages have a few counters running
weird, as can be observed in the menu to the left where accumulation
leads to an unpredicted boost in article statistics.