Page MenuHomePhabricator

[SMW] When mainlabel specified an extra mainlabel parameter is added in the further results link
Closed, ResolvedPublic

Description

SMW 1.7.0.0.2 MW 1.18

This query:

{{#ask: [[Anything]]

mainlabel=Anymainlabel

}}

Will be changed to this query, when clicking on "further results":

{{#ask: [[Anything]]

mainlabel=Anymainlabel
?=Anymainlabel#

}}

Notice that this part is added by the further results URL query string:

?=Anymainlabel#

The relevant further results url query string is:

/Special:Ask/-5B-5BAnything-5D-5D/-3F%3DAnymainlabel-23/mainlabel%3DAnymainlabel/

When it should be:

/Special:Ask/-5B-5BAnything-5D-5D/mainlabel%3DAnymainlabel/

Note that the query string is produced correctly if it starts out as it would otherwise be incorrectly done. This:

{{#ask: [[Anything]]

mainlabel=Anymainlabel
?=Anymainlabel#

}}

Will produce this:

/Special:Ask/-5B-5BAnything-5D-5D/-3F%3DAnymainlabel-23/mainlabel%3DAnymainlabel/

Just like it should.

This bug is all that look similar when I searched prior to entering this bug. It might be somehow related:

https://bugzilla.wikimedia.org/show_bug.cgi?id=23722


Version: unspecified
Severity: normal

Details

Reference
bz34749

Event Timeline

bzimport raised the priority of this task from to Needs Triage.Nov 22 2014, 12:17 AM
bzimport set Reference to bz34749.

I have just discovered that manually formatting a URL query string will not eliminate extra:

?=Anymainlabel#

That will still be displayed on the Special:Ask page, even if the URL does not contain it. So, the problem is deeper than just the "Further results" link.

This problem also occurs for the export formats (CSV, DSV, JSON, possibly others). I'm assigning this to Jeroen.

djschaap wrote:

I found explicitly hiding the first column via mainlabel=-, then including it in the first position via ?= seems to work around this. When used with format=template, this keeps the numbered parameters correct, too.

{{#ask: [[Anything]]

?=Anymainlabel
?more fields ...
mainlabel=-

}}

I have not upgraded to 1.8 yet. I've got to set aside some time to be able to find and fix anything that breaks after the upgrade is done. Rolling out fixes is time consuming on large wikis, so I've been updating a few mechanisms we have to make it easier to fix things that will inevitably get broken by something unexpected when we upgrade. I haven't stayed current on the mailing list, so I will have to review the traffic to get up to speed about likely trouble spots from the 1.7 to 1.8 upgrade. As far as I am aware, most of the changes were performance related, from NischayN's GSoC work, so maybe there's not much to worry about when upgrading.

tarkis13 wrote:

(In reply to comment #4)

Is this still present in 1.8?

I can confirm that it is still present in 1.9.0.1.