Extension talk:Semantic Drilldown

SDD don't show results in MW 1.32

• MediaWiki 1.32.0
• PHP 7.2.17-0ubuntu0.18.04.1 (apache2handler)
• MariaDB 10.1.38-MariaDB-0ubuntu0.18.04.1

I run SMW 3.0.2 and SDD 2.1 (56e40a2) 10:12, April 22, 2019
Just made un upgrade from 1.27 to 1.32
My drilldown configuration in my Category Tune is:

{{#drilldowninfo:filters=Region (property=It_comes_from),
Genre (property=Has_genre),
Rhythm (property=Has_rhythm),
|title=Down The Tune Hole}}

The Special:BrowseData/Tune show all the filtered Properties with the correct number of pages per filter but when I follow one of the filter links the Special:BrowseData/Tune special page says:

• There are no results for this report

and for the filters:

• (There are no values for this filter)

Am I miss something in config?

NOTE: I run all (I think) the requested script, i.e. maintenance/update.php and SemanticMediaWiki/maintenance/rebuildData.php
Thanks.
Silkwood (talk) 19:40, 4 May 2019 (UTC)

Unfortunately, I have no easy way to test SD with the latest versions of either SMW or MW... unless you or someone else can give me access to their system. Otherwise, you may have to debug this on your own. Yaron Koren (talk) 15:19, 5 May 2019 (UTC)

I've sent you a PM by e-mail with access details. Thanks. Silkwood (talk) 10:44, 6 May 2019 (UTC)

Database PostgreSQL: Error 42601 Syntax-Error

I run a SMW (2.4.1) MW (1.27.1) with PHP (7.0.7) and PostgresSQL (9.4.9)

