Extension talk:Semantic Drilldown/Archive 2012 to 2016

"Or" Filter values not displayed

After selecting a filter in BrowseData, the "or" values do not appear for that same property. You only see Other and None. It seems like SDAppliedFilter->getAllOrValues() is returning an empty array.

Using MW 1.23.1, SMW 1.9.2, Drilldown 2.0 Dpmpolo (talk) 18:57, 8 December 2014 (UTC)

Sort order in drilldown results

Is it possible to order the results by their frequency? --Dusanson 17:17, 28 January 2012 (UTC)

Hi - unfortunately, no. Yaron Koren 14:41, 29 January 2012 (UTC)

has drilldown title property not working

I am unable to get the "has drilldown title" property working. I set it in my category here: http://thisishowyouplay.com/wiki/Special:Browse/Category:Activities

but when I try to browse data, it still says "browse data" on this page: http://thisishowyouplay.com/wiki/Special:BrowseData/Activities?_single

thanks again. Chrisisready 02:27, 12 February 2012 (UTC)

Yes - you've discovered a problem that seems to occur with more recent versions of MediaWiki - starting with MW 1.18 or 1.18.1. I think I just fixed it in SVN - see here. Yaron Koren 16:10, 12 February 2012 (UTC)

Thanks Yaron! The patch worked great. You're the best. Chrisisready 19:09, 12 February 2012 (UTC)

After the upgrade from 1.17.x to 1.18.1 the DrillDown gave up working

My configuration:

• MediaWiki 1.18.1
• PHP 5.2.17 (cgi)
• MySQL 5.0.91mm-log

and

• Semantic Bundle (Version 20120124)
• Semantic Forms (Version 2.3.2)
• Semantic MediaWiki (Version 1.7.0.2)

http://tunearch.org/Special:BrowseData now shows just a list of articles in category, in alphabetical order.
Are there configuration issues related to the semantic bundle that I'm missing?

I have entered the following in my LocalSettings.php

######## THE SEMANTIC BUNDLE  ######
$sdgNamespaceIndex = 170;
require_once( "$IP/extensions/semantic-bundle/SemanticBundleSettings.php" );
require_once( "$IP/extensions/semantic-bundle/SemanticBundle.php" );

and this in the $IP/extensions/SemanticBundleSettings.php

# Semantic Drilldown 
# More info: http://www.mediawiki.org/wiki/Extension:Semantic_Drilldown#Installation
include_once( "$IP/extensions/SemanticDrilldown/SemanticDrilldown.php" );
$sdgShowCategoriesAsTabs = false;
$sdgFiltersSmallestFontSize=9;
$sdgFiltersLargestFontSize=25; 
$sdgNumResultsColumns=1;
$sdgNumResultsPerPage=250;

I also run the $IP/extensions/SemanticMediaWiki/maintenance/SMW_refreshData.php more than once... nothing happened.
Please help!
VALERIO M. PELLICCIONI - 18:46, 12 February 2012 (GMT+1)

Hi - it looks like you got both the URL and the date wrong... anyway, this looks like the page you're talking about, and the filters seem to be working correctly there. Is there still a problem? Yaron Koren (talk) 19:30, 9 March 2012 (UTC)

Slow to load page links on Semantic Drilldown

UPDATE!!!!: The problem seems to only exist in Chrome. Are there any known incompatibilities or conflicts with Chrome?

Hello -- I have several filters set up and on one of them, there are serious performance issues. The links to pages that meet the criteria load immediately, but it takes 10 seconds until they can be clicked on. On some filters, things work fine but on the one with perhaps several hundred values, it is very laggy. What is a reasonable number of values a filter can have before performance suffers?

I know that one option is to have a restricted set of values and to use a Combo Box. However, I'd greatly prefer not to do that since I want to allow users to add their own tags.

Are there any recommended speed enhancements specifically for using Semantic DrillDown?

I tried the following speed enhancements to no avail:

• $smwgQEnabled=false;
• $smwgQEqualitySupport=SMW_EQ_NONE;

I'm not sure if caching has been setup yet... would that improve the issue? I'm not very experienced and would prefer to avoid setting up PHP caching unless that would definitely fix the problem.

I am running:

• Semantic Drilldown .0.8.3
• Semantic Mediawiki 1.5.5 alpha
• Mediawiki 1.17.0
• PHP 5.3.3 (apache2handler)
• MySQL 5.1.61

Thanks in advance for any help. SEE UPDATE ABOVE!!!!

Hi - the choice of browser really shouldn't have any effect, since all the performance-intensive stuff done by Semantic Drilldown is server-side. Also, SMW settings should have no effect (as you discovered), since SD does direct SQL queries, instead of going through SMW. You could try upgrading SD (and SMW) - I don't know if that will have an effect, but it couldn't hurt, and it's a good idea anyway. If that doesn't help, it could be that switching to combo boxes is the best solution, for now. Yaron Koren (talk) 02:29, 8 April 2012 (UTC)

Excluding a page from drilldown

Is there a way to exclude particular page from showing up within drilldown? Something like __HIDEFROMDRILLDOWN__ for pages? --Dusanson (talk) 13:49, 25 April 2012 (UTC)

No - out of curiosity, why would you want that? Yaron Koren (talk) 14:40, 25 April 2012 (UTC)

Pity. I ended up changing the template. Well, i'd need to explain more widely what i'm working on, briefly - we have two sets of pages with imported data: public, and the rest which is only visible to their owners. They can make them public after setting up an account, but before that their data shall not be part of drilldown. --Dusanson (talk) 16:38, 25 April 2012 (UTC)

Filter problems with namespaces

I have had problems with filters not returning results - error msg: (There are no values for this filter) is displayed.

