For example https://commons.wikimedia.org/wiki/Category:Berlin has a link to itself, that shouldn't be the case. Commons should never link to itself in the other projects sidebar.
To achieve this set $wgWikimediaBadgesCommonsCategoryProperty to null for commons.
Per T94989#2076945
Change 274506 had a related patch set uploaded (by Hoo man):
Set $wgWikimediaBadgesCommonsCategoryProperty to null on commons
Change 274506 merged by jenkins-bot:
Set $wgWikimediaBadgesCommonsCategoryProperty to null on commons
Mentioned in SAL [2016-03-03T00:10:00Z] <hoo@tin> Synchronized wmf-config/Wikibase-production.php: Set $wgWikimediaBadgesCommonsCategoryProperty to null on commons (T128661) (duration: 01m 09s)
Please note that page caches will take up to 30 days to clear, thus you might still see these links. Use action=purge to force that for a specific page.
@hoo @Lydia_Pintscher this is quite a small annoying bug. Would appreciate if this can be fixed.
Apparently 7a805ff94a584a91c6fbb10c1d651565cead7e89 doesn't fix the issue here. I guess this is because we set $wgWikimediaBadgesCommonsCategoryProperty to null before the WikimediaBadges extension is loaded. Once the extension is loaded, it reverts the setting to the default of P373.
In order to fix this, the extension needs to be explicitly loaded via the Wikidata.php entry point in the Wikidata extension.
Note: T173818: [Epic] Kill the Wikidata build step will also "magically" fix this, so I'm not sure direct action is required/ worth it here.
This is indeed still a problem:
hoo@terbium:~$ mwscript eval.php --wiki commonswiki > var_dump($wgWikimediaBadgesCommonsCategoryProperty); string(4) "P373
The extension is now loaded (via wfLoadExtension( 'WikimediaBadges' );) before the setting is set to null, thus this is (probably) not the cause.
Change 405925 had a related patch set uploaded (by Hoo man; owner: Hoo man):
[mediawiki/core@master] ExtensionRegistry: Properly detect if a global is already set
Looked into this some more:
wfLoadExtension only enqueues loading the extension in question, but doesn't actually load it. The actual extension loading only happens later on in Setup.php. Usually that's fine, ExtensionRegistry is not overwriting any previously set globals… but there's a bug in there, it treats variables that are null as not set, thus overriding them with the default, which is what happens here.
I uploaded a patch for ExtensionRegistry which should finally fix this.
Change 405925 merged by jenkins-bot:
[mediawiki/core@master] ExtensionRegistry: Properly detect if a global is already set
This should be fine once the above patch is deployed on commons (but beware that the old state can be cached and page purging might be required for this change to have immediate effect).