Extensionless Plugin with Blosxom > 2.0

cng3 wrote:
> I recently moved my Blosxom site from one home server to another home
> (Debian) server using Apache2. After this move, upon upgrading to
> Blosxom 2.0.2, the extensionless plugin did not work. The entry page
> would render (the flavor templates etc.) but the body content was not
> displayed.
<snip&gt;
> Has anyone else experienced any issues with the extensionless plugin
&gt; and Blosxom 2.0.1 or 2.0.2?

I don't have time to complete debugging and fixing this, but I now have
a better idea of what's going on. (I applied the 2.0.2 diffs against 2.0
in order until things broke.)

The problem seems to be due to the fact that invocation of plugins'
filter subroutines moved further down in blosxom.cgi, into the generate
subroutine. The extensionless plugin does its magic in the filter
subroutine, changing $blosxom::path_info to add a flavour extension if
it's not already present. This relies (relied) on the fact that
$path_info isn't used in blosxom.cgi prior to extensionless changing it.
However in 2.0.2 there's a use of $path_info right before the generate
subroutine (and hence extensionless's filter subroutine is called); this
is no doubt what's causing the problem.

What was the reason that invocation of the filter subroutines was moved
from its former location in blosxom.cgi?

Frank

--
Frank Hecker
heckerhecker.org

On Jul 22, 2006, at 12:30 PM, Frank Hecker wrote:

>
> What was the reason that invocation of the filter subroutines was moved
>; from its former location in blosxom.cgi?
>

This was to address a bug in static mode. In the previous incarnation,
the filter stage was only run once, even when static mode is generating
many individual pages. By moving it into the generate routine (along
with a couple other small changes), the filtering runs correctly for
each static page that is generated.

It's unfortunate that this appears to have screwed up extensionless.
Does it seem like something you can work around? Can the work be
pushed earlier into the start stage?

-kevin

Kevin Scaldeferri wrote:
&gt; This was to address a bug in static mode. In the previous incarnation,
> the filter stage was only run once, even when static mode is generating
> many individual pages. By moving it into the generate routine (along
&gt; with a couple other small changes), the filtering runs correctly for
> each static page that is generated.

Ah, got it. Thanks.

> It's unfortunate that this appears to have screwed up extensionless.
> Does it seem like something you can work around? Can the work be
> pushed earlier into the start stage?

I think so. The reason why the current version of extensionless does its
work in the filter stage is because it references %files, so it has to
have the entries subroutine already run, and the filter stage is the
first opportunity after that happens. Basically if the URL supplied to
Blosxom is something like .../foo/bar, extensionless checks in %files to
see if an entry .../foo/bar.txt was found.

The alternative is to do a direct check to see if a readable file
foo/bar.txt exists in the Blosxom data directory; this can be done in
the start stage. I've attached a minimal patch to the extensionless
plugin to implement this change. The patched version appears to work
fine with Blosxom 2.0.2 and my configuration. Others running
extensionless should check this out both with Blosxom 2.0 and 2.0.2 if
possible.

Besides the minimal overhead of going back to the file system to check
for file existence, the one possible problem I see with this change is
that it assumes that the default entry subroutine hasn't been replaced
with one that uses a non-standard way to store Blosxom entry files. For
example, the patched version of extensionless won't work for someone
who's using the svn-backend plugin to pull entries from a Subversion
repository, while previous versions of extensionless would have no
problem with this.

However this (proposed) new version of extensionless should work with
the various plugins that do caching of entry information (e.g.,
entriescache, entries_cache_meta, etc.), as long as they start from a
standard Blosxom data directory. I'm testing with entries_cache_meta and
it appears to work fine.

Moving the work to the start stage also has the advantage of ensuring
that $blosxom::path_info gets fixed up as soon as possible. If
extensionless is the very first plugin run (which I recommend) then no
other plugins should be affected, even if they reference $path_info in
their own start subroutines.

If further testing goes OK I'll push out a new version of the
extensionless plugin with this change. This new version should work with
all versions of Blosxom through 2.0.2.

Frank

--
Frank Hecker
heckerhecker.org