It occurs when I have a local namespace defined. $smwgNamespaceIndex has been set, the ns label/value #defined and listed in $wgExtraNamespaces. The docs on $smwgNamespacesWithSemanticLinks say "Overwriting the following array"... so I assume that means to copy it, add additional namespaces and insert into LocalSettings.php (I have tried before and after the SemanticBundleSettings.php line).

I find that doing that breaks all filters (sometimes only some are broken until SMW_Refresh -ftpv & -v are done, then all don't work). If I change the list in SMW_Settings.php (and remove the list in LocalSettings.php) all is fine.

I have just tested it with MediaWiki 1.19.0, PHP 5.3.3, MySQL 5.0.77, Semantic Bundle (Version 20120327).

Am I missing something? Can that be reproduced elsewhere? Or should $smwgNamespacesWithSemanticLinks not be in LocalSettings.php?

Thanks for a bunch of great extensions! Bejay (talk) 07:55, 16 May 2012 (UTC)

Hi - if you go to a page in that custom namespace, that has properties defined in it, and click on "Browse properties", do the properties show up? If not, then this isn't a Semantic Drilldown issue. Yaron Koren (talk) 15:08, 16 May 2012 (UTC)

Spezial:BrowseData causes Fatal error after Update 1.18.2 to 1.19.0

After updating to MW 1.19.0 Using Spezial:BrowseData results in following error:

Fatal error: Call to a member function getArticleID() on a non-object in /var/www/MyWiki/extensions/PageSchemas/PageSchemas.classes.php on line 265

My configuration:

• MediaWiki 1.19.0
• PHP 5.3.10-1ubuntu3.1 (apache2handler)
• MySQL 5.5.22-0ubuntu1

and

• Semantic Bundle (Version 20120327)
• Semantic Forms (Version 2.4.2)
• Semantic MediaWiki (Version 1.7.1)

Barpfotenbaer (talk) 12:46, 23 May 2012 (UTC)

This sounds like a bug in the Page Schemas extension - by the way, it's great that you're using Page Schemas. What's the category name? My guess is that it contains non-Latin characters. Yaron Koren (talk) 16:42, 23 May 2012 (UTC)

No category, starting at the top of the tree

...?title=Spezial:BrowseData/Personenindex works, but does not show the grey category chooser box anymore.

...?title=Spezial:BrowseData results in the error.

However, I discoverd something strange: I have a very similar setup on another server, with absolutely identical extensions, versions and LocalSettings.php. It differs only in PHP (version & configuration) and MySQL

• MediaWiki 1.19.0
• PHP 5.3.3 (cgi-fcgi)
• MySQL 5.0.95

and everything seems to be fine there!

In total I have updated 6 SMW installations from 1.18.2 to 1.19.0. Four of these installations are on the same server. The both installations on the two different servers are doing well. But it is strange, that on the "big" server, 3 of 4 installations are affected by this error, but one single installation is doing very well! Every single installation does have absolutely identical extensions installed they do differ inside LocalSettings.php only in names, MySQL-configuration and user rights.

Barpfotenbaer (talk) 13:33, 24 May 2012 (UTC)

Strange! Maybe it's the MySQL configuration - MyISAM vs. InnoDB, latin1 vs. utf8, or something like that? Yaron Koren (talk) 15:06, 24 May 2012 (UTC)

I compared all databases, but all are type InnoDB. If not binary, only one database has some tables with utf8 charset, all the others are latin1 (if not binary). It must not be responsible for the problems. However a new strange thing occured. I installed 2 new mediawikis from scratch. The first one with 1.19.0, the second one with 1.18.2. And both are resulting in the getArticleID()-"Fatal error", mentioned above. Thus, the bug actually must not have to do with 1.19.0!

But what about my configuration? Perhaps the error is caused by my php.ini or httpd.conf? Unlikely, because all four mediawiki-installations are using the same configs, the same extensions, ... The working one is neither the first, nor the last mediawiki, I installed. Barpfotenbaer (talk) 16:20, 24 May 2012 (UTC)

I have the same problem!

--Schubi87 (talk) 16:22, 25 June 2012 (UTC)

I've looked through the code, but I can't figure out what is causing this behavior. Is this happening on a public wiki anywhere? Because that would be helpful to see. In any case, it's easy to make this problem go away, for now - you just have to un-include the Page Schemas extension (assuming you're not using it). Yaron Koren (talk) 23:22, 25 June 2012 (UTC)

I could resolve the issue by enabling all rights for the database user. By default they are not enabled.--Schubi87 (talk) 10:44, 28 June 2012 (UTC)

That's good news, though very strange.... just to clarify: (1) you got the error message above ("Call to a member function getArticleID()..."), (2) it only showed up when you went to "Special:BrowseData" without a category name, and (3) it went away when you added rights for the database user? Yaron Koren (talk) 14:49, 28 June 2012 (UTC)

(2) I just saw the message when I called Special:BrowseData without any arguments. 1,3 are correct. Maybe there was something else that influenced (3). --Schubi87 (talk) 16:10, 2 July 2012 (UTC)

Filter based on Namespace

