Item10237: Incorrect parsing of bracketed topic names in WebOrder

The parsing of bracketed topic names in WebOrder is too simplistic, and doesn't track how topic names are currently handled in Foswiki::UI::Render::internalLink, which is the only place I could find which actually specifies what should happen.

For example, TocPlugin cannot handle this topic name:

[[Grating CC-F Mode]]

The routines which deal with this are TocPlugin::Section::_toWikiName and TocPlugin::Section::_expandOddLink.

The first problem is that the code which recognizes and processes the links (at line 631) below, only accepts word and space characters:

    626 sub _toWikiName {
    627     my $t  = shift;
    628     $t =~ s/^[\s*]*//o;
    629     $t =~ s/[\s*]*$//o;
    630     # expand [[odd link]]
    631     $t =~ s/\[\[([\w\s]+)\]\]/_expandOddLink($1)/eo;
    632     return $t;
    633 }

I've looked at other bits of the Foswiki code base, and come up with the following replacement which seems to track what other code is doing.

    631     $t =~ s/\[\[(.+)\]\]/_expandOddLink($1)/eo;

(There's lots of duplicated code dealing with [[][]] style links. Shouldn't this all be in a single place?)

Now for _expandOddLink:

    637 sub _expandOddLink {
    638     my( $topic ) = @_;
    639     
    640     # kill spaces and Wikify topic name
    641     $topic =~ s/^\s*//o;
    642     $topic =~ s/\s*$//o;
    643     $topic =~ s/^(.)/\U$1/o;
    644     $topic =~ s/\s([a-zA-Z0-9])/\U$1/go;
    645     return $topic;
    646 }

It doesn't have the sophistication of the code in UI::Render::internalLink(), so I copied that over:

    637 sub _expandOddLink {
    638     my( $topic ) = @_;
    639     
    640     # kill spaces and Wikify topic name. Taken from Foswiki::UI::Render::internalLink()
    641     $topic =~ s/^\s*//o;
    642     $topic =~ s/\s*$//o;
    643     $topic = ucfirst $topic;
    644     $topic =~ s/\s([$Foswiki::regex{mixedAlphaNum}])/\U$1/go;
    645     $topic = Foswiki::Sandbox::untaintUnchecked($topic);
    646 
    647     return $topic;
    648 }

Again, it seems that perhaps this should be exposed as part of the Core API.

I should note that this code doesn't do anything with the {NameFilter} configuration parameter. Should it?

I've attached a patch against $Rev: 5851 (2009-12-22) $

-- DiabJerius - 10 Jan 2011

Parsing now uses the BookmakerPlugin, which uses code taken from the core renderer.

-- CrawfordCurrie - 24 Mar 2011

Commenting is disabled while not logged in