Page MenuHomePhabricator

Don't add other projects links to commons on commons
Closed, ResolvedPublic


For example 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

Event Timeline

hoo created this task.Mar 2 2016, 10:07 PM
Restricted Application added subscribers: JEumerus, Steinsplitter, Matanya, Aklapper. · View Herald TranscriptMar 2 2016, 10:07 PM
hoo updated the task description. (Show Details)Mar 2 2016, 10:08 PM

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)

hoo closed this task as Resolved.Mar 3 2016, 12:12 AM
hoo removed a project: Patch-For-Review.

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.

XXN reopened this task as Open.EditedMay 5 2017, 7:22 PM
XXN added a subscriber: XXN.

The problem still persist. Purge doesn't help.

Lydia_Pintscher triaged this task as Low priority.Jun 11 2017, 5:57 PM
Lydia_Pintscher moved this task from incoming to ready to go on the Wikidata board.

@hoo @Lydia_Pintscher this is quite a small annoying bug. Would appreciate if this can be fixed.

hoo added a comment.Sep 4 2017, 11:44 AM

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.

hoo added a comment.Sep 4 2017, 11:48 AM

In order to fix this, the extension needs to be explicitly loaded via the Wikidata.php entry point in the Wikidata extension.

hoo added a comment.Sep 20 2017, 4:04 PM

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.

Still happens, T173818 did no magic.

hoo added a comment.Jan 21 2018, 10:38 AM

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

hoo added a comment.EditedJan 23 2018, 6:51 PM

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

hoo closed this task as Resolved.Jan 23 2018, 7:06 PM
hoo removed a project: Patch-For-Review.

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).