WikiPatches/ExtendedSearchSyntax

I have been experimenting with using wikis for informal bug tracking. Its relatively easy to use categories to classify which projects bugs belong to, and even to assign priorities, but I found that it was more difficult to track dependancies and do things like "find all open bugs". This lead me to extend the syntax of my own customized wiki, so that I could make links that perform searches for strings like "BugStatus open". Since then, I have been using UseModWiki to create a wiki farm for work. I decided to try to rationalise the search syntax and patch UseModWiki to use it.

This patch extends the wiki syntax to allow the formation of links that perform arbitrary searches, using the standard search method. Please note that it has not been tested in anger.

-- DavidMcNicol

See also

/TemplatePages

Syntax

The extended search syntax looks like this:

{? search term | optional text }

In its simplest form, you can make a link to search for "foo" like so:

{? foo }

If you want to name the link differently, you can add some arbitrary text after a vertical bar, like so:

{? foo | bar }

This will make a link to search for "foo", which will appear on the page as "bar". Here is a more concrete example:

{? BugStatus open | find all open bugs }

Code

My UseModWiki source code already has several patches applied, so supplying diffs does not make much sense. However I have tried to keep the code as separate as possible. You should be able to add these three parts to the relevant sections of your code with the minimum of fuss.

Configuration section

This bit should be added at the at the end of the configuration section, just before the "you should not have to change anything below this line" comment.

# == SearchLinks patch ===================================================
use vars qw( $SearchLinks );
$SearchLinks = 1;       # 1 = allow search link syntax, 0 = don't
# ========================================================================

The subroutines

The GetExtendedSearchLink subroutine takes an arbitrary search term, encodes it using the CGI module, then makes a link using the standard ScriptLink subroutine.

It should be added after the GetSearchLink subroutine for the sake of consistency.

# == SearchLinks patch ===================================================
sub GetExtendedSearchLink {

  my $term = shift;
  my $text = shift;

  my $cgi = new CGI("");
  $cgi->param("search", $term);
  my $qstring = $cgi->query_string();

  return &ScriptLink( $qstring, $text || $term );
}
# ========================================================================

The StoreSearchLink subroutine is used to perform the actual substitution. I placed it before the StorePageOrEditLink subroutine.

# == SearchLinks patch ===================================================
sub StoreSearchLink {

  my $term = shift;
  my $text = shift;

  return &StoreRaw(&GetExtendedSearchLink($term, $text));
}
# ========================================================================

Substitution code

This code uses the StoreSearchLink subroutine to perform the substitution on any matching syntax, as long as the $SearchLinks variable is set:

# == SearchLinks patch ===================================================
    if ( $SearchLinks ) {
      s/\{\?\s*([^\|]*?)\s*(\|\s*(.*?)\s*)?\}/&StoreSearchLink($1,$3)/geo;
    }
# ========================================================================

This is the most sensitive piece of code, in terms of placement. It should go into the CommonMarkup subroutine, before the code which deals with FreeLinks - that's the if-statement which starts:

if ($FreeLinks) {
  ...
}

It may work if its added elsewhere, but I haven't tested that. The important thing is that the substitution takes place before any of the $LinkPattern based substitutions.