Page MenuHomePhabricator

#ask result maps with template giving UNIQ/QINU tags
Closed, ResolvedPublic


Author: plewe

Trying to upgrade to MW 1.17/SMW 1.6/SM 1.0, but a new problem emerged:
When I have an ask query with map results that use a template, many of the formatted elements (headers and links at least) that appear above the map have the UNIQ...QINU in them, with source code like:
<h3> <span class="mw-headline" id=".7FUNIQ527bb8725a0682a4-h-0--QINU.7FSettlements">UNIQ527bb8725a0682a4-h-0--QINUSettlements</span></h3>

I have some form links which are replaced completely by the UNIQ tag:
{{#formlink:form=TextBlock|link text=Add quote...|query string=super_page={{PAGENAME}}&Attribute_t[Place]={{PAGENAME}}&Attribute_t[AttType]=quote}}

formatted elements appearing *below* the map are fine. Other templates work fine, and if I remove the template= from the ask query, it works fine.

This wasn't a problem in MW 1.16.1/SMW 1.5.6/SM 0.7.7. I think I followed all the upgrading instructions. Might I have missed something?

Version: unspecified
Severity: major
OS: Windows Server 2003
Platform: PC



Event Timeline

bzimport raised the priority of this task from to Needs Triage.Nov 21 2014, 11:55 PM
bzimport set Reference to bz30255.

This is a bug occurring when combining MediaWiki 1.17.x with SM 1.0 and using the template parameter. I have looked at it but could not find any working solution. (Well, this sort of is, originally you'd simply get a fatal error when trying to use the template parameter)

The issue does not occur for MediaWiki 1.18 and later.

This is quite unfortunate of course. You can always try getting a core dev that knows the MediaWiki parser well have a look at it.

plewe wrote:

Ouch! This is no the answer I'd like, but I understand that it is not worth fixing if it will go away soon.

I suppose I can make do until 1.18 is released.

leo_wallentin wrote:

MediaWiki 1.21alpha (c86351c)
Semantic MediaWiki 1.8rc1
Semantic Maps 2.1 alpha (30c1b77)
Maps 2.1 alpha (818f8f4)

leo_wallentin wrote:

Investigating further, this seems to happen when a template included at the same page as the map contains one or more <nowiki />-codes. It also happens when calling parser functions that use Parser::recursiveTagParse somewhere in the code.

leo_wallentin wrote:

...but only if the parser (or tag) function is placed BEFORE the map ...

Could you try and see if that fixes it?

It's putting back in the old dirty fix, no time to look for something better ATM.

leo_wallentin wrote:

Yes, that fixes it!