Is there a way to have Semantic Drilldown filter by Namespace (I'm trying to get it to include pages from the Main namespace)

--Rosencrantz (talk) 18:09, 24 September 2012 (UTC)

No, there's no way to do that. Yaron Koren (talk) 18:17, 24 September 2012 (UTC)

No Results format for Googlemaps

I had set up a semantic browse data on mapped places. On my category page I had set as per the Browse Cities example shown in the documentation. I had this working up until I upgraded to the letest version of Mediawiki 1.19.2 PHP5.2.17 SQL5.0.91 and latest SMW bundle

Now I get the following error message There is no result format for 'googlemaps'.

Backtrace:

#0 /hermes/waloraweb070/b2209/moo.xxx/wikireedia/extensions/SemanticDrilldown/specials/SD_BrowseData.php(1093): SMWQueryProcessor::getResultPrinter('googlemaps', 0, Object(SMWQueryResult))
#1 /hermes/waloraweb070/b2209/moo.xxx/wikireedia/includes/QueryPage.php(530): SDBrowseDataPage->outputResults(Object(OutputPage), Object(SkinMonoBook), Object(DatabaseSimpleSecurity), Object(ResultWrapper), 14, 0)
#2 /hermes/waloraweb070/b2209/moo.xxx/wikireedia/extensions/SemanticDrilldown/specials/SD_BrowseData.php(148): QueryPage->execute('Places')
#3 /hermes/waloraweb070/b2209/moo.xxx/wikireedia/includes/SpecialPageFactory.php(476): SDBrowseData->execute('Places')
#4 /hermes/waloraweb070/b2209/moo.xxx/wikireedia/includes/Wiki.php(263): SpecialPageFactory::executePath(Object(Title), Object(RequestContext))
#5 /hermes/waloraweb070/b2209/moo.xxx/wikireedia/includes/Wiki.php(593): MediaWiki->performRequest()
#6 /hermes/waloraweb070/b2209/moo.xxx/wikireedia/includes/Wiki.php(503): MediaWiki->main()
#7 /hermes/waloraweb070/b2209/moo.xxx/wikireedia/index.php(58): MediaWiki->run()
#8 {main}

Google Maps and Semantic Maps works everywhere else in the Wiki and I put the Validator/Maps and Semantic Maps in the right order in LocalSettings.php. In semanticbundlesettings.php I uncommented the $egGoogleMapsKey line (doesnt make a difference either way). If i just leave the format=maps I dont get an error just the page with the coordindates of the places not the maps themselves. Do I have a compatibility issue or a set up issue?--Paulreed (talk) 02:31, 26 September 2012 (UTC)

I've seen that issue myself, and, if I remember correctly, both I and Jeroen De Dauw (the author of Semantic Maps) have looked into it, but without being able to figure it out, unfortunately. In any case, I'm pretty sure this is an issue in Semantic Maps. Yaron Koren (talk) 13:34, 27 September 2012 (UTC)

Filters not showing values

I set up a few filters, but they don't appear to register the values. I've tried several things but none seem to work including the different options to specify the included values and running SMW_refreshdata.

http://businessmodelproject.com/w/Special:BrowseData/Business

Any insight would be greatly appreciated.

MediaWiki 1.19.1
PHP 5.3.14
MySQL 5.5.21
SMW 1.7.1 Semantic Drilldown 1.2.2

CJGarner (talk) 13:46, 8 October 2012 (UTC)

Hi - it's because all your properties are of type "Text", which can't be filtered on. "Text" should be used only for properties that can have very long values - you should switch those properties to "String" instead (or, for the case of "Active Model", possibly "Boolean"). Yaron Koren (talk) 15:57, 8 October 2012 (UTC)

Yes. I switched the properties and everything worked perfectly. Thank you! CJGarner (talk) 16:03, 8 October 2012 (UTC)

In the Drilldown page, Is it possible to automatically hide filter that doesnt show any value because of previous select.

In the drilldown page when we select some values, some filters below doesnt show any values anymore... Is that possible to automatically hide this row or is this enhancement planned ?

Thanks,

Nicolas NALLET (talk) 18:29, 11 October 2012 (UTC)

No, unfortunately there's no such feature, and it's not planned. Do you think it would be a good idea? Yaron Koren (talk) 22:26, 11 October 2012 (UTC)

Hi, Yes it could be a nice feature because we could put a lot of filters and be sure to have the clearest DrillDownPage.

Another solution could be showing filters only if a value was selected in another filter. But it need more configuration in the category page.

What do you think ?

Thanks, Regards

Nicolas NALLET (talk) 18:25, 12 October 2012 (UTC)

Hi - for that, you can already use the "Requires filter" property, if I understand your question correctly. Yaron Koren (talk) 03:15, 15 October 2012 (UTC)

Hi, ok for "Requires filter" property, but it shows the new filter regardless the value selected previously. And some values has no values in the new filter posted and in consequence we have a filter without value... Idont know if I'm clear...

See U Nicolas NALLET (talk) 15:16, 15 October 2012 (UTC)

I get it - you want the 2nd filter to show up only if the 1st filter has been selected with certain values. Yes, there's no way to do that - that might be interesting. Yaron Koren (talk) 16:53, 15 October 2012 (UTC)

Yes you got it. And I think that it could be achieved by 2 ways :

• Enhance the property (or build a new special property which could be named "require value in filter") "Requires filter" to require only one value of the filter to be selected and not anyone of the values of the filter.
• Adding the rule : if "There are no values for this filter" the filter is completly hide

Both solution have the same results a narrower "drilldown zone" in the DrillDown page without empty filters, and thus more results directly visible at the bottom without nedding scroll.

I think the 2nd way is more simple both for programer and admin : he could put a lot of filters without being afraid of overload the drilldown with empty filters which will appear after the first value selected.

Anyway I thnink that that's not a priority enhancement. What do you think? Thanks and see U Nicolas NALLET (talk) 19:29, 15 October 2012 (UTC)

Wrong version?

I was about to write here that the filters no longer work in the latest version of SD, but now I see there may be an error in the documentation. The latest version according to the infobox is 1.2.4, but the download link leads to a version that claims to be v1.2.3 - which may not be compatible with SMW 1.8 (and so may explain the filter issue). Could someone put up the correct version? Cavila ^{MW 1.19.2, MySQL 5.1.63, Php 5.3.3-7, SMW 1.8, SF 1.5.1} 11:14, 21 January 2013 (UTC)

Oops! I had the wrong download link there for two months. That's pretty bad... hopefully it didn't cause too many problems. Thanks for letting me know about that; I just fixed it. Yaron Koren (talk) 14:06, 21 January 2013 (UTC)

No problem at all, as far as I'm concerned, and thanks for fixing this so quickly. Now the filters are working again rather smoothly. Cavila ^{MW 1.19.2, MySQL 5.1.66, Php 5.3.3-7, SMW 1.8, SF 1.5.1} 12:09, 28 January 2013 (UTC)

Troubleshooting Semantic Drilldown after upgrade "(There are no values for this filter)"

After upgrading switching to php 5.3 from 5.2 and upgrading from mediawiki 1.18, smw 1.7 and all other extensions, including Semantic Drilldown from 1.2.2-- drilldown no longer works -- the Browse Data page is now useless. I'm just looking for next steps in the trouble shooting process.

Current Config

• MediaWiki 1.20.6
• PHP 5.3.25 (cgi-fcgi)
• MySQL 5.5.30-30.1
• Semantic Drilldown (Version 1.2.4)
• Semantic MediaWiki (Version 1.8.0.4)

Problem Details

• Every Filter just reports "(There are no values for this filter)" on Special:BrowseData. These filters used to work. I created new filters, they don't work. custom labels don't display.
• Semantic properties work. All the basic tools for browsing semantic data in SMW, property pages list values, ask# works, etc.... SMW appears to work
• all changes to semantic data ends up updating the data as one would expect.
• I have tried disabling all extensions other than Validator, SMW, and Drilldown, with no effect on this
• the MW db user has all required permissions for SMW 1.8.0.4
• no errors show up when $wgShowExceptionDetails or $wgDebugToolbar are enabled.

And.. what might be the key to this:

• a private facing MW install of 1.19.2 with Drilldown 1.2.2 and SMW 1.7 has also stopped functioning in the exact same way. it is on the same server.
• a few hours after switching to php 5.3 from server default via forcing through .htaccess -- both SMW sites went down due to a new server config error on the part of the hosting service- essentially despite my .htacccess telling the site to use php5.3 the site was being forced to 5.2.17. They fixed it super fast after I contacted them, so they probably did something easy.

Any insights? anyone else run into this problem? any ideas for what I should be looking into? could this be a problem server-side? Is there something I can check or should ask tech support to check/fix? I am not really a server person and I have learned the hard way that for tasks that I cannot access, I need to spell out exactly what I need them to do/try -so specific ideas would be really helpful.... Thanks!

-- A.Sea.Arr (talk) 17:44, 12 June 2013 (UTC)

Hi - I just released a new version of Semantic Drilldown, 1.2.5, yesterday, that may fix this problem - please try upgrading to that. Yaron Koren (talk) 18:00, 12 June 2013 (UTC)

I was so excited to try the upgrade... but no change occurred. I'm not really sure where I should be looking to fix this. I've already tried going back down to 1.2.2 as well... -- A.Sea.Arr (talk) 21:48, 12 June 2013 (UTC)

Downgrading definitely won't work. How are you defining your filters? Can you paste here the contents of one of the non-working "Filter:" pages? Yaron Koren (talk) 23:03, 12 June 2013 (UTC)

Some Examples -- I just cut and pasted, and took out the extraneous details and added "code" and "nowiki" formatting for readability here. My filters previously worked. I've tried subbing in the enumeration allowed values to "Has value" for the filter with no result as well. All of the filters have plenty of material to work from and the SMW property pages list pages/values as one would expect. All only are on properties of type "enumeration" there are no dependencies on other filters. Top level category, one property filter for most cats. The fact that it stopped working in two MW installs, only one that has been upgraded to DD 1.2.4 (well, 1.2.5, now) makes me wonder if something could be wrong with our host's server configuration post move to php5.3.25? I just wish I knew enough on how to dig deeper or could pinpoint the exact point at which they stopped working.

::::Category:Y  
::::Has form: [[Has default form:: Y]].   
::::This category has the drilldown title [[Has drilldown title::Browse by Attribute]].  
::::This category uses the filters  [[Has filter::Filter:X]]  
::::Filter:X  

::::This filter covers the property [[Covers property::X]]. 
::::It has the label [[Has label::Expanded Label Title X]. 

::::Property:X     
:::: is a property of type [[Has type::Enumeration]]. 

::::Allowed values:
::::* [[Allows value::a]] 
::::* [[Allows value::b]] 
::::* [[Allows value::c]] 

--A.Sea.Arr (talk) 15:13, 13 June 2013 (UTC)

I don't know if PHP is involved, but in any case, "Enumeration" is not a type - could that be the issue? Also, I'm not sure if "Covers property" requires the "Property" namespace - you might try adding it in, just in case. Yaron Koren (talk) 15:16, 13 June 2013 (UTC)

First -- Thanks for your help! Second, some digging showed me that "Enumeration" was really just an alias for String -- which I see is now depreciated as of SMW 1.8. Its not working on the MW1.19 install with SMW 1.7, anymore either. Also, It's my understanding that type "text" can't be filtered on ... but that's the suggested replacement for properties of type string.... Does type "Page" still work with Drilldown? there are a couple of filters for Type Page, and even when changing the "Covers Property::Property:X" --- this didn't lead to success (on either install). -- A.Sea.Arr (talk) 18:25, 13 June 2013 (UTC)

Type "Text" can be filtered on, starting with SMW 1.8, and with the latest SD. And yes, you can filter on "Page". Yaron Koren (talk) 20:23, 13 June 2013 (UTC)

An Update: I figured out what was causing the problem and fixed it. This was kind of an idiot case mistake. $smwgNamespacesWithSemanticLinks array definition in LocalSettings.php was updated with new namespaces after all plugin defintions, and the indiv. who added the custom namespaces had just copied declaration from the SMW definitions and then added our namespaces to the end, not realizing that other extensions (SD) need to update this as well. Changing the statement to "$smwgNamespacesWithSemanticLinks = $smwgNamespacesWithSemanticLinks + array(WHATEVS);" made all the difference in the world A.Sea.Arr (talk) 19:48, 12 July 2013 (UTC)

Fatal error: Unsupported operand types in SemanticDrilldown.php on line 161

i cam getting this error: Fatal error: Unsupported operand types in extensions/SemanticDrilldown/SemanticDrilldown.php on line 161 am using the latest MediaWiki ver, and am installing the extension thru git.

That's odd... what code do you have on that line? Yaron Koren (talk) 15:12, 9 July 2013 (UTC)

here is my code:
157 // Enable semantic links on filter pages
158 $smwgNamespacesWithSemanticLinks = $smwgNamespacesWithSemanticLinks + array(
159 SD_NS_FILTER => true,
160 SD_NS_FILTER_TALK => false
161 );
162 }
163
164/**********************************************/
165/***** language settings *****/
166/**********************************************/

i am using the latest extension version @ (git clone https://git.wikimedia.org/git/mediawiki/extensions/SemanticDrilldown.git)
and am using the following sys environment:
MediaWiki 1.20.5
PHP 5.3.24
any hints?

Hm, yes, that's what I have also. My current theory is that, for some reason, you have $smwgNamespacesWithSemanticLinks set to some value that's not an array. Are you including SD in LocalSettings.php after SMW? If so, perhaps you modify that variable somewhere in LocalSettings.php? Yaron Koren (talk) 13:07, 11 July 2013 (UTC)

if i replace my line $smwgNamespacesWithSemanticLinks = $smwgNamespacesWithSemanticLinks + array(

with $smwgNamespacesWithSemanticLinks = array(
i don't get that error msg anymore, and i can see the SpecialPage.
but if i go to: Special:BrowseData i get the following error msg:
Fatal error: Call to undefined function smwfGetStore() in extensions/SemanticDrilldown/includes/SD_Utils.php on line 203 no i am not including SMW, as i don't have it installed. and that variable 'smwgNamespacesWithSemanticLinks ' is defined nowhere in LocalSettings.php
any hints?

Ah, that's the issue - you need SMW to run SD. Yaron Koren (talk) 16:23, 11 July 2013 (UTC)

Database error with filters

In versions 1.2.4 and 1.2.5, using filters may no longer work. Instead I'm getting the following error message, where this used to present no issues before:

A database query syntax error has occurred. This may indicate a bug in the software. The last attempted database query was:

    SELECT DISTINCT ids.smw_title AS title, ids.smw_title AS value, ids.smw_title AS t, 
ids.smw_namespace AS namespace, ids.smw_namespace AS ns, ids.smw_id AS id, ids.smw_iw AS iw,
ids.smw_sortkey AS sortkey FROM `[prefix]_smw_object_ids` ids JOIN `[prefix]_smw_fpt_inst` 
insts ON ids.smw_id = insts.s_id AND ids.smw_namespace != 14 JOIN `[prefix]_smw_di_wikipage` r0 
ON ids.smw_id = r0.s_id JOIN `[prefix]_smw_object_ids` o_ids0 ON r0.o_id = o_ids0.smw_id WHERE 
insts.o_id IN (SELECT smw_id FROM `[prefix]_smw_object_ids` cat_ids WHERE smw_namespace = 14 
AND (smw_title = '[...]')) AND (r0.p_id = (SELECT smw_id FROM `[prefix]_smw_object_ids` WHERE 
smw_title = '[...]' AND smw_namespace = 102)) AND (o_ids0.smw_title = '[...]') ORDER BY sortkey 
LIMIT 250 

from within function "SDBrowseDataPage::reallyDoQuery". Database returned error "1242: Subquery returns more than 1 row (localhost)".

(Personal information has been disguised)

One thing that's changed since my last post on this page (January) is a shift to SMW 1.8.0.5 with Store3, but I'll investigate this further, if possible. Update: This could be another instance of bug 43260, in which case the bug may be down to SMW rather than SD. Perhaps the replication issue rears its ugly head again. Cavila (MW 1.19.7, MySQL 5.1.66, Php 5.3.3-7, SMW 1.8, SF 1.5.2} 09:19, 10 July 2013 (UTC)

Yes - you have more than one ID for the same page somewhere. I thought I had fixed this everywhere, but apparently not. Have you tried using the latest Git code, by the way? Yaron Koren (talk) 13:29, 10 July 2013 (UTC)

Yes, I did download the zipped files from git using the link given on the page for this extension (as opposed to, say, Distributor). Cavila (MW 1.19.7, MySQL 5.1.66, Php 5.3.3-7, SMW 1.8, SF 1.5.2} 07:52, 11 July 2013 (UTC)

Well, that's not the very latest version, but it's close enough. I'll have to look into this again. Yaron Koren (talk) 13:08, 11 July 2013 (UTC)

OK, the database error has disappeared following an upgrade to 1.3. Instead the filters are not working at all, but I should investigate this first (maybe having switched properties to type "Text" is causing this). Cavila (MW 1.19.7, MySQL 5.1.66, Php 5.3.3-7, SMW 1.8, SF 1.5.2} 10:49, 7 September 2013 (UTC)

Order of filters are not the same in category page and in browsedata page

Hi,

In this category page, the filter "Marque"is in first position but it appears in the last position in the drilldown page

My software Versions :

• MW 1.21.1
• SMW 1.8.0.5
• SD 1.2.5 (It was the same problem with older version)

Any idea ?

Thanks,

Nicolas NALLET (talk) 15:22, 14 July 2013 (UTC)

Yes - there's no guarantee on the order of the filters, unfortunately. I would try making a small change to the category page and resaving it. Yaron Koren (talk) 13:32, 15 July 2013 (UTC)

Ok I have found the tips : the first criterion of the order is the date when the filter was published. This date could be reseted if the filter is erased. If more than one filter is published at the same time, the second criterion (the order of the filter on the page),is taken into account.

In consequence for changing the order of the filter you must first erase each filter

1. edit the category page
2. write down the filter sentence for the fisrt filter that you want to appears in the BrowData page
3. publish and do again the 3 steps for each filter

Nicolas NALLET (talk) 15:21, 15 July 2013 (UTC)

Do all the properties I create with Semantic Forms need to have no accented letter to be acceptable in Semantic Drilldown

I continue building www.coetus.eu thanks to your great tools. I was amazed how simple it is to use SemanticDrillDown, yet on http://www.coetus.eu/wiki/Sp%C3%A9cial:BrowseData/Tome?_single= if all the values get displayed well, some of the properties do not filter as they should. Eg : http://www.coetus.eu/wiki/Sp%C3%A9cial:BrowseData/Tome?_single&Ville_d%27%C3%A9dition=Londres does not restrict from the 196 pages down to the 28 having Londres as the value of property "Ville d'édition". The same issue happens with "Année d'édition".

My best guess is it might be Drilldown might not work well with accented letters. Should I remove any accented letter from any of my semantic properties, definitions of forms, etc, for this to work ? Or is there anything else I can do to fix this problem ?

Many thanks in advance.

Frederic, 19th August 23h @Paris.

I can't reproduce this problem locally. I would try upgrading to the latest version - maybe it's been fixed already. Yaron Koren (talk) 21:57, 19 August 2013 (UTC)

Thanks for the suggestion. I'll try and keep you posted.

Handling incomplete date problem

I'm creating wiki with bibliographical records. Each page has property "Has publication date" of type date. Each of the dates is represented only by a year, for example [[Has publication date::2007]]. And Semantic Drilldown cannot handle it properly; the dates are not categorised on Browse data page. When I change the property typ from Date to Number, everything is handled as it should be.

Help says, that this kind of incomplete dates should be handled properly, so I suppose that this is a Semantic Drilldown problem.

UPDATE: On the Browse data page the following errors are displayed:

Notice: Undefined offset: 2 in /mwpath/extensions/SemanticDrilldown/includes/SD_Filter.php on line 238

Notice: Undefined offset: 1 in /mwpath/extensions/SemanticDrilldown/includes/SD_Filter.php on line 238

Notice: Undefined offset: 2 in /mwpath/extensions/SemanticDrilldown/includes/SD_Filter.php on line 240

Notice: Undefined offset: 1 in /mwpath/extensions/SemanticDrilldown/includes/SD_Filter.php on line 240

Oops, that's indeed a bug - if either the earliest or latest dates (or, in your case, both) are year-only, the code fails. I just checked in a fix for this, here - if you get the latest code from Git, or recreate this change manually, the problem should hopefully go away. Yaron Koren (talk) 19:36, 1 May 2014 (UTC)

After updating to the latest version from git, there is still problem with dates listing, look a the screenshot. After updating, I've done "data repair and upgrade" from Special:SMWAdmin page, it did not help.

What should the date range be? Do you have any idea where "0 - 9" is coming from? And is the "Publication date" property of type "Date"? Yaron Koren (talk) 18:49, 2 May 2014 (UTC)

I have no idea where "0-9" comes from. The numbers should be ranges of years, something like "1940-1948 (123) · 1950-1959 (234) · 1960-1969 (345)" and so on. And it was displayd that way, when the "Publication date" property was of type "Number". But when I've changed it to "Date" (for sure, it is of type "Date"), the categorisation disappeared. Furthermore, when I click on the "0-9", the resulting page shows no records. This is a personal wiki, but if you'd like to look, I can mail you url and access to it. DBobak (talk) 22:22, 2 May 2014 (UTC)

UPDATE: During run of SMW_refreshData script, I have got the following error message:

Notice: Undefined index: named args in /home/lithics/domains/mydomain/mw-git/core/extensions/SemanticResultFormats/formats/timeline/SRF_Timeline.php on line 39

Maybe it is in some way connected with the problem above? I'm using Mediawiki REL_1.23 from Git and all the extensions are in developement versions from Git, updated today. DBobak (talk) 13:38, 3 May 2014 (UTC)

No, that's an unrelated problem. Yes, please email me the access details. Yaron Koren (talk) 12:44, 5 May 2014 (UTC)

Hello, FYI, I got the same problem with last version of SD. Nicolas NALLET (talk) 14:21, 23 February 2016 (UTC)

Possible to use #drilldownlink in mediawiki left menu defined by MediaWiki:Sidebar

I would like to put in the left menu bar some search links leading directly to a drilldown page, on wite www.coetus.eu

Yet the #drilldownlink function is not recognized in this context, or I did not manage to use it properly in http://coetus.eu/w/index.php?title=MediaWiki:Sidebar

I wrote :

* navigation
** mainpage|mainpage-description
** recentchanges-url|recentchanges
** randompage-url|randompage
** helppage|help

* Chercher
** {{#drilldownlink:category=Auteur|single|link text=Auteur|tooltip=trouvez un AUTEUR dans la base Coetus}}
** {{#drilldownlink:category=Editeur|single|link text=Éditeur|tooltip=trouvez un ÉDITEUR dans la base Coetus}}
** {{#drilldownlink:category=Livre et Tome|single|link text=Livre&Tome|tooltip=trouvez un LIVRE ou un TOME dans la base Coetus}}
** {{#drilldownlink:category=Livre|single|link text=Livre|tooltip=trouvez un LIVRE (publié en un seul volume) dans la base Coetus}}
** {{#drilldownlink:category=Tome|single|link text=Tome|tooltip=trouvez un TOME dans la base Coetus}}
** {{#drilldownlink:category=Série|single|link text=Série|tooltip=trouvez une SERIE de tomes dans la base Coetus}} 
** {{#drilldownlink:category=Suite|single|link text=Suite|tooltip=trouvez une SUITE de lives et tomes dans la base Coetus}}
** {{#drilldownlink:category=Série et Suite|single|link text=Série&Suite|tooltip=trouvez une SUITE ou une SERIE dans la base Coetus}}
** {{#drilldownlink:category=Tome|link text=Chercher|tooltip=trouvez un livre dans la base Coetus}}
* Créer
** Formulaire:AUTEUR|Auteur
** Formulaire:EDITEUR|Éditeur
** Formulaire:LIVRE|Livre
** Formulaire:TOME|(Tome)
** Formulaire:SERIE|Série 
** Formulaire:SUITE|Suite
** Special:FormEdit/ITEM|Item
** Spécial:Forms|Liste des formulaires

* Documentation
..... etc .....

Is there a solution, or is it impossible to establish such a link ?

Thank you !

Unfortunately, you can't have parser functions within the sidebar. What you can do, and what I would recommend, is to just put in the entire URL. Yaron Koren (talk) 03:43, 16 November 2015 (UTC)

Excellent suggestion. It perfectly solves my problem. Many thanks Yaron, very helpful.

Drilldown partially not working

I'm stuck, please advise!

I am using: MediaWiki: 1.26.2; PHP: 5.4.43 (cgi-fcgi); MySQL 5.5.45-cll-lve; Semantic Drilldown: 2.0.1 on zonacostera.info, where I created

• http://zonacostera.info/Especial:Buscar_datos/DocCGSM?_single using four filters, and
• http://zonacostera.info/Especial:Buscar_datos/News?_single using three filters.

Apparently it looks ok, but on

• http://zonacostera.info/Especial:Buscar_datos/DocCGSM?_single where Año (which in fact is a number) and Sistema are working fine, whereas Etiqueta does not work and Autor works sometime, sometimes not; a similar problem occurs on
• http://zonacostera.info/Especial:Buscar_datos/News?_single with TipoMedia working fine, but Fuente noticia and KeywordsCGSM not working.

I thought it might have to do with autocomplete which is set on the forms http://zonacostera.info/Formulario:DocCGSM and http://zonacostera.info/Formulario:CGSM_en_las_noticias for the three properties which are not working, but taking autocomplete out does not make any difference.

Anybody any idea? Thanks a lot in advance. horst.salzwedel at gmail.com

No, it's not related to the forms. Are you using the very latest code? There have been various changes since version 2.0.1 came out - I really need to release a new version. Also, you should really change Año to type Date, but that's another issue. Yaron Koren (talk) 17:58, 16 May 2016 (UTC)

I do not quite get you, sorry. I am using the versions as stated above...To which code do you refer? If you would like to have access to the wiki just let me know your email and I shall make you a user...Where can I ger the latest code you are refering to?...guess I found it at https://www.mediawiki.org/wiki/Extension:Semantic_Drilldown#Code_and_download ....anyhow, I uploaded the presumingly newest version....but no difference to be noticed...Looking forward to your advise.

My best guess is that is might have to do with the length/amount of the property values. TipoMedia, Año and Sistema are all short/little values, Autor seems to work with short Autor names but not when the property value for Autor is long, and Etiqueta, KeywordsCGSM and Fuente noticia are all relatively plenty values.

Sorry for the delay. If you're not using Git, you can download the latest SD code here. Yaron Koren (talk) 02:40, 17 May 2016 (UTC)

Thanks for the link. I replaced the files on the server - unfortunately no change to notice, it behaves exactly like described earlier...Do my comments regarding the amount and lengths of property values make any sense to you? Horst Salzwedel

That's too bad. I have no idea what the cause is. Yaron Koren (talk) 16:50, 17 May 2016 (UTC)

That's really bad notice...Anyhow, I shall keep trying to find out what s wrong, because the SD is thought to be kind of the backbone of the whole site to identify documents and pages. I would appreciate if you could give me hints where to look into and/or how to approach the issue systematically: property types? filters? categories? Or is there something else to replace SD witout having to redo all the work invested regarding the established pages for docs and news (some 400)?? Horst Salzwedel

The issue is presumably in the SQL queries that SD is generating. But another option is to switch to using Cargo - all that would have to change would be the template pages and any queries. Yaron Koren (talk) 17:52, 17 May 2016 (UTC)

I shall give it a try and leave a note about the results. Thanks for your kind attention. Horst Salzwedel

Bug with Drilldown 2.0.2 and Postgresql?

Could there be a bug in SM-Drilldown in combination with PostgreSQL-DB? Whenever I want to use Special:BrowseData there is an issue with my Database

CREATE TEMPORARY TABLE semantic_drilldown_filter_values AS SELECT s_id AS id, (IF(o_blob IS NULL, o_hash, CONVERT(o_blob using utf8))) AS value FROM "smw_di_blob" JOIN "smw_object_ids" p_ids ON "smw_di_blob".p_id = p_ids.smw_id WHERE p_ids.smw_title = 'WorkflowStatus'

because there is no CONVERT(o_blob using utf8) funktion in PostgreSQL.

Backtrace

#0 /srv/www/htdocs/SemanticMediaWiki/includes/db/DatabasePostgres.php(539): DatabaseBase->reportQueryError('ERROR:  syntax ...', '42601', '\tCREATE TEMPORA...', 'DatabaseBase::q...', false)

#1 /srv/www/htdocs/SemanticMediaWiki/includes/db/Database.php(1205): DatabasePostgres->reportQueryError('ERROR:  syntax ...', '42601', '\tCREATE TEMPORA...', 'DatabaseBase::q...', false)

#2 /srv/www/htdocs/SemanticMediaWiki/extensions/SemanticDrilldown/includes/SD_Filter.php(426): DatabaseBase->query('\tCREATE TEMPORA...')

#3 /srv/www/htdocs/SemanticMediaWiki/extensions/SemanticDrilldown/specials/SD_BrowseData.php(970): SDFilter->createTempTable()

#4 /srv/www/htdocs/SemanticMediaWiki/extensions/SemanticDrilldown/specials/SD_BrowseData.php(1187): SDBrowseDataPage->printUnappliedFilterLine(Object(SDFilter), '/zweidat-test/i...')

#5 /srv/www/htdocs/SemanticMediaWiki/includes/specialpage/QueryPage.php(537): SDBrowseDataPage->getPageHeader()

#6 /srv/www/htdocs/SemanticMediaWiki/extensions/SemanticDrilldown/specials/SD_BrowseData.php(127): QueryPage->execute('Kapitel')

#7 /srv/www/htdocs/SemanticMediaWiki/includes/specialpage/SpecialPage.php(384): SDBrowseData->execute('Kapitel')

#8 /srv/www/htdocs/SemanticMediaWiki/includes/specialpage/SpecialPageFactory.php(582): SpecialPage->run('Kapitel')

#9 /srv/www/htdocs/SemanticMediaWiki/includes/MediaWiki.php(263): SpecialPageFactory::executePath(Object(Title), Object(RequestContext))

#10 /srv/www/htdocs/SemanticMediaWiki/includes/MediaWiki.php(634): MediaWiki->performRequest()

#11 /srv/www/htdocs/SemanticMediaWiki/includes/MediaWiki.php(482): MediaWiki->main()

#12 /srv/www/htdocs/SemanticMediaWiki/index.php(41): MediaWiki->run()

#13 /srv/www/htdocs/SemanticMediaWiki/index.php5(26): require('/srv/www/htdocs...')

#14 {main}

My System: MW: 1.25.5 PHP: 5.6.23 PostgresSQL: 9.4.6 SMW: 2.3.1 SM Drilldown: 2.0.2

What should I do? Thanks for help.

Correct query when having internal objects (smw_subobject in table smw_object_ids)?

Hi, recently I wondered why

http://biowikifarm.net/test2/Special:BrowseData/Publications?title=Special%3ABrowseData%2FPublications&_search_Filter_by_Authors[0]=Stevenson

… does not reveal any results. Digging further into the SQL-code I replaced sub-queries by the returned “id” and checked the subqueries further. In line 18 of the SD Query there are multiple results and I think there is a crux …

SELECT DISTINCT 
  ids.smw_title AS title, 
  ids.smw_title AS value,
  ids.smw_title AS t,
  ids.smw_namespace AS namespace,
  ids.smw_namespace AS ns,
  ids.smw_id AS id,
  ids.smw_iw AS iw,
  ids.smw_sortkey AS sortkey
FROM `smw_object_ids` ids 
JOIN `smw_fpt_inst` insts ON ids.smw_id = insts.s_id AND ids.smw_namespace != 14 
JOIN `smw_di_blob` a0 ON ids.smw_id = a0.s_id WHERE insts.o_id 
  IN (
    3408 
    -- SELECT smw_id FROM `smw_object_ids` cat_ids WHERE smw_namespace = 14 AND (smw_title = 'Publications')
  )
  AND a0.p_id = ( 5487 ) 
     -- SELECT MAX(smw_id) FROM `smw_object_ids` WHERE smw_title = 'Foaf:maker' AND smw_namespace = 102
  AND ( 
    (IF(a0.o_blob IS NULL, a0.o_hash, CONVERT(a0.o_blob using utf8)))
   LIKE '%Stevenson%'
  ) ORDER BY sortkey LIMIT 251

Line 18 in detail returned …

SELECT * FROM `smw_object_ids` WHERE smw_title = 'Foaf:maker' AND smw_namespace = 102 -- returned
-- smw_id  smw_namespace   smw_title   smw_iw        smw_subobject                          smw_sortkey  smw_proptable_hash
-- 89      102             Foaf:maker                                                        Foaf:maker  [BLOB - 244B]
-- 5485    102             Foaf:maker                _QUERY234fa9f6d71e103eae34892340f70471  Foaf:maker  [BLOB - 250B]
-- 5486    102             Foaf:maker                _QUERY731c28ab03f46900831aeecdb7144a90  Foaf:maker  [BLOB - 250B]
-- 5487    102             Foaf:maker                _QUERYfe979f664830b88689849aaa9c5202f8  Foaf:maker  [BLOB - 250B]
-- 5484    102             Foaf:maker  :smw-delete   _QUERY1762a3582fc3588f47ad99d12eecc8a2  Foaf:maker  [BLOB - 6B]
-- 5483    102             Foaf:maker  :smw-delete   _QUERY9c1bcfa1a0ad47ff334d852c6d9e4a89  Foaf:maker  [BLOB - 6B]

… and it turned out that a0.p_id=89 (line 17) was needed instead of a0.p_id=5487. So my guess is smw_subobject has to be considered as well in filtering the SD query.

• Do you follow?
• Is it fixed in SD 2.0.2? (biowikifarm.net/test2 uses still SD 2.0.1)

--Andreas P. 16:20, 17 November 2016 (UTC)

Okay, I think I understand - thanks for isolating the problem. I have no idea if this bug still exists with the latest SD, but it would be good to know. Yaron Koren (talk) 20:35, 17 November 2016 (UTC)