Extension talk:Semantic Drilldown

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: and
 * MediaWiki	1.18.1
 * PHP	5.2.17 (cgi)
 * MySQL	5.0.91mm-log
 * 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 $sdgNamespaceIndex = 170; require_once( "$IP/extensions/semantic-bundle/SemanticBundleSettings.php" ); require_once( "$IP/extensions/semantic-bundle/SemanticBundle.php" );
 * 1) THE SEMANTIC BUNDLE  ######

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

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

Barpfotenbaer (talk) 12:46, 23 May 2012 (UTC)
 * Semantic Bundle (Version 20120327)
 * Semantic Forms (Version 2.4.2)
 * Semantic MediaWiki (Version 1.7.1)


 * 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!
 * 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)