As long as I set only one filter in my drilldowninfo-tag everything on Special:BrowseData is fine. But as soon as a second (or third) filter the 42601 ERROR occur: 42601 ERROR: syntax error at or near "using" LINE 2: ...AS id, (IF(o_blob IS NULL, o_hash, CONVERT(o_blob using utf8... My guess. PostgreSQL hast no CONVERT()-Funktion. I also posted this for a while at Phabricator

Backtrace:

#0 /storage/srv/www/htdocs/mediawiki-1.27.1/includes/db/DatabasePostgres.php(448): DatabaseBase->reportQueryError('ERROR:  syntax ...', '42601', '\tCREATE TEMPORA...', 'DatabaseBase::q...', false)
#1 /storage/srv/www/htdocs/mediawiki-1.27.1/includes/db/Database.php(901): DatabasePostgres->reportQueryError('ERROR:  syntax ...', '42601', '\tCREATE TEMPORA...', 'DatabaseBase::q...', false)
#2 /storage/srv/www/htdocs/mediawiki-1.27.1/extensions/SemanticDrilldown/includes/SD_Filter.php(427): DatabaseBase->query('\tCREATE TEMPORA...')
#3 /storage/srv/www/htdocs/mediawiki-1.27.1/extensions/SemanticDrilldown/specials/SD_BrowseData.php(970): SDFilter->createTempTable()
#4 /storage/srv/www/htdocs/mediawiki-1.27.1/extensions/SemanticDrilldown/specials/SD_BrowseData.php(1187): SDBrowseDataPage->printUnappliedFilterLine(Object(SDFilter), '/developer/inde...')
#5 /storage/srv/www/htdocs/mediawiki-1.27.1/includes/specialpage/QueryPage.php(619): SDBrowseDataPage->getPageHeader()
#6 /storage/srv/www/htdocs/mediawiki-1.27.1/extensions/SemanticDrilldown/specials/SD_BrowseData.php(127): QueryPage->execute('Digitalisat')
#7 /storage/srv/www/htdocs/mediawiki-1.27.1/includes/specialpage/SpecialPage.php(479): SDBrowseData->execute('Digitalisat')
#8 /storage/srv/www/htdocs/mediawiki-1.27.1/includes/specialpage/SpecialPageFactory.php(576): SpecialPage->run('Digitalisat')
#9 /storage/srv/www/htdocs/mediawiki-1.27.1/includes/MediaWiki.php(282): SpecialPageFactory::executePath(Object(Title), Object(RequestContext))
#10 /storage/srv/www/htdocs/mediawiki-1.27.1/includes/MediaWiki.php(745): MediaWiki->performRequest()
#11 /storage/srv/www/htdocs/mediawiki-1.27.1/includes/MediaWiki.php(519): MediaWiki->main()
#12 /storage/srv/ww
w/htdocs/mediawiki-1.27.1/index.php(43): MediaWiki->run()
#13 {main}

Any suggestion or solutions? Thanks a lot!

What's the full SQL call, do you know? Yaron Koren (talk) 14:18, 19 January 2017 (UTC)

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 = 'Sachbereich' --M art in (talk) 14:27, 19 January 2017 (UTC)

On Referata there is a similar bug - but more than one filters are possible there --M art in (talk) 14:53, 19 January 2017 (UTC)

Thanks for pointing out that bug on Referata, though it's a different bug. Yes, the issue does seem to be CONVERT() with PostgreSQL - that function exists, but it has different syntax and (I think) behavior. I just checked in what I think are fixes for both bugs - if you get the latest code, hopefully it should work now. Yaron Koren (talk) 04:35, 20 January 2017 (UTC)

Thanks for the fast fix. The Problem with CONVERT was solved but now there is stll a database error 42883 function if (boolean, text bytea) does not exist

Seems there are still some problems with PostgreSQL. The full SQL-query is this:

CREATE TEMPORARY TABLE semantic_drilldown_filter_values AS SELECT s_id AS id, (IF(o_blob IS NULL, o_hash, o_blob)) 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 = 'Sachbereich' Could you please have a look again? --M art in (talk) 08:23, 23 January 2017 (UTC)

Ah, I didn't realize that IF() was a problem too... I just checked in another fix, so hopefully now it works. Yaron Koren (talk) 18:04, 24 January 2017 (UTC)

Thank you very much for the fix! Works great now with postgresSQL. I really appreciate your patience with stupied users like me and your time you have to spend therefore. --M art in (talk) 08:44, 30 January 2017 (UTC)

Great. Sorry about the problems! Yaron Koren (talk) 22:12, 30 January 2017 (UTC)

Free text search

Hi. Is there a way to add a free-text search box pointed only to the filtered pages? I am developing a smw about Supreme Court orders fron my country, by now I have about 80k documents. Filters are great to narrow down the search, but a search box would be very helpfull. Greetings.

No, unfortunately. If you want this feature, you may have to install the Cargo extension (which I also wrote) - it is an alternative to Semantic MediaWiki that contains a drilldown feature, closely modeled after Semantic Drilldown, but which also supports free-text search. Yaron Koren (talk) 15:28, 25 January 2017 (UTC)

Thanks a lot. When you say alternative to smw, does it mean that both extensions cannot work together?

They can run on the same wiki, although each one stores data in its own location, and they can't query each other's data. Yaron Koren (talk) 17:03, 25 January 2017 (UTC)

Filtering Data type property

I have a property wich is Date type. It works fine but, when I set $sdgMinValuesForComboBox=1; the filter doesnt give any result. I would thank any idea..

That's strange. What if you set it to 2? Yaron Koren (talk)

No matter the value, the moment ComboBox is activated for date filter, it doesnt work anymore.

Without ComboBox, when I click on a date, the follow line is generated: ...&Fecha_de_publicacion=febrero_2010 (and works)

With ComboBox: ...&_search_Fecha_de_publicacion%5B0%5D=febrero+2010 (and it doesnt work)

Well, that's a bug in the extension. I guess I never tried setting that variable to a value low enought that it would kick in for dates, so I never saw the issue. Out of curiosity, why do you want a combo box to appear, and not individual links, even if there are only a few values? Yaron Koren (talk) 19:43, 25 January 2017 (UTC)

Date ComboBox creates a group for each month, I have documents from 84 different months. So I would need to set up a very high value for $sdgMinValuesForComboBox. Also there is another property (key word) that has more that a hundred values. So, a ComboBox is more functional for me.

There may be 84 months, but only up to 12 months are shown at a time in the drilldown interface. Yaron Koren (talk) 20:37, 25 January 2017 (UTC)

You are right. I just set up $sdgMinValuesForComboBox=13. I'll let you know how it worked. Thanks.

It took a while but the date filter is already showing only 12 groups. Thanks.

Performance

Hi. I have a Category with 42k pages already loaded and it will grow fast. By now, it takes one minute to load the drilldown page. I wolud appreciate any suggestion to keep a good performance. Thanks.

I'm surprised that it's taking that long to load - it may be one specific filter that is causing the problem. You could try removing the filters one at a time, to try to isolate the problem. In any case, another option is to install and use the Cargo extension, which provides its own very similar drilldown interface - either instead of or in addition to SMW+SD. Cargo has a more straightforward database structure, so I'm guessing that it's drilldown would be faster for your data. Yaron Koren (talk) 14:57, 7 February 2017 (UTC)

New release?

I have seen that several fixes especially concerning the querying for dates were authored since the last 2.0.2 release. Thus it will be cool to have a new version. --[[kgh]] (talk) 16:42, 1 May 2017 (UTC)

It would be immensely useful to have a Composer version so that it can be integrated with the rest of the Semantic MediaWiki suite of tools. This is the last major extension from Extension:Semantic Bundle that still has to be installed manually without Composer.

"Special:Filters" and "Special:Create filters" missing after upgrade

Hi, I've upgraded my MW installation:

FROM

MediaWiki           1.19.23
PHP                 5.3.3 (apache2handler)
MySQL               5.1.73
Semantic MediaWiki  1.7.0.2
Semantic Drilldown  1.1

TO

MediaWiki           1.23.15
PHP                 5.3.3 (apache2handler)
MySQL               5.1.73
Semantic MediaWiki  2.4.1
Semantic Drilldown  2.0.2

The wiki behaves ok, all existing filters are working as expected. However, both filter-related special pages seem to be gone. I've already run the SMW "Data repair and upgrade" multiple times but to no avail. Can this be a configuration setting issue in LocalSettings.php or some missing dependency? Any pointers welcome.

TIA --Nakohdo (talk) 15:07, 16 June 2017 (UTC)

Yes, this is not a bug - in version 2.0, those two special pages were removed, because filters are now defined in category pages, as opposed to in their own separate pages. (The "Filter:" pages are still supported, but they will stop being supported at some point, so I'd suggest converting everything over to use #drilldown_info.) Yaron Koren (talk) 15:31, 16 June 2017 (UTC)

Many thanks for this information, Yaron. This helps a lot. Nakohdo (talk) 13:04, 19 June 2017 (UTC)

#drilldownlink: Syntax for "filters" setting

Hi,

I don't quite understand the correct syntax for the "filters" parameter of #drilldownlink. The documentation says:

#drilldownlink

filters - the set of filters to apply, in the format "a=b&c=d&..."

Whereas the syntax for #drilldowninfo looks different:

#drilldowninfo

{{#drilldowninfo:filters=Author (property=Was written by), ...

Could you perhaps provide a working example for #drilldownlink with filters set? Many thanks in advance.
--Nakohdo (talk) 09:34, 30 June 2017 (UTC)

Here's one example. Yaron Koren (talk) 14:03, 30 June 2017 (UTC)

Many thanks for the quick reply. However, that's an example for #drilldowninfo where the documentation is quite clear. I'm struggling with #drilldownlink. Nakohdo (talk) 14:19, 30 June 2017 (UTC)

Oh, oops. I can't think of any public examples of #drilldownlink, but for that earlier example you could have a parameter like "filters=Language=English&Data type=Education". Yaron Koren (talk) 18:46, 30 June 2017 (UTC)

Is the drilldown info cached somewhere?

I am running into an issue I can't remember experiencing with Drilldown. No matter what I change in the #drilldowninfo tag in my category, the Special:BrowseData page still shows an earlier version of the drilldown filters. It is behaving as if the drilldown filter info was cached somewhere. --Lalquier (talk) 12:30, 12 March 2018 (UTC)

I don't think so... I can't think of why that would be happening for you. Yaron Koren (talk) 13:20, 12 March 2018 (UTC)

That's very odd. I was hoping a full rebuildData would clear things up but it didn't. For some reason, the filters displayed on the Special:BrowseData page are not the same filters that are defined in the category page.I will let you know if I figure this one out. --Lalquier (talk) 10:15, 14 March 2018 (UTC)

Update - I even tried to delete the call to #drilldowninfo in my category page and I can still see the Special:BrowseData page for that category, so it is really cached somewhere. I tried restarting the web server, forcing an exclusion to the mediawiki cache for that page, clearing my browser cache with no result. Very odd. --Lalquier (talk) 11:23, 15 March 2018 (UTC)

Update 2 - so it took a few days but the cache was eventually cleared on its own and the changes were applied. I still don't know which cache is causing such a delay between mediawiki, apache and the browser but at least I know it sorts itself out eventually. --Lalquier (talk) 01:22, 16 March 2018 (UTC)

Properties set by a parser hook cannot be filtered

Property filtering works When setting {{#set::Has type=Text}} or [[Has type::Text]], but it doesn't when we set the property types through an customized parser hook. IE: {{#someparserhook: type=Text}}. Any idea why?

No idea. When you use the parser hook/function, does the data get set correctly? Does it show up in query results, for instance? Yaron Koren (talk) 00:42, 26 March 2018 (UTC)

A quick update after some further digging. Data gets set correctly, and the culprit is not the parser function but a query. If on a property page we put an ask-query like {{#ask: [[somerelationto::ThePropertyPage]]}}, filtering on that property ceases to works. Remove the query from the property page, and it still doesn't work until on the Special:SMWAdmin page we run the 'Schedule disposal' task. The filtering works again, until we put back the ask-query on the property page. I had wanted to show this on the SMW sandbox, but SemanticDrilldown is not installed there. --Remco de Boer 12:53, 27 March 2018 (UTC)

DB Unexpected Error

I run a SMW (2.5.8) MW (1.31.0) with PHP (7.0.31)

When going to https://dicoado.org/dico/Sp%C3%A9cial:BrowseData I get this error :

[W5gpIHkNzHsXxe7F9uBXeAAAAJA] /dico/Sp%C3%A9cial:BrowseData/Classe_grammaticale Wikimedia\Rdbms\DBUnexpectedError from line 3769 of /home/clients/0486a60c95a26f96e318d8715f689dd7/web/wiki/includes/libs/rdbms/database/Database.php: TemporaryTableManager::queryWithAutoCommit: Expected mass commit of all peer transactions (DBO_TRX set).

Backtrace:

#0 /home/clients/0486a60c95a26f96e318d8715f689dd7/web/wiki/extensions/SemanticDrilldown/includes/TemporaryTableManager.php(31): Wikimedia\Rdbms\Database->commit(string)
#1 /home/clients/0486a60c95a26f96e318d8715f689dd7/web/wiki/extensions/SemanticDrilldown/specials/SD_BrowseData.php(230): TemporaryTableManager->queryWithAutoCommit(string, string)
#2 /home/clients/0486a60c95a26f96e318d8715f689dd7/web/wiki/extensions/SemanticDrilldown/specials/SD_BrowseData.php(1150): SDBrowseDataPage->createTempTable(string, NULL, array, array)
#3 /home/clients/0486a60c95a26f96e318d8715f689dd7/web/wiki/includes/specialpage/QueryPage.php(642): SDBrowseDataPage->getPageHeader()
#4 /home/clients/0486a60c95a26f96e318d8715f689dd7/web/wiki/extensions/SemanticDrilldown/specials/SD_BrowseData.php(129): QueryPage->execute(string)
#5 /home/clients/0486a60c95a26f96e318d8715f689dd7/web/wiki/includes/specialpage/SpecialPage.php(522): SDBrowseData->execute(string)
#6 /home/clients/0486a60c95a26f96e318d8715f689dd7/web/wiki/includes/specialpage/SpecialPageFactory.php(568): SpecialPage->run(string)
#7 /home/clients/0486a60c95a26f96e318d8715f689dd7/web/wiki/includes/MediaWiki.php(288): SpecialPageFactory::executePath(Title, RequestContext)
#8 /home/clients/0486a60c95a26f96e318d8715f689dd7/web/wiki/includes/MediaWiki.php(861): MediaWiki->performRequest()
#9 /home/clients/0486a60c95a26f96e318d8715f689dd7/web/wiki/includes/MediaWiki.php(524): MediaWiki->main()
#10 /home/clients/0486a60c95a26f96e318d8715f689dd7/web/wiki/index.php(42): MediaWiki->run()
#11 {main}

I tried a rebuild data. Even completely deleted all SMW data and also ran the MW update.php maintenance script. I really don't know what the cause of that problem is. Any hint ? DSwissK (talk) 20:47, 11 September 2018 (UTC)

I concur, tried MariaDB and Mysql 5.7.32, same issue

It's the same thing here with MW1.30.0 SMW 3.0.0 SD 2.0.2 Carchaias (talk) 09:44, 19 October 2018 (UTC)

Same with me: MW 1.31.1, MariaDB 10.2.15, SMW 3.0.0, SD 2.0.2

Same with me with Mediawiki 1.31 and Semantic Mediawiki 2.5.8 or 3.0. This error:

[84cb877bf9a2718570bb04a1] 2019-02-13 13:55:30: Erreur fatale de type « Wikimedia\Rdbms\DBUnexpectedError »--Manu.wikidebats (talk) 14:00, 13 February 2019 (UTC)

Compatibility with SMW 3?

Hi Yaron, is current version of Semantic Drilldown compatible with SMW3? I tried to upgrade an older wiki from SMW2/Drilldown 1.4 to MW1.31 and SMW3/Drilldown latest master via git and it does not appear to work.

since SD 2.1. you can use SMW 3.0.1 BUT not together with elasticStore --M art in (talk) 08:27, 13 February 2019 (UTC)

branch compatability

Branch REL_130 yes

Branch REL_131 no

Branch REL_132(stable) no

Tag 2.1 only if PHP < 7.1, issues with the major breaking change in PHP from version 7.0 to 7.1, function count() Parameter must be an array or an object that implements Countable

Compatibility with what? Yaron Koren (talk) 16:55, 14 February 2019 (UTC)

MW REL1_30 works with SDD REL1_30 , MW REL1_31 does not work with SDD REL1_31, MW REL1_32 does not work with SDD REL1_32, SDD version 2.1 works with MW REL1_32 but if PHP > 7.1 ( I said 7.0) above you get a lot of warnings about the breaking change in count() function "count(): Parameter must be an array or an object that implements Countable in /var/www/html/extensions/SemanticDrilldown/specials/SD_BrowseData.php on line 973" and 999 and 1008. Using mediawiki docker release REL1_32 uses PHP 7.2

What's the error message for MW 1.31 and higher? Yaron Koren (talk) 02:27, 15 February 2019 (UTC)

Never mind, now I get it. You really should never use those "REL_..." branches for Semantic Drilldown - or for any other of my extensions - because they just represent a random snapshot in time; there's no coordination with MediaWiki's own release schedule. As for the "Countable" warnings - sorry about that; I checked in a fix, so if you use the latest code, those warnings should go away. Yaron Koren (talk) 05:02, 20 February 2019 (UTC)

Version 2.1 is running with MW 1.32.0, SMW 3.0.2, PHP 7.3.5, MariaDB 10.1.37

I would like to share my experience with the download links - this may be helpful for others to get the extension running with the specified configuration:

• Download link https://www.mediawiki.org/wiki/Special:ExtensionDistributor/SemanticDrilldown leads to version 2.0.2 - which is NOT running with this configuration
• Github link https://github.com/wikimedia/mediawiki-extensions-SemanticDrilldown/archive/master.tar.gz leads to version 2.1 - which is running with this configuration

MW Kappa (talk) 16:04, 3 June 2019 (UTC)

In general, ExtensionDistributor shouldn't be used for any of my extensions. Yaron Koren (talk) 13:07, 4 June 2019 (UTC)

Call to undefined method SMWQueryProcessor::processFunctionParams() since SMW 3.1.0

• MW 1.31.x
• SD master (2019-10-26)
• SMW 3.1.0

SMW 3.1.0 removed long deprecated functions from SMWQueryProcessor.

This throws

specials/SD_BrowseData.php: Call to undefined method SMWQueryProcessor::processFunctionParams()

from SD_BrowseData.php line 1305

Potential fix:

# SMWQueryProcessor::processFunctionParams( $display_params, $querystring, $params, $printouts );
  list( $querystring, $params, $printouts ) = SMWQueryProcessor::getComponentsFromFunctionParams( $display_params, false );

--Planetenxin (talk) 13:11, 26 October 2019 (UTC)

The place to report this would be on Phabricator. 「ディノ奴千？！」^{☎ Dinoguy1000} 09:37, 27 October 2019 (UTC)

Planetenxin - does that code change fix the problem for you? Yaron Koren (talk) 23:19, 27 October 2019 (UTC)

Good that you asked Yaron, indeed there was a copy&paste issue. Now, the above fix works for me.--Planetenxin (talk) 09:05, 28 October 2019 (UTC)

Okay, I merged in this change - thanks. Dinoguy1000 - it's also fine to put bug reports here. Yaron Koren (talk) 21:36, 28 October 2019 (UTC)

Aah, apologies. I've seen in the past that generally when an extension has a Phabricator project, that is the preferred location for bug reports, which is why I said as much here. 「ディノ奴千？！」^{☎ Dinoguy1000} 23:26, 28 October 2019 (UTC)

Phabricator is indeed usually better, but for simple bugs like this one, anything is fine - email too. Yaron Koren (talk) 01:38, 29 October 2019 (UTC)

Format datatables does not load with SematicDrilldown

Hi,

after an update of MediaWiki and all extensions the pages using SemanticDrilldown do no longer show results with format=datatables. Using format=datatables with common ask queries works without problems. Other formats also work without problem together with SemanticDrilldown.

• MediaWiki: 1.33.1
• PHP: 7.1.33
• Semantic MediaWiki: 3.1.1
• Semantic Drilldown: 2.1 (d75d8b5) 22:36, 15 March 2019
• Semantic Result Formats: 3.1.0

The firefox javascript console shows an error: "jQuery.Deferred exception: value is null".

Is SemanticDrilldown known to be working with MediaWiki 1.33.1? Is there any other MediaWiki version that is known to be working?

Thanks! Uli

I don't know. Are SMW queries with "format=datatables" working correctly? Yaron Koren (talk) 03:53, 26 November 2019 (UTC)

Yes, SMW queries are working correclty, SemanticDrildown not.

Today I have tested a fresh MediaWiki 1.33.1 installation and configured the installation using the web interface. Semantic Drilldown is taken from git.

I added two pages with different (text) properties, added the properties with type text and added a simple SemanticDrilldown statement with format=datatables to the category page. Executed all jobs using runJobs.php script. When going to the Special:BrowseData page the filters are displayed but the datatables do not load (only the three progress dots are shown).— Preceding unsigned comment added by 92.198.57.114 (talk • contribs) 14:00, 26 November 2019‎

I solved the problem by adding in the file "extensions/SemanticMediaWiki/res/smw/data/ext.smw.data.js", line 114, the clause "&& value !== undefined", therefore:

/* 114 */ if ( key !== '' && value != undefined && value.length > 0 && self.properties.hasOwnProperty( key ) ){

As a side note, I hoped that this way I could export the drilldown results, but also in datatables format the Export button is missing.

--MarcoFalda (talk) 13:34, 14 May 2020 (UTC)

It sounds like you should create a patch to get that added to SMW. Yaron Koren (talk) 15:13, 14 May 2020 (UTC)

Allowing for more than one value of a property

In a ReplicationWiki test version this example shows one can allow more than one value for a property (in this case years 2012, 2013, and 2014 for article year):
https://replication.uni-goettingen.de/replication/wiki/index.php/Special:BrowseData/Studies?Journal=%5B%5B%3ACategory%3AJAE%7CJAE%5D%5D&Article_year[0]=2012&Article_year[1]=2013&Article_year[2]=2014
(The markup language makes links break at certain characters like in this case, this is another problem for which I'm searching a fix.)
This can however only be made work by adding the additional years manually to the URL. When trying to click for it as indicated "Article year: (Click arrow to add another value)" the options are only "other" or "none". Yaron wrote in an email this seems to be a bug but he cannot currently fix it. Anyone else? I created a bug report at phabricator. ReplicationWiki-fan (talk) 15:22, 7 December 2019 (UTC)

Upgrading mediawiki MediaWiki 1.31.1 to 1.34.0

Product Version

MediaWiki 1.31.1

PHP 7.1.30 (apache2handler) (I upgraded to 7.2)

MySQL 5.6.10

Semantic MediaWiki 2.5.8

Semantic Drilldown (I Upgraded to the latest version)

Running update.php I'm getting error

Error from line 224 of /app/mediawiki/extensions/SemanticDrilldown/SemanticDrilldown.php: Call to undefined method SMW\DIProperty::registerProperty()

Did you also upgrade to the latest SMW version? Please take a look at SMW's compatility: SMW is not (yet) compatible with MW 1.34. --Planetenxin (talk) 10:51, 4 February 2020 (UTC)

Thanks, I did not get to SMW upgrade yet. I will start over

what alternative to my old SMWQueryProcessor::getResultFromFunctionParams($ask_params, SMW_OUTPUT_WIKI );

In a semantic wiki with SDD I wrote 5+ years ago, I used

SMWQueryProcessor::getResultFromFunctionParams($ask_params, SMW_OUTPUT_WIKI ); where $ask_params could be :
$ask_params= array ("".$wikipagename."", "?Suffixe_image=", "mainlabel=-");

This returns today an error : [Xrgon5lJueA1SWZQiRnZWAAAAMA] /index.php/F.RAYN.Shpp8 Error from line 903 of /home/coetus/dufal.fr/extensions/BooksmeetPrivateExt/includes/FonctionsDeMonExtension.php: Class 'MediaWiki\Extensions\BooksReuniteExt\SMWQueryProcessor' not found

Any clue on what my mistake is ? Possibly just that I don't know how to call the relevant SMW or SDD library at the beginning of my php file. I can send my full code page by email if it helps. Many thanks in advance.

Fatal error "Cannot write; target role is DB_REPLICA" when accessing Special:BrowseData

I have four SMW wikis, two of each (dev and live) that all use Semantic Drilldown, but only one of the four, both dev and live, is having this problem. Accessing the Special:BrowseData page throws a fatal error:

[59101af2a65b4876db1e1f27] /wiki/Special:BrowseData Wikimedia\Rdbms\DBReadOnlyRoleError from line 1195 of $IP/includes/libs/rdbms/database/Database.php: Cannot write; target role is DB_REPLICA 

Backtrace:

#0 $IP/includes/libs/rdbms/database/Database.php(1148): Wikimedia\Rdbms\Database->executeQuery(string, string, integer)
#1 $IP/includes/libs/rdbms/database/DBConnRef.php(68): Wikimedia\Rdbms\Database->query(string, string, integer)
#2 $IP/includes/libs/rdbms/database/DBConnRef.php(292): Wikimedia\Rdbms\DBConnRef->__call(string, array)
#3 $IP/extensions/SemanticDrilldown/includes/TemporaryTableManager.php(34): Wikimedia\Rdbms\DBConnRef->query(string, string)
#4 $IP/extensions/SemanticDrilldown/specials/SD_BrowseData.php(237): TemporaryTableManager->queryWithAutoCommit(string, string)
#5 $IP/extensions/SemanticDrilldown/specials/SD_BrowseData.php(1146): SDBrowseDataPage->createTempTable(string, string, array, array)
#6 $IP/includes/specialpage/QueryPage.php(687): SDBrowseDataPage->getPageHeader()
#7 $IP/extensions/SemanticDrilldown/specials/SD_BrowseData.php(133): QueryPage->execute(NULL)
#8 $IP/includes/specialpage/SpecialPage.php(575): SDBrowseData->execute(NULL)
#9 $IP/includes/specialpage/SpecialPageFactory.php(611): SpecialPage->run(NULL)
#10 $IP/includes/MediaWiki.php(296): MediaWiki\Special\SpecialPageFactory->executePath(Title, RequestContext)
#11 $IP/includes/MediaWiki.php(900): MediaWiki->performRequest()
#12 $IP/includes/MediaWiki.php(527): MediaWiki->main()
#13 $IP/index.php(44): MediaWiki->run()
#14 {main}

FWIW, all of the wikis are AWS Aurora MySQL 5.6-compatible and while the live clusters each have two nodes, a master and a replica, the dev clusters each only have a single master node. However, since this is only happening on one of the four SMW wikis, I feel it's unlikely this is specific to Aurora.

What would cause SD to error like this? Also FWIW, I don't manage our wikis' content/data, our editors do, so I can work with them if this happens to likely be a data issue. Voidwarped (talk) 19:33, 26 May 2020 (UTC)

I have the same issue : When I am on page dufal.fr Sp%C3%A9cial:BrowseData and clic e.g. on Tome to open Sp%C3%A9cial:BrowseData/Tome , I get the following INTERNAL ERROR page :

[XtQM4nqzJmd6QLKgl3akewAAAMY] /index.php/Sp%C3%A9cial:BrowseData/Tome Wikimedia\Rdbms\DBReadOnlyRoleError from line 1195 of /home/coetus/dufal.fr/includes/libs/rdbms/database/Database.php: Cannot write; target role is DB_REPLICA

Backtrace:
#0 /home/coetus/dufal.fr/includes/libs/rdbms/database/Database.php(1148): Wikimedia\Rdbms\Database->executeQuery(string, string, integer)
#1 /home/coetus/dufal.fr/includes/libs/rdbms/database/DBConnRef.php(68): Wikimedia\Rdbms\Database->query(string, string, integer)
#2 /home/coetus/dufal.fr/includes/libs/rdbms/database/DBConnRef.php(292): Wikimedia\Rdbms\DBConnRef->__call(string, array)
#3 /home/coetus/dufal.fr/extensions/SemanticDrilldown/includes/TemporaryTableManager.php(34): Wikimedia\Rdbms\DBConnRef->query(string, string)
#4 /home/coetus/dufal.fr/extensions/SemanticDrilldown/specials/SD_BrowseData.php(237): TemporaryTableManager->queryWithAutoCommit(string, string)
#5 /home/coetus/dufal.fr/extensions/SemanticDrilldown/specials/SD_BrowseData.php(1146): SDBrowseDataPage->createTempTable(string, string, array, array)
#6 /home/coetus/dufal.fr/includes/specialpage/QueryPage.php(687): SDBrowseDataPage->getPageHeader()
#7 /home/coetus/dufal.fr/extensions/SemanticDrilldown/specials/SD_BrowseData.php(133): QueryPage->execute(string)
#8 /home/coetus/dufal.fr/includes/specialpage/SpecialPage.php(575): SDBrowseData->execute(string)
#9 /home/coetus/dufal.fr/includes/specialpage/SpecialPageFactory.php(611): SpecialPage->run(string)
#10 /home/coetus/dufal.fr/includes/MediaWiki.php(296): MediaWiki\Special\SpecialPageFactory->executePath(Title, RequestContext)
#11 /home/coetus/dufal.fr/includes/MediaWiki.php(900): MediaWiki->performRequest()
#12 /home/coetus/dufal.fr/includes/MediaWiki.php(527): MediaWiki->main()
#13 /home/coetus/dufal.fr/index.php(44): MediaWiki->run()
#14 {main}

Update

This appears to be resolved in MediaWiki 1.35, as the new wikis I've built for testing to upgrade from 1.34 to 1.35 do not exhibit the problem.

Categories redirect still appear in the list

Hi, when I have a Categorie:X redirecting to Categorie:Y, I still have both X and Y showing in the list. It would be better to only display Y, don't you think? --Varlin (talk) 18:45, 6 November 2020 (UTC)

Results as table

Is there an option or expansion to get the results of a drilldown in a sortable table? I want to compare the results. MW 1.35 SD 2.1 TruckerB88 (talk) 07:26, 17 November 2020 (UTC)

You can use |display parameters= format=table in the #drilldowninfo parser function. --Varlin (talk) 20:28, 15 January 2023 (UTC)

Semantic Drilldown not working (SMW 3.2.3, MW 1.35.1)

Semantic Drilldown is not working on my new instance using MW 1.35.1 and SMW 3.2.3. Error message when accessing Special:BrowseData is

[YH7ezjnsZiEuGp@YxCuETwAAAAA] /isee135/index.php/Special:BrowseData Error from line 105 of /app/httpd/htdocs/isee135/extensions/SemanticDrilldown/includes/SD_Filter.php: Call to a member function getDatatypeLabels() on null

I can see the last version of Semantic Drilldown is now 2 years old. Is the extension still maintained ? --Emmanuel Touvier (talk) 14:04, 20 April 2021 (UTC)

Following a fix described in https://phabricator.wikimedia.org/T249172, I replaced line 105 of SD_Filter.php

$datatypeLabels = $smwgContLang->getDatatypeLabels();

with

$datatypeLabels = smwfContLang()->getDatatypeLabels();

and the error is gone. I will do some testing with this configuration. --Emmanuel Touvier (talk) 16:09, 20 April 2021 (UTC)

Note that there were other issues with SD 2.0, SMW 3.2.3 andMW 1.35.1. I suggest to use REL1_35 and not the latest tag of this extension. Actually I do not think this one is being tagged reliably any longer. [[kgh]] (talk) 17:37, 20 April 2021 (UTC)

Combobox and $sdgMinValuesForComboBox not always working

Compare these two search results :

• https://wikirouge.net/texts/en/Special:BrowseData/Text?_search_Keywords=Odessa&_search_Collection=New%20York%20Tribune
• https://wikirouge.net/texts/en/Special:BrowseData/Text?_search_Keywords%5B0%5D=Odessa&Collection=New_York_Tribune

In the second case, the combobox is not displayed, resulting in all the long list of property values displayed. I understand that the request is different ("search" vs "direct match"), but don't you think it would be better if the param $sdgMinValuesForComboBox applied to any case ? (Especially since when you pick up a property value by clicking on it, it launches a "direct match"). --Varlin (talk) 12:14, 10 May 2021 (UTC)

ExtensionRegistry?

Are there any plans to switch this extension to use ExtensionRegistry (extension.json)? SemanticMediaWiki and SemanticResultFormats, for example, already do this.

Got it running with MW 1.35.5, SMW 4.0.0

With a few modifications I got Semantic Drilldown running with MW 1.35.5 and SMW 4.0.0 with MariaDB as data store. I used mediawiki-extensions-SemanticDrilldown-REL1_35. These are my modifications:

SemanticDrilldown/includes/SD_Filter.php

• line 105

#		$datatypeLabels = $smwgContLang->getDatatypeLabels(); // old
        $datatypeLabels = smwfContLang()->getDatatypeLabels(); // new

• line 153

	public function loadDBStructureInformation() {
		global $smwgDefaultStore, $wgDBtype;

#		if ( $smwgDefaultStore === 'SMWSQLStore3' || $smwgDefaultStore === 'SMWSparqlStore' ) { // old
		if ( true ) { //new
        ...

Obviously the 'else'-branch does not apply any longer. I simply changed the 'if'-condition to 'true'. Alternatively one could clean up the whole 'if - else' construction by deleting the 'else'-branch and removing the 'if'-condition.

SemanticDrilldown/includes/SD_Utils.php

• line 447

		if ( $smwgDefaultStore === 'SMWSQLStore3' || $smwgDefaultStore === 'SMWSparqlStore' ) {
			return 'smw_object_ids';
		} else {
#			return 'smw_ids'; // old
			return 'smw_object_ids'; // new
		}

• line 457

		if ( $smwgDefaultStore === 'SMWSQLStore3' || $smwgDefaultStore === 'SMWSparqlStore' ) {
			return 'smw_fpt_inst';
		} else {
#			return 'smw_inst2'; // old
			return 'smw_fpt_inst'; // new
		}

MW Kappa (talk) 10:27, 31 January 2022 (UTC)

Hello, that's because $smwgDefaultStore possible values have been renamed. It used to be SMWSQLStore3 but now it is SMW\SQLStore\SQLStore. (see https://www.semantic-mediawiki.org/wiki/Help:$smwgDefaultStore). The code should be changed to take this in account. In the meantime, you can set this in your LocalSettings.php :

$smwgDefaultStore = 'SMWSQLStore3'; BertrandGorge (talk) 08:50, 21 July 2022 (UTC)

MW Kappa (and BertrandGorge) - sorry about the problems (and the long delay) thanks for pointing this out. I just checked in what I think is a fix for this, based on the above code. Yaron Koren (talk) 17:36, 27 July 2022 (UTC)

wfLoadExtension wrong on page

Page shows: wfLoadExtension( 'Semantic Drilldown' ); Should be: wfLoadExtension( 'SemanticDrilldown' ); (no space). Not sure where the page derives this from... 68.160.173.53 23:56, 3 March 2023 (UTC)

Thanks for reporting. Fixed. Planetenxin (talk) 08:56, 4 March 2023 (UTC)

Install via composer

Is there any experience to install with composer? I am using Semantic Drilldown since 2010 and whenever I update semantic mediawiki or semantic drilldown it works reliable. However, each time I update the version, I face the challenge to install SMW via composer and Semantic Drilldown normally (git clone, composer install from the root with inlucding all extension composer files https://github.com/MaRDI4NFDI/docker-wikibase). When doing that I see

Fatal error: Cannot redeclare smwfContLang() (previously declared in /var/www/html/extensions/SemanticMediaWiki/includes/GlobalFunctions.php:28) in /var/www/html/extensions/SemanticMediaWiki/includes/GlobalFunctions.php on line 28

caused by a composer internal "problem"

https://github.com/SemanticMediaWiki/SemanticMediaWiki/issues/5479#issuecomment-1604045185

with an unmerged fix. There will be probably a solution to this problem, but overall it would be better if both extensions were installed in the same way. Physikerwelt (talk) 04:33, 28 June 2023 (UTC)

Still not fixed as of now.. 79.95.87.62 01:20, 23 August 2024 (UTC)

Error: Call to undefined method MediaWiki\Page\PageProps::getInstance()

Mediawiki version: 1.40.0 PHP: 8.1.2

Backtrace:

from /var/www/wiki/extensions/SemanticDrilldown/includes/Services.php(115)

1. 0 /var/www/wiki/extensions/SemanticDrilldown/includes/Services.php(111): SD\Services->getPageProps()
2. 1 /var/www/wiki/extensions/SemanticDrilldown/includes/Services.php(60): SD\Services->getLoadParameters()
3. 2 /var/www/wiki/vendor/wikimedia/object-factory/src/ObjectFactory.php(227): SD\Services::getSpecialBrowseData()
4. 3 /var/www/wiki/vendor/wikimedia/object-factory/src/ObjectFactory.php(149): Wikimedia\ObjectFactory\ObjectFactory::getObjectFromSpec()
5. 4 /var/www/wiki/includes/specialpage/SpecialPageFactory.php(1326): Wikimedia\ObjectFactory\ObjectFactory->createObject()
6. 5 /var/www/wiki/includes/specialpage/SpecialPageFactory.php(1361): MediaWiki\SpecialPage\SpecialPageFactory->getPage()
7. 6 /var/www/wiki/includes/specials/SpecialSpecialpages.php(58): MediaWiki\SpecialPage\SpecialPageFactory->getUsablePages()
8. 7 /var/www/wiki/includes/specials/SpecialSpecialpages.php(47): SpecialSpecialpages->getPageGroups()
9. 8 /var/www/wiki/includes/specialpage/SpecialPage.php(701): SpecialSpecialpages->execute()
10. 9 /var/www/wiki/includes/specialpage/SpecialPageFactory.php(1475): SpecialPage->run()
11. 10 /var/www/wiki/includes/MediaWiki.php(327): MediaWiki\SpecialPage\SpecialPageFactory->executePath()
12. 11 /var/www/wiki/includes/MediaWiki.php(923): MediaWiki->performRequest()
13. 12 /var/www/wiki/includes/MediaWiki.php(576): MediaWiki->main()
14. 13 /var/www/wiki/index.php(50): MediaWiki->run()
15. 14 /var/www/wiki/index.php(46): wfIndexMain()
16. 15 {main}

2001:8F8:1DB9:F086:31D1:446C:775F:F77C 08:03, 30 September 2023 (UTC)

Plain (unformatted) printout in display under display parameters

Hello. I would like to use a template to show the results, however I need the main column results to be in a plain printout for the template to work. When I write "?=#" under the display parameters like I would with a regular semantic query, it doesn't seem to effect the semantic drilldown results. The template itself is showing up fine (and works well in other parts of the wiki), so that isn't the issue. Is there anyway to make this work?

This is an example of what I've written:

{{#drilldowninfo:filters=Type (property=Type)|display parameters=?=#;format=plainlist;template=Card;}} Lucidlywisely (talk) 11:16, 9 May 2024 (UTC)

I figured it out. In case anyone else is curious, I realized I needed to set link=none. I had forgotten about this query parameter. Lucidlywisely (talk) 12:33, 9 May 2024 (UTC)

Latest version beta 4.0 causes Page Form to throw an error in Special Pages

Beta 4.0 and Page Forms 5.8.1 don't seem to play well together. I am getting this error in Special Pages when I enable Semantic Drilldown before or after Page Forms.

[Zx7pdpHPUxdbm0PD7U6-ngAAAFM] /mediawiki/index.php?title=Special:SpecialPages Error: Call to undefined method MediaWiki\Page\PageProps::getInstance()

Lalquier (talk) 01:33, 28 October 2024 (UTC)

Hi @Lalquier, I'm getting the same error when trying to load Special Pages. Also using Beta 4.0 of SemanticDrilldown and Page Forms 5.7.2. Any update on how to solve this? Thanks Albert Ke (talk) 20:49, 14 November 2024 (UTC)

SD requires some updates. At the moment we try to get CI running again. Planetenxin (talk) 20:52, 14 November 2024 (UTC)

Thanks for the prompt reply @Planetenxin! Much appreciated all the work that is put into the Semantic tools. I'll hold off on using the 4.0 Beta version for now. Thank you! Albert Ke (talk) 02:35, 15 November 2024 (UTC)

Feel free to use the latest version from the main branch. This works very well. 4.0.0-beta3 is quite old. Planetenxin (talk) 12:19, 22 November 2024 (UTC)