Development discussion for FindElsewherePlugin

Concept originated at TopicNotFoundInThisWeb.

-- MikeBarton - 31 Jan 2002

Uploaded new version (Cairo+Dakar compat), synced with SVN (TWiki4 branch) - thanks for your work, ScottHunter! Old discussion moved to FindElsewherePluginDevArchive.

-- SteffenPoulsen - 20 Apr 2006

There is a big problem with this plugin - at least in Dakar.

If you use ACRONYMs in headlines, the TOC links to these headlines are wrong and do not work.

It may not only be ACRONYM type links that has this problem. But for the moment this is what we use it for.

-- KennethLavrsen - 02 Jun 2006

Please consider adding the use strict; pragma to this plugin. Its use is important to ensuring the quality of TWiki plugins and avoiding unpleasant surprises. See UseStrict for more.

-- MeredithLesly - 02 Jul 2006

I love the plugin - I'm using it as a Glossary for our TWiki installation.

One of my users loves colour and prefers using the WYSIWYG editor. He has therefore written "DefinedTerm" and caused it to be purple using the WYSIWYG editor; after autolink the raw view looks like

 <font color="#4b0082">text text text </font>[[DefinedTerm][<font color="#4b0082">DefinedTerm</font>]] <font color="#4b0082">text text text</font>

i.e. the font tags turn off and on for the surrounding text and there is an additional font tag for the linked text.

The upshot is that "DefinedTerm" doesn't show up a link to the Glossary web, instead it shows up as a NewUndefinedTopic link. And it's not purple.

That is, text text text DefinedTerm text text text

Is the FindElsewherePlugin comfused by the font tags?

-- DianeSexton - 11 Oct 2006

The plugin won't interfer with anything that's absolutely linked up (in double square brackets).

Perhaps the plugin should have its own CSS class for the links it creates instead, or a way to interact with i.e. LinkOptionsPlugin could be thought of?

-- SteffenPoulsen - 11 Oct 2006

I understand the double square brackets problem - I can't guarantee that my user didn't add them himself so I have manually fixed the link by removing all the weirdo font markups and double square brackets - I won't blame the Plugin for what may have been user screw-up.

-- DianeSexton - 12 Oct 2006

Hi there!

This plugin is quite useful, but I would like to be able to use the double square brackets for my links.

Is there anyway I can change the plugin to include double square bracket links as well?

-- DuncanKinnear - 28 Dec 2006

An idea for increasing the usefulness of this plugin... Provide the "multiple hits" links even for WikiWords with matches in the current web. For instance...

I have a topic named Main.MissionOperationsDirectorate. I also have a topic named Main.MOD that %REDIRECTS% to Main.MissionOperationsDirectorate. I have a third topic named Acronym.MOD that simply spells out what "MOD" is short for.

I'd like for every instance of "MOD" in the Main web to be rendered as MOD^(Acronym), where the "MOD" part links to the Main.MOD topic and the "^Acronym" part links to the Acronym.MOD topic. (If the instance is found in the Acronym web, the text should be rendered as MOD^(Main) with appropriate linkages.) This will keep the "larger" link pointed to the current web, but still display the other options.

Presumably, this could be a variable... like... SHOWALLMATCHES = 1 (default 0)

Update: I've found that commenting out the # Look in the current web, return when found section of FindElsewherePlugin.pm (line 231) almost meets this need. This change alone, however, renders an "MOD" instance in the Main web as MOD^{(Main, Acronym)} with both "MOD" and "^Main" linking to Main.MOD. This causes a bit of clutter, putting two identical links next to each other. I can't figure out how to make the "Main" superscript link go away... I've toyed with adding a control command in the # Look in the other webs, return when found section (line 250) like:

if ($otherWeb eq $theWeb) {
  next;
}

-- DustinGooding - 21 May 2007

Nice Plugin, but this is also example #1000 of a plugin which doesn't work with other Plugins. This Plugin does not work with a WYSIWYG editor.....

-- MaartenDeRuiter - 25 Jul 2007

In our local installation, I've added code to Core.pm to expand variables in LOOKELSEWHEREWEBS (function _lazyInit):

  $otherWebs = &TWiki::Func::expandCommonVariables($otherWebs);

This allows us to define LOOKELSEWHEREWEBS as follows:

 Set LOOKELSEWHEREWEBS = %WEBLIST{separator=","}%

This gives us automatic linking throughout the site, and I don't even have to update the LOOKELSEWHEREWEBS definition when new subwebs are added.

However, this may have a significant performance impact (haven't run measurements yet). Any opinions on this change?

-- ClausBrod - 09 Jan 2008

What's the expected behavior of this plugin in a hierarchical web configuration? For example, if I have a Foo/Bar subweb with a GazonkOmatic topic in it, what should FindElsewherePlugin do with the following WikiWords:

1. GazonkOmatic
2. Bar.GazonkOmatic
3. Foo.Bar.GazonkOmatic

Both Foo and Foo/Bar are in LOOKELSEWHEREWEBS.

In my installation (4.2.0 RC2), (1) and (3) resolve as expected, but (2) doesn't.

-- ClausBrod - 11 Jan 2008

I propose two changes to make FEP compatible with SpacedWikiWordPlugin:

1. change the link output from

   [[web.topic][topic]]

   to web.topic -> SpacedWikiWordPlugin ignores links with a specified label for obvious reasons
2. modify the joining of multiple matches -> ,web.topic is ignored by TWiki; , web.topic or

   ,[[web.topic]]

   not

See also the discussion between xoimai (me) and OliverKrueger http://koala.ilog.fr/twikiirc/bin/irclogger_log/twiki?date=2008-06-08

Does anyone have any objections against these changers?

-- MartinKoning - 08 Jun 2008

I think the bracket notation was introduced, reverted and re-introduced for performance reasons. Since both variants work, I would suggest to make a case distinction whether {FindElsewherePlugin}{enabled} is true or not.

-- OliverKrueger - 09 Jun 2008