Page MenuHomePhabricator

Link page from wikimedia.Commons with page exisiting on en.wikipedia with no existing item on wikidata fails
Closed, ResolvedPublic8 Estimated Story Points


When I try on Commons on a page e.g. to add a link to tthe corresponding page on en.wikipedia for the same exemple this woiuld be using the side menu item In Wikipedia Add links then the pop-up window 'Link with page' opens where I am able to select in the field Language en and in the field Page 'Yema_T80' but when I then either validate with enter or click on the 'Link with page' button then the tool seems to start to work but it runs in what looks like a loop and even after minutes nothes has happen and you just have tthe possibility to abort the action by clicking on the 'x' in the top right corner of the pop-up window 'Link with Page'

This happens since a few days each time you try to link this way a page on Commons with an existing page on wikipedia for which there is not yet an item on wikidata. If you try this for pages wchich have already a link on wikidata everything works fine.

Event Timeline

Robby renamed this task from Link page from wikimedia.Commons with page exisiting on en.wikiipedia with no existing item on wikidata fails to Link page from wikimedia.Commons with page exisiting on en.wikipedia with no existing item on wikidata fails.Jan 16 2019, 10:20 PM
Robby added a subscriber: Lydia_Pintscher.

I just tried it for the latter example and an error shows up in my browser javascript console:

jQuery.Deferred exception: firstSite is null _createItem@
_linkFirstPageOrCreateItem/<@… undefined load.php:55:670

The code corresponding to firstSite and _createItem seems to be in client/resources/wikibase.client.PageConnector.js inside the Wikibase git repository, but that file hasn’t been substantially touched in a long time. However, the related lib/resources/wikibase.sites.js file was touched as part of T210744; the change looks innocuous enough to me, but just in case this is another regression similar to T213998 let’s CC @Michael.

diff --git a/lib/resources/wikibase.sites.js b/lib/resources/wikibase.sites.js
index 0c059f421..7dc2d14b9 100644
--- a/lib/resources/wikibase.sites.js
+++ b/lib/resources/wikibase.sites.js
@@ -76,7 +76,7 @@
                 var site = sites[ siteId ],
                     group = site.getGroup();
-                if ( $.inArray( group, groups ) === -1 ) {
+                if ( groups.indexOf( group ) === -1 ) {
                     groups.push( group );

Just looked into this. That change is actually covered by qunit unittests. So I would assume that this change should be fine 🤔

Yeah, and as far as I can tell the method touched by that change is also not used, at least not directly, by the method that now fails (_createItem), so I also now suspect the bug is somewhere else.

I also noticed this recently. I attempted the work-around of creating the link from Wikipedia instead, but that also fails because there doesn't seem to be any way of selecting Commons as the link target. Maybe that should be another issue raised in Phabricator.

With debug=true I get this:

jQuery.Deferred exception: firstSite is null _createItem@

Finding the root cause for me took hours. First I tried to reproduce it locally but I couldn't.

Then tried to check things in frontend of commons. With the debug=true, I realized it's line 331 of wikibase.client.PageConnector.js which means wb.sites.getSite( firstSiteId ) is failing. This needs to return value for both commons and enwiki. Trying it out, it works for enwiki but not commons.
If you dig in the code, it's based on mw.config.get( 'wbSiteDetails' ) config variable that gets injected using SitesModule.php and SitesModuleWorker.php in WikibaseLib. If you ask for the config variable, it doesn't have any special wiki in commons but it has in wikidata or other wikis.
This php module, reads specialSiteLinkGroups from \Wikibase\Settings::singleton() in which combines repo and client settings. So the problem is that repo setting of specialSiteLinkGroups is set to [] per default but it's correct for clients (but it got overriden once commons turned to be a repo). The fix is easy, add wikidata specialSiteLinkGroups repo setting to commons too and that's what I did in the patch.

Change 487076 had a related patch set uploaded (by Ladsgroup; owner: Ladsgroup):
[operations/mediawiki-config@master] Populate wmgWikibaseRepoSpecialSiteLinkGroups for commonswiki

Change 487076 merged by jenkins-bot:
[operations/mediawiki-config@master] Populate wmgWikibaseRepoSpecialSiteLinkGroups for commonswiki

Mentioned in SAL (#wikimedia-operations) [2019-02-04T12:34:18Z] <ladsgroup@deploy1001> Synchronized wmf-config/InitialiseSettings.php: SWAT: [[gerrit:487076|Populate wmgWikibaseRepoSpecialSiteLinkGroups for commonswiki (T213975)]] (duration: 00m 51s)

Can someone who had the issue please test it now and let us know if everything works fine?