Wikimedia Bugzilla is closed!

Set to "Highest" importance - this prevents a number of important SMW-based extensions from working.

I need some more information to debug this. Please note that SMW itself is using many special properties, and would widely fail if this was a general problem. So it seems that only a few special properties are affected.

Some of the Semantic Forms properties currently have a problem with the datatype they are using, or that they are supposed to be using. Namely, there used to be a special data value "SimpleWikiPage" that represented pages but stored only their DBKey string. This is no longer supported in SMWSQLStore2 at the moment: either the data is a wiki page (then it consists of all the data related to a page) or it consists of a string only (then it must be a string or URI or similar). The problem might be in the internal assignment of SF special properties to special tables that can only keep string data.

I do not see how this would relate to the initialization issue that you mentioned. The property data item that you get by initializing from a special property label (using the static method) should be exactly the same that you get by initializing from the respective property key. However, if you provide the label as a key, then it will not be the same special property but rather a normal property named like the label of the special one. This would explain why the type problem does not occur in this case, since the property is then not treated in any special way.

Could you provide a list of the affected properties and their types?

Hi - thanks for looking into this. The obvious special property to look at is the one I mentioned before - "Has filter" in Semantic Drilldown - because it's very easy to reproduce the problem, assuming you have Semantic Drilldown installed. (If you'd prefer to look at a problem in Semantic Forms, let me know.) That property is defined as type "_wpg", on line 154, here:

http://svn.wikimedia.org/viewvc/mediawiki/trunk/extensions/SemanticDrilldown/includes/SD_GlobalFunctions.php?revision=88214&view=markup

With this code, and the latest SMW, no filters show up when looking at Special:BrowseData. However, in line 21, here:

http://svn.wikimedia.org/viewvc/mediawiki/trunk/extensions/SemanticDrilldown/includes/SD_Utils.php?revision=88214&view=markup

...if the SMWDIProperty() constructor is passed in the string "Has_filter", instead of the property ID ("_SD_F"), then the filters show up.

I tried but cannot reproduce the problem yet. Here is what I did:

* Install SD from SVN
* Create a page "Drilldown test" with the text "[[has filter::Filter:Testfilter]]"
* Add the following to Localsettings:

$wgExtensionFunctions[] = 'runMyTests';
function runMyTests() {
	$store = smwfGetStore();
	$page = new SMWDIWikiPage( 'Drilldown_test', NS_MAIN, null );
	$property = new SMWDIProperty( '_SD_F' );
	debug_zval_dump( $store->getPropertyValues( $page, $property, null ) );
}

Debug output:

array(1) refcount(2){
  [0]=>
  object(SMWDIWikiPage)#36 (3) refcount(1){
    ["m_dbkey":protected]=>
    string(4) "Testfilter" refcount(1)
    ["m_namespace":protected]=>
    long(170) refcount(1)
    ["m_interwiki":protected]=>
    string(0) "" refcount(1)
  }
}

I can also see the "has filter" value in Special:Browse. The only place where "has filter" is currently missing is the RDF export -- this needs to be fixed. Currently extension builtin properties do not get a URI assigned. But this does not affect data retrieval in SMW.

Aha! Thanks - that little script helped me to debug the issue. It turned out that I just needed to refresh all the semantic data; I didn't realize that a refresh was needed. After doing a full data refresh, it started to (mostly) work, and then I was able to debug the rest in SD. I'm marking this as "invalid".