Page MenuHomePhabricator

The "...further results" link causes the duplication of the first column on Special:Ask (1.9 alpha)
Closed, ResolvedPublic

Description

Author: icarnevale

Description:
If you define an ask on a page, and the results are paged, the link "...further results ...", which refers to the page Special:Ask passing the query as a parameter causes the duplication of the first column of the ask results table.
Ask generated in the column indicated in "mainlabel" is also added to the list of columns to display, and this causes duplication of the same.
My solution was to exclude the column if it's defined in the parameter "mainlabel".

includes/SMW_Infolink.php:

before line

$titletext = $this->mTarget . '/' . SMWInfolink::encodeParameters( $this->mParams );

i added

if(isset($this->mParams['mainlabel'])){
  foreach($this->mParams as $k => $v){
    if($v==='?='.$this->mParams['mainlabel'].'#')
      unset($this->mParams[$k]);
  }
}

Version: master
Severity: normal
URL: http://semantic-mediawiki.org/wiki/Special:Ask/-5B-5BCategory:City-5D-5D-20-5B-5BLocated-20in::Germany-5D-5D/-3F%3DCity-23/-3FPopulation%3DNumber-20of-20inhabitants/limit%3D3/mainlabel%3DCity/offset%3D3

Details

Reference
bz37214

Event Timeline

bzimport raised the priority of this task from to Medium.Nov 22 2014, 12:28 AM
bzimport set Reference to bz37214.
bzimport added a subscriber: Unknown Object (MLST).

What version of SMW are you using? I think this has been fixed already. Definitely works fine for me.

icarnevale wrote:

I'm using Semantic MediaWiki 1.7.1

I can confirm this behaviour for SMW 1.8alpha (f98e778). When was this fixed?

Kghbln added a comment.Sep 5 2012, 9:59 PM

Basically a "?=title#" is added to the printout statement

This problem is still there. A fix would be cool since this duplication consumes space one might not have on screen. For convenience I added a link to the problem.

Is this problem still there? I was no able to reproduce this on semantic-mediawiki.org (running SMW 1.8 RC1).

Yes, just click on the link provided at the URL field of this bug. The same actually applies to the export formats, too. There it is not as problematic since one may just delete the duplicated column.

Oops, the query seems to have saved the superfluous syntax. Hmm, indeed it seems to be ok right now. I will run a test today and report back.

Yes, the link stored in this bug report is just the link for a query with additional main printout. The link as such should continue to work as before, showing two main printouts (there are queries for which this is the correct link). But the link should no longer be produced for queries without an additional main printout.

Oh dear! It took me a while to understand. One of these days :( Hmm...

Having an additional second main printout when you set "mainlabel=name of mainlabel" was not the case prior to SMW 1.7+

What wonders me: How do you set a label for the first main printout, since the first main printout is empty by default? Not being able to set a label for the main printout would be a regression and indeed a bug as far as I am concerned. I believe that setting "mainlabel=name of mainlabel" should not result into a second main printout.

(In reply to comment #10)
...

What wonders me: How do you set a label for the first main printout, since the
first main printout is empty by default? Not being able to set a label for the
main printout would be a regression and indeed a bug as far as I am concerned.
I believe that setting "mainlabel=name of mainlabel" should not result into a
second main printout.

Setting mainlabel to a value does not result in a second main printout, at least not in my tests. You can set it to any value and it will merely change the label of the first column. If you want to main printout to vanish, you can set it to "-".

If you want to have a second main printout, you can get this with the printout parameter "|?" which can be assigned a label using "=" like any other printout. You can have as many main printouts as you like (and in any position among the other printouts).

Feel free to close this bug report if everything works fine for you now as well. Otherwise, it would be helpful to have a concrete query that causes a problem for you. In my tests, all queries work as expected.

Sorry it took me a while:(

I am not sure about this new behaviour. Now you have to force a second main column and suppress the first main column to avoid the column duplication on Special:Ask. Is this really the intended behaviour?

This gives you two main result columns on "Special:Ask":

{{#ask:[[Category:Website]] [[Has property count::+]]

?Has farm=Farm
?Has property count=Property values
?Has used property count=Used properties
?Has property page count=Declared properties
mainlabel=Wiki name
format=table
link=all
sort=Has property count
order=descending
headers=show
limit=100
searchlabel=… more semantic wikis
class=sortable wikitable smwtable

}}

Now you have to do this to avoid the two main result columns:

{{#ask:[[Category:Website]] [[Has property count::+]]

?=Wiki name
?Has farm=Farm
?Has property count=Property values
?Has used property count=Used properties
?Has property page count=Declared properties
mainlabel=-
format=table
link=all
sort=Has property count
order=descending
headers=show
limit=100
searchlabel=… more semantic wikis
class=sortable wikitable smwtable

}}

One may try out the old revision [1] which shows the main result column duplication.

[1] http://wikiapiary.com/w/index.php?title=Semantic_statistics&diff=187773&oldid=187677

Another way out is to use result format "template" but this is a bit overdoing things.

martin.braun wrote:

It seems to be a bug in creating the "further results" link from the inline query to the Special:Ask page when reaching the limit and having defined a mainlabel. This link erroneously contains the first search parameter as additional printout.

This problem can be reproduced and can be seen here:
http://sandbox.semantic-mediawiki.org/wiki/InlineQueryLinkBug

(The Sandbox uses SMW 1.8 alpha, it also occurs in my SMW 1.8.0.5.)

martin.braun wrote:

Correction: This link erroneously contains the result page as
additional printout.

This is similar to bug 33475.