Last modified: 2012-12-19 15:14:18 UTC
One of the modes for wbgetentities and wbsetsitelink is to report the sitelinks urls (http://www.wikidata.org/w/api.php?action=wbgetentities&ids=q42&props=sitelinks/urls). This mode will now return empty strings. This did work some days ago so something has changed that creates this failure. It is also visible in current master.
After tracing whats going on I found that SiteLink::getSite gives a SiteObject instead of MediawikiSite. Otherwise it seems like the rest of the code does what it is supposed to do.
We now have a test case for detecting this: Change I3cefa7dd: (bug 42761) make PHPUnit test aware of empty sitelinks It seems to only happen on some installations though. Can't reproduce it locally, but also see it on wikidata-dev-repo.wikimedia.de
It seems to me that after populating the tables the mediawiki sites are correctly tagged as "mediawiki" and the necessary URLs are there. (The domain in field site_domain seems weird.) During write the object is the subclass MediaWikiSite. During read out the object is the parent class SiteObject and stays that, rendering URLs unaccessible.
This turns out to be a core issue in how sites are using memcache. Jeroen is working on a fix.
Abraham: So how did this get fixed? Closing without any references or Gerrit ID is quite intransparent :-/
Problem is described in bug 43022 - SitesArray needs proper serialization
I think i added to the confusion here. To re-iterate: we found the issue now (see bug 43022), but it's not yet fixed in master. It's actually a core bug.
SiteArray's serialization was broken, causing it to come up empty when trying to deserialize. So, whenever the Sites list was taken from Memcached, it would be empty. This change fixes that problem: Change I9844236b: Fixed SiteArray serialization
