Page MenuHomePhabricator

RelatedArticles showing on all German and Russian Wikipedia due to incorrect configuration settings
Closed, ResolvedPublic

Description

NOTE: This was an accidental change, caused by a misconfiguration and/or software bug, in a change made by a volunteer developer. See T181242#5386350 for context and technical details.

Some projects probably don't care, but several definitely do (such as dewp), and we probably want what we set in the config to, well, apply, regardless, as this will allow any relevant discussions about changing the config to likewise apply.

Evidently caused by the default value being set as an empty array in the extension as part of T181242, and wmf-config getting tripped up by that.

Details

Related Gerrit Patches:

Event Timeline

Pruem created this task.Aug 2 2019, 3:47 AM
Restricted Application added a subscriber: Aklapper. · View Herald TranscriptAug 2 2019, 3:47 AM
Aklapper changed the task status from Open to Stalled.Aug 2 2019, 8:33 AM
Aklapper removed a project: Wikimedia-Site-requests.

Hi @Pruem, thanks for reporting this. Please provide steps to reproduce a problem. I don't see any "Related Articles" when going to https://de.wikipedia.org/wiki/Berlin?useskin=vector and using Vector skin. If you see it somewhere, please explain where: https://www.mediawiki.org/wiki/How_to_report_a_bug

So there is absolutely no basis for the WMF to force-enable this extension on dewiki, as happend yesterday. I ask for an immediate reversal.

There have been no changes in the Wikimedia site configuration at https://phabricator.wikimedia.org/source/mediawiki-config/history/master/wmf-config/InitialiseSettings.php in the last two weeks to any RelatedArticles configuration settings. There is no need [yet] to make claims that "WMF" "force-enabled" something at this stage. Please see https://de.wikipedia.org/wiki/Wikipedia:Geh_von_guten_Absichten_aus for the general concept. Thanks.

T181242#5386294 implies that this is a software bug and not some intentional "force-enabling".

As this bug is one of the features the foundation is actively promoting it isnt far fetched, that the problem stems from San Francisco. Glad to hear that the installation in DE.Wikipedia was not intentionally

@Bahnmoeller: You may want to discuss meta-level assumptions about "San Francisco" (where only some WMF folks are located) in better suited places. Thanks!

Hi, here you could see the first reports about this bugs in the German Wikipedia. It was solved by hide the class about https://de.wikipedia.org/wiki/Spezial:Diff/190965755. Now it is unvisible, but the function loadRelatedArticles() load it. So it cost unnecessary Computer performance. In my opinion we could find the cause of the bug here

Change 527570 had a related patch set uploaded (by Isarra; owner: Isarra):
[mediawiki/extensions/RelatedArticles@master] Untested attempt to avoid triggering wmf-config bug

https://gerrit.wikimedia.org/r/527570

German Wikipedia user here who wants to use the feature.

Rather than to remove it completely, please either make it non-visible by default (via CSS), or make it an opt-in feature via preferences or gadgets.

Isarra renamed this task from Disable RelatedArticle feature on dewiki to RelatedArticles showing on all Wikimedia projects regardless of configuration settings.Aug 2 2019, 4:59 PM
Isarra updated the task description. (Show Details)
Isarra added a subscriber: Isarra.

Not intentional force-enabling, also not actually done by the WMF to begin with. I've updated the task to more accurately reflect what happened; if we can resolve this properly, perhaps it would be time to start some discussions about wider/different enabling.

Isarra changed the task status from Stalled to Open.Aug 2 2019, 5:16 PM
Isarra triaged this task as Unbreak Now! priority.
Restricted Application added a subscriber: Liuxinyu970226. · View Herald TranscriptAug 2 2019, 5:16 PM
Pruem removed a project: Patch-For-Review.EditedAug 2 2019, 5:22 PM

@Aklapper: Steps to reproduce the problem:

  1. open up https://de.wikipedia.org/wiki/Spezial:Zufällige_Seite?useskin=monobook
  2. open the browser tools' "inspector" tab
  3. open up (in sequence) the body element > #globalWrapper > #column-content > #mw-data-after-content > .read-more-container
  4. you will see that it is not empty, but is simply made invisible by CSS
  5. on the browser tools' "network" tab, you will see that an "api.php" call is being made upon page rendering, regardless of whether the aforementioned element is invisible

This last call should only be made if and when there is something to display, which isn't with the current settings.

Pruem added a comment.Aug 2 2019, 5:25 PM

I will now proceed to force-disable the extension by blocking api.php calls and see if this breaks something else.

Quiddity updated the task description. (Show Details)Aug 2 2019, 5:28 PM
Isarra added a comment.Aug 2 2019, 5:29 PM

Er... what? We have a patch to fix this. It should fix it everywhere. I don't know that it's necessarily the right approach (problem isn't actually the extension, but the wmf-config implementation), but it's all of two lines and won't break anything anywhere else, so...

stjn added a subscriber: stjn.Aug 2 2019, 5:53 PM
Agabi10 added a subscriber: Agabi10.Aug 2 2019, 6:28 PM

@Pruem please do not do anything blocking API calls.
Error sounds very similar to T37852 and T37853 and the issue was T142663 and the workaround in place.

The clue is in the mediawiki config:

'wmgRelatedArticlesFooterWhitelistedSkins' => [
	// T144812
	'default' => [ 'minerva' ],
	// T126826
	'htwiki' => [ 'minerva', 'vector' ],
	'hewiki' => [ 'minerva', 'vector' ], // T191573
	'wikivoyage' => [ 'minerva', 'vector' ],
	'related-articles-footer-blacklisted-skins' => [],
],

with the following entry in CommonSettings.php

// Workaround for T142663 - override flat arrays
$wgExtensionFunctions[] = function () {
	global $wmgRelatedArticlesFooterWhitelistedSkins, $wgRelatedArticlesFooterWhitelistedSkins;

	$wgRelatedArticlesFooterWhitelistedSkins = $wmgRelatedArticlesFooterWhitelistedSkins;
};

I'm not sure what should be and clearly this code has always been brittle.
Previously related-articles-footer-blacklisted-skins was set as [] for German WIkipedia which should mean enable on all skins but clearly it was using the default.

Change 527611 had a related patch set uploaded (by Jdlrobson; owner: Jdlrobson):
[operations/mediawiki-config@master] Restore RelatedArticles config

https://gerrit.wikimedia.org/r/527611

^ I believe this is the solution you are looking for. I defer to somebody like @Reedy @Krinkle or @Legoktm to give the confidence that this config is setup correctly though.

Is anyone able to confirm what $wgRelatedArticlesFooterWhitelistedSkins is being set to for English Wikipedia. German Wikipedia can be explained - the config is wrong - it's being set with the incorrect config:

	'related-articles-footer-blacklisted-skins' => [],

but English Wikipedia it should be set as ['minerva']:

'default' => [ 'minerva' ],
Isarra added a comment.EditedAug 2 2019, 7:17 PM

All right, we found the actual problem. Looks like this is related to the related-articles-footer-blacklisted-skins wikigroup, as it actually only seems to be broken on these two projects. Nowhere else I checked appears to have it showing up in any skins but minerva etc.

Is there any particular reason for disabling it even in minerva on these projects, and if so, would it perhaps make more sense to simply disable the extension entirely on these projects instead of using such a wikigroup to work around it?

Change 527611 abandoned by Jdlrobson:
Restore RelatedArticles config

https://gerrit.wikimedia.org/r/527611

Change 527570 abandoned by Isarra:
Use null instead of [] for default whitelist to avoid triggering wmf-config bug

Reason:
lolololol

https://gerrit.wikimedia.org/r/527570

Jdlrobson added a comment.EditedAug 2 2019, 7:28 PM

German Wikipedia user here who wants to use the feature.
Rather than to remove it completely, please either make it non-visible by default (via CSS), or make it an opt-in feature via preferences or gadgets.

You can enable it in your user scripts:
User:Name/vector.js

mw.loader.using('ext.relatedArticles.readMore.bootstrap');

Would be great if someone could turn that into a global gadget.

stjn added a comment.Aug 2 2019, 7:35 PM

You can copy or reference this script, since RelatedArticles wouldn’t load until .read-more-container exists on the page:
https://ru.wikipedia.org/wiki/Участник:Stjn/relatedArticles.js

Change 527632 had a related patch set uploaded (by Isarra; owner: Isarra):
[operations/mediawiki-config@master] Remove related-articles-footer-blacklisted-skins.dblist

https://gerrit.wikimedia.org/r/527632

Jdlrobson renamed this task from RelatedArticles showing on all Wikimedia projects regardless of configuration settings to RelatedArticles showing on all German and Russian Wikipedia due to incorrect configuration settings.Aug 2 2019, 8:06 PM
Jdlrobson added a project: User-notice.

Change 527632 abandoned by Isarra:
Remove related-articles-footer-blacklisted-skins.dblist

Reason:
UGH.

https://gerrit.wikimedia.org/r/527632

Change 527636 had a related patch set uploaded (by Isarra; owner: Isarra):
[operations/mediawiki-config@master] Set a dummy skin to 'disable' Related Article cards on blacklisted projects

https://gerrit.wikimedia.org/r/527636

Change 527632 restored by Isarra:
Remove related-articles-footer-blacklisted-skins.dblist

https://gerrit.wikimedia.org/r/527632

Restricted Application added a subscriber: Dereckson. · View Herald TranscriptAug 2 2019, 8:45 PM

There's no SWATs today so let's SWAT https://gerrit.wikimedia.org/r/#/c/operations/mediawiki-config/+/527632/ on Monday.
User-notice has been added to communicate this is a known problem. Solution is ready. there are SWAT windows at 4am PST and 11am PST

Isarra added a comment.Aug 2 2019, 8:48 PM

Whee!

Still not entirely sure if the commit msg on that one is accurate, but I'm like mostly entirely sure it should actually fix the matter at hand, so whatever.

Change 527636 abandoned by Isarra:
Set a dummy skin to 'disable' Related Article cards on blacklisted projects

Reason:
I like the other one better too?

https://gerrit.wikimedia.org/r/527636

Urbanecm lowered the priority of this task from Unbreak Now! to High.Aug 4 2019, 4:11 PM
Urbanecm added a subscriber: Urbanecm.

There's no SWATs today so let's SWAT https://gerrit.wikimedia.org/r/#/c/operations/mediawiki-config/+/527632/ on Monday.
User-notice has been added to communicate this is a known problem. Solution is ready. there are SWAT windows at 4am PST and 11am PST

Given we decided to SWAT this, and not deploy this as soon as possible, even outside of SWAT window, I'm lowering priority to High, per https://wikitech.wikimedia.org/wiki/Wikimedia_site_requests#Prioritisation.

Krinkle removed a subscriber: Krinkle.Aug 4 2019, 4:39 PM
Raymond added a subscriber: Raymond.Aug 5 2019, 1:39 PM

Change 527632 merged by jenkins-bot:
[operations/mediawiki-config@master] Remove related-articles-footer-blacklisted-skins.dblist

https://gerrit.wikimedia.org/r/527632

Mentioned in SAL (#wikimedia-operations) [2019-08-05T18:19:27Z] <urbanecm@deploy1001> Synchronized wmf-config/InitialiseSettings.php: SWAT: a9e4ed8: Remove related-articles-footer-blacklisted-skins.dblist (T229644, 1/3) (duration: 00m 49s)

Mentioned in SAL (#wikimedia-operations) [2019-08-05T18:20:29Z] <urbanecm@deploy1001> Synchronized wmf-config/CommonSettings.php: SWAT: a9e4ed8: Remove related-articles-footer-blacklisted-skins.dblist (T229644, 2/3) (duration: 00m 47s)

Mentioned in SAL (#wikimedia-operations) [2019-08-05T18:21:28Z] <urbanecm@deploy1001> Synchronized dblists/: SWAT: a9e4ed8: Remove related-articles-footer-blacklisted-skins.dblist (T229644, 3/3) (duration: 00m 46s)

Jdlrobson closed this task as Resolved.Aug 5 2019, 7:27 PM
Jdlrobson claimed this task.

Now fixed.

In this edit, a user at German Wikipedia complains that the feature is visible again when using the mobile skin (minerva), and I can confirm that this is actually the case. This became apparent after CSS code was removed from MediaWiki:Mobile.css which set display:none; for .read-more-container (the container which contained the tool output).

  • Is this intentional, i.e. should the feature be enabled in mobile view in German Wikipedia?
  • Has the feature been activated before the mis-configuration was deployed initially?

This has always been enabled in mobile view on German Wikipedia. If german wikipedia wants to disable it they should raise a new site request with rfc etc..