One the first plugins I decided to use for this weblog was wikieditish, a fantastic plugin by Rael Dornfest, author of Blosxom. This plugin allows the posting and editing of blog entrys via a web page. Among its features are password protection and modification date preservation.
Date preservation is important, because Blosxom uses a story’s file-system modification time as the posting time of the story. However, when I started using it, new posts created by wikieditish all had a date of Dec 31, 1969 at 16:00. A search of the Blosxom mailing list found a description of the problem, but not the solution.
Eventually, I worked it out. The problem is caused when $preserve_lastmodified is set. In the following code, the comment says something the code does not:
# If file already exists, memorize the lastmodified date/time
my $mtime = (stat "$blosxom::datadir$path/$fn.$file_extension")[9];
There is no If in the code – when the file does not exist, the stat call returns no value. So when $mtime is used later, its numeric value is 0:
# reset lastmodified date/time to memorized value (if possible)
$preserve_lastmodified
and utime(time, $mtime, "$blosxom::datadir$path/$fn.$file_extension")
? $response .= " Preserved last modified date/time."
: warn "blosxom : wikieditish plugin : couldn't reset lastmodified
time on $blosxom::datadir$path/$fn.$file_extension.";
utime expects a date/time value as seconds since the epoch. The epoch is Jan 1, 1970, 00:00 GMT. Those of us west of GMT see this as a time during the evening of Dec 31, 1969. In my case, 16:00, which is 8 hours prior to midnight, which tells me my host in on Pacific time.
My fix for this is brief. In the above code, we don’t proceed if $mtime is 0:
# reset lastmodified date/time to memorized value (if possible)
$preserve_lastmodified
and $mtime
and utime(time, $mtime, "$blosxom::datadir$path/$fn.$file_extension")
? $response .= " Preserved last modified date/time."
: warn "blosxom : wikieditish plugin : couldn't
reset lastmodified time on
$blosxom::datadir$path/$fn.$file_extension.";
Its possible some people don’t have this problem with the code as written. Judging from the code, I think perhaps utime is expected to fail with a 0 arg. Since utime is just a wrapper for utime(2) on most systems, this could be a difference between *nix implementations… but that’s all theory :) The code fix however is actually tested.
According to the Xalan-j homepage, Xalan-J 1 is no longer supported. Unfortunately, I’m still using it, at least for the time being. These two realities colided a couple days ago when I ran into a problem with the following (filenames have been changed to protect the innocent):
java org.apache.xalan.xslt.Process -IN /path/datafile.xml -XSL /path/template.xslt -OUT /path/output.xml -PARAM base_currency_iso 'EUR'
Despite the deceptive simplicity of the above, the output indicated a problem with the parameter value. Adding a element to the key template proved the point:
$ISO=EUR, $base_currency_iso=
$ISO=CHF, $base_currency_iso=
$ISO=DKK, $base_currency_iso=
$ISO=EUR, $base_currency_iso=
(snip...)
My parameter value was not making it into the process. Making the ‘no longer supported’ issue even more fun is the fact that Xalan-j 2 no longer requires the single quotes around string values. I tried with single quotes, without; I googled and groups.googled; I kept coming up dry.
Of course, those of you in the audience whose Unix skills are better than mine have already seen the issue… the shell was handling the single-quotes. The answer was stunningly simple:
java org.apache.xalan.xslt.Process -IN /path/datafile.xml -XSL /path/template.xslt -OUT /path/output.xml -PARAM base_currency_iso "'EUR'"
The funny thing is, I never saw any example that showed the extra double quotes. An hour wasted, but not a true waste… I’ll bet that in the future I’ll be more quote-savvy in when working in Unix. And now I’ve documented it, so at least for a brief moment, Xalan-j 1 is once again supported… just not by Apache.
It has taken longer than I anticipated (as does every project), but this weblog is underway. In this category I will document what goes into the creation, maintenance and growth of this site.
Although getting to this point has taken longer than I expected, it has still not taken very long. Although it has been nearly a week and I have only a couple of posts and a very meager layout, I have only been able to devote an hour or two here and there. Above all, the process has been educational.
There have been two sources of delay. The first is minor, and is a just a matter of bad timing. I began setting up this site using Blosxom 2.0 Beta RC5, which I thought was current. Several hours later, I learned that Blosxom 2.0 final had been released, along with a new website. I don’t know if I had followed an out of date link, or if the old site was not redirecting to the new site (which it does now). When I did learn of my mistake, I decided to replace blosxom.cgi and all of my plugins with new versions from the new site. Unfortunately, the plugin registry on the new site links to outdated versions of several plugins. More time lost, but more knowledge gained; I’ll call it an even trade. Perhaps this was just a case of growing pains.
The other source of delay has been a much bigger problem. The hosting firm I am using, iPowerWeb, does not offer shell access. I have used them previously, and found the provided web-based admin site they provide to be adequate. However, they have recently introduced a new admin interface, with which I have not fared as well. Again, I seem to be the victim of growing pains. The issue is that many of the functions (e.g. chmod, file rename, file delete) are implemented with client side javascript, which appears to contain bugs. The code will not run in Safari 1.0 or IE5.5/Mac. It does, of course work in IE/Win. So, much computer-hopping has been required. iPowerWeb support has escalated the issue to the development staff, and claim that they are working on it. In the meanwhile, they suggest using Mozilla Firebird. Perhaps I’ll try it.
But there is another issue with iPowerWeb’s admin interface, which I have not yet sent to support. The provided editor uses CR/LF for newlines, but my host runs Unix (i386-FreeBSD). The perl interpreter does not like finding s in perl code; it has also caused textile -encoded posts to render without formatting . For now, my solution has been to find a decent (well, half decent) ftp client (review to come later), and to do my script editing locally, and my post editing via wikieditish. Even my early attempts with wikieditish had s. I’m guessing this is because the HTTP spec mandates the use of CR/LFs, which in turn would cause CR/LFs to appear in textareas. One of these days I’ll research further, for now I’ll work around.
Having successfully passed these hurdles, I have begun posting to the weblog. In future posts I’ll detail where I hope to go from here.
or, I’ve Buttered My Bread and Now I Have to Lay in it.
I did not intend for my second post to be a rant. I won’t let that stop me.
Although I work primarily on a Mac in my spare time, my work machine is a Windows box. I also several at home, with three currently in service. In both locations I use a Microsoft 5-button optical mouse. I use the comfortable beige one, not that awful grey one with all the ergonomics of a rock. Just as with the scroll wheel before it, the five button has become something I am keenly aware of missing when it’s not present. I don’t even use all five… it’s the thumb button that makes this mouse special to me. It is wired by default to Internet Explorer’s Back button. I can’t express how much I love not having to drag my mouse to the toolbar every time I want to back up. Sheer Genius, as I have extolled to many.
And so it was a cruel twist indeed today, when my beloved thumb button stabbed me in the back. I was entering a post for this blog into a webpage (via wikieditish. I had been at this for a good 10 minutes, and was nearly done. It was then, for reasons I can not quite recall, I casually tried to nudge my mouse away from my keyboard an inch or so. And (you saw this coming) hit the thumb button. Back, Browser!
Oops. Goodbye post. I did try (in vain) to use the Forward button from the menu bar to return, but the form was cleared, the work lost.
Why is it that those we love the most hurt us the most?
I am Jason Clark, and this is the weblog at jclark.org. Welcome.
I am a software developer by trade – and by inclination. This weblog will be my attempt to learn more about the technologies of the web, and to document what I learn.
I have several initial goals. The first is to learn Blosxom, the blogging software which powers this site. I intend to document how the site is put together as I proceed. My next goal is to better learn CSS by evolving the design of this site. Hopefully this will proceed quickly, for the current look can surely use the help. At certain milestones in the site design (as I see fit), I intend to ‘archive’ the site design by copying the current Blosxom flavor and CSS stylesheets to keep for future reference. With luck, this will be instructive.
My final goal is to document the little tidbits of useful knowledge that always seem to be forgotten when later needed. These may be bugfixes, workarounds, or clever hacks for any product or technology I come in contact with. Hopefully they will help others as they help me.
In between all of this, I’ll try to comment on whatever else comes along. This is my first attempt at ongoing writing, and that may be the biggest learning experience of all. Committing thought to text requires more thought than just thinking. Or something like that.