Item12770: Formatted search attaches wrong webname prefix to output variables

I maintain a Shared web with topics that are INCLUDEd into other webs. One such topic produces a tabular topic list with last edit date, parent, author...

The included code is

%TABLE{ headercolor="#000000" sort="on" }%
| *Topic* | *Parent* | *Created By* | *Last Modified* |
%SEARCH{ ".*" scope="topic" web="%INCLUDINGWEB%" type="regex" 
   nosearch="on" noheader="on" order="modified" reverse="on"
   format="| [[$web.$topic][$percntSPACEOUT{$topic}$percnt]] | $parent | $createwikiname | $date |" }%

When this is INCLUDEd into, e.g. my Vicki web, I should see something like this (expected):

Instead, I see this (actual):

The Search is returning the wrong web prefix for the $parent and $createwikiname variables. It should be using the web as specified in the web= parameter.

-- VickiBrown - 10 Mar 2014

The $createwikiname is working as documented. It returns the unqualified WikiName. To get the fully qualified name, use $createwikiusername

Also $parent is working as documented. It returns just the parent topic name. To qualify it, use $web.$parent. However you'll probably want to use a %IF to only expand the $web if $parent is non-blank.

It might seem to make sense that these should all return fully qualified topic names, but there are other applications where someone might really only want the parent topic name, or creator's user name.

-- GeorgeClark - 31 May 2014

Um... Shared.VickiBrown isn't an unqualified wikiname. It's an (incorrectly) qualitifed wikiname The "I should see" shows an unqualified name, which is, as you point out, what I should see. (But don't)

Similarly, as you point out $parent should return just the parent topic name. It doesn't (in the INCLUDED code).

George - you're repeating the bug description back to me. Look at the screenshots headers more carefully. (I added some bolding to the initial report to make it stand out more.

'>> It might seem to make sense that these should all return fully qualified topic names

No, it wouldn't; if I wanted fully qualified names, I'd ask for them. That's the point of this report. They shouldn't, but they appear to be (and the apparently fully qualified names are incorrect.)

-- VickiBrown - 31 May 2014

Okay. you are right. These are completely bogus expansions. The autolinking in my test case was throwing me off here. Expanding your test inside <noautolink> tags makes it obvious that they are wrong.

Setting this to confirmed. I've also recreated it on Foswiki 1.2. I'll mark it urgent so it has a chance of getting looked at for 1.2.

-- GeorgeClark - 31 May 2014

This does not appear to be a search bug. Search is doing the right think and returns an unqualified $createwikiname and $parent. You can prove this by putting the <noautolink> tags into the included topic surrounding the search. (Debug print's prove that search returns unqualified names). Here are trace results from Meta::getRev1Info() and the search format token expansion for $createwikiname

Meta: getRev1Info RETURNS WikiGuest 
2: ntopics | [[Litterbox.TheTopic][$percntSPACEOUT{TheTopic}$percnt]] | $parent | WikiGuest | 01 Jan 1970 - 00:02 |

So the bug? appears to be in the expansion of the %INCLUDE itself. Even with a noautolink around the including topic, the included topic gets expanded in the context of the included web.

I'm not sure if this is a bug or a side effect of includes working as designed. It's important that autolinking of wikiwords be done in the context of the included web, or they would be wrong. Since the include expands in the context of the included web, and doesn't specify noautolink, wikiwords are expanded in place. The more I ponder this, I don't believe it's a bug. Add <noautolink> tags surrounding either the entire search or around the individual $parent and $createwikiname fields and see if that works for you.

Other than that, if we change include to not expand wikiwords, I suspect we'd break a lot of things. Changed it back to Normal priority.

-- GeorgeClark - 31 May 2014

'>> So the bug? appears to be in the expansion of the %INCLUDE itself.

Yes.

I say it's a bug somewhere because two variables that are supposed to hold and provide unqualified values are instead providing not only qualified values but incorrectly qualified values. (There is no Shared.PhotoAlbums. There is no Shared.VickiBrown. Those supposed topics do not exist. That's a bug.)

That... and the fact that the bug doesn't occur in TWiki 6.

http://cfcl.com/twiki6/bin/view/Vicki/TopicListTest

-- VickiBrown - 31 May 2014

(FYI, http://wiki.cfcl.com/Vicki/TopicListTest is the exact same test page under Foswiki. Same files on the back end. I share data directories between TWIki and Foswiki instances.

-- VickiBrown - 31 May 2014

(FYI, I run noautolink by default. )

-- VickiBrown - 31 May 2014

In trying to debug this, could you add a <noautolink> tags surrounding the search in the topic that you include? I was able to recreate and then solve your issue by doing that. How do you set noautolink? By preference variable? Set in WebPreferences, User settings? Topic setting?

I suspect that maybe the INCLUDE macro is not honouring however you are setting noautolink.

So another thing to check is to use the INCLUDE without the search, just give it a wikiword to not autolink. If we can reduce this to a very simple case, and add a unit test to http://trac.foswiki.org/browser/trunk/UnitTestContrib/test/unit/Fn_INCLUDE.pm so we can fix it and make sure it never comes back.

-- GeorgeClark - 31 May 2014

Is this a duplicate of Item10949

-- GeorgeClark - 01 Jun 2014

This is definitely a dup of Item10949, and I have a fix. Unfortunately I am stumped trying to get the Unit Tests to set & pass along the NOAUTOLINK preference.

I'm checking in the fix anyway against both tasks, along with a unit test that will fail.

-- GeorgeClark - 01 Jun 2014

Commenting is disabled while not logged in