Page MenuHomePhabricator

Separate out logo handling into square image logos and long text/wordmark banner logos
Open, HighPublic

Description

Basically, we seem to have three sorts of logo layout:

  • Long banner/wordmark, in which it's either just the text logo, or an image plus the text logo (Minerva, BlueSky, CologneBlue, Timeless header/on mobile)
  • Square logo with text/wordmark underneath (MonoBook, Vector)
  • Square logo one place, text/banner/wordmark elsewhere in interface (Timeless desktop - text in header, square in sidebar, GreyStuff - banner/text in header, square logo in footer, or at least that was the idea...)

By splitting the logo into two distinct images, a square image logo if applicable and a long text/wordmark version, we could thus minimise the number of uploads required for branding different types of skins while consistently supporting all of them:

  • Assemble the MonoBook/Vector logos by placing a 135-150px square logo image above a 135-150px centered/text wordmark
  • Allow skins to use only text/wordmark or logo image in different places as appropriate

For backwards compatibility:

  • Fall back to $wgLogo etc if none of the new stuff is specified (what Timeless currently does for the square sidebar logo)
  • Fall back to styled text message containing by default (sitetitle) or whatever if no wordmark image is specified (Minerva uses (mobile-frontend-footer-sitename) and Timeless uses (timeless-sitetitle) custom messages as wrappers currently, but we likely do want to standardise this as well)

Developer notes

We'll introduce a wgLogos array which will replace wgLogo and wgLogoHD.

QA steps

ASAP

Using an old device (IE7 on browserstack suggested)

On Thursday, February 27:

  • Open Wikipedia, Commons, and Wikidata (in any language) from a modern browser. Confirm there is no changes to the logos.
  • Open Wikipedia, Commons, and Wikidata (in any language) from IE 8. Take a screenshot of the logo (we are expecting it to look broken)

Sign off notes

  • Setup a task for a config change to replace MinervaCustomLogos with wgLogos
  • Setup a task to make a configuration change to merge MinervaCustomLogos, wgLogo and wgLogoHD

Details

Related Gerrit Patches:
operations/mediawiki-config : masterMerge $wgLogo and $wgLogoHD into $wgLogos
mediawiki/skins/MinervaNeue : masterDeprecate wgMinervaCustomLogos in favor of $wgLogos
mediawiki/core : masterUpdate you-should-set-a-logo reminder to point to $wgLogos, not $wgLogo
operations/mediawiki-config : masterMobile logo should fall back to PNG if no SVG support
mediawiki/extensions/ContentTranslation : masterUse wgLogos['wordmark'], not the removed wgMinervaCustomLogos
mediawiki/core : master[doc] [PHP] fix wfDeprecated() description
mediawiki/skins/MinervaNeue : masterFollow-up 51a34809: Don't hard-deprecate something still set in config, you'll break prod
mediawiki/skins/MinervaNeue : masterHard-deprecate $wgMinervaCustomLogos being set
mediawiki/skins/MinervaNeue : masterDrop support for $wgMinervaCustomLogos being set
mediawiki/skins/Vector : masterDrop usage of mediawiki.skinning.interface module in favor of SkinModule
mediawiki/extensions/WikimediaIncubator : masterRead from (and write to!) wgLogos, not the deprecated wgLogo
mediawiki/core : masterCorrectly use wfDeprecated function signature for wgLogoHD
mediawiki/core : masterFollow-up 8cd2e13: RELEASE-NOTES-1.35: Add new $wgLogos configuration
mediawiki/core : masterRestore wordmark to Vector printed media
mediawiki/core : masterFollow-up 8cd2e13: Setup: Check that 1x key has been set in wgLogos before using
operations/mediawiki-config : masterSet $wgLogos['1x'] (new style access) to $wgLogo (old style access)
operations/mediawiki-config : masterRestore wgLogoHD to wikis without a MinervaCustomLogos defined
mediawiki/core : masterDeprecate access of logos directly from config, introduce wgLogos
operations/mediawiki-config : masterwgLogoHD and $wgVectorPrintLogo is replaced with wgLogos (2/2)
operations/mediawiki-config : masterwgLogoHD and $wgVectorPrintLogo is replaced with wgLogos (1/2)
mediawiki/core : masterRemove the need for Vector's ResourceLoaderLessModule and wgVectorPrintLogo
mediawiki/core : masterDeprecate wgLogo and wgLogoHD
mediawiki/skins/Vector : masterDrop mediawiki.skinning.interface
mediawiki/core : masterReplace wgLogo and wgLogoHD with more generic wgLogos

Related Objects

Event Timeline

There are a very large number of changes, so older changes are hidden. Show Older Changes

Mentioned in SAL (#wikimedia-operations) [2020-02-05T12:50:32Z] <urbanecm@deploy1001> Synchronized wmf-config/CommonSettings.php: SWAT: d450288: wgLogoHD and $wgVectorPrintLogo is replaced with wgLogos (T232140) (duration: 01m 07s)

Mentioned in SAL (#wikimedia-operations) [2020-02-05T13:03:06Z] <urbanecm@deploy1001> Synchronized wmf-config/InitialiseSettings.php: SWAT: 5cc2b70: wgLogoHD and $wgVectorPrintLogo is replaced with wgLogos (T232140) (duration: 01m 06s)

Change 570326 had a related patch set uploaded (by Jdlrobson; owner: Jdlrobson):
[operations/mediawiki-config@master] Restore wgLogoHD to wikis without a MinervaCustomLogos defined

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

Currently wgLogos and wgLogoHD are set with the same value in production. wgVectorPrintLogo is set for the time being, but will be removed along with wgLogoHD once the related changes are out across all wikis.

I'm seeing 2 potential issues so far:
Previously a logo displayed on Vector when you printed it, however for some reason this is not displaying any more. I'm not sure if this relates to these changes as before I deployed I was not seeing it. Locally I am able to see the logo. Could possibly be something to do with the use of @when in ResourceLoader ? I'm also not seeing it in production (before the new changes) so I think this may have broken some time earlier.

I'd expect to see a rule for firstHeading:before in skins.vector.styles on beta cluster per mediawiki.skinning. This does not seem to be the case.

I'll look into this more tomorrow (seems we have lots of print related issues right now - including the heading being missing altogether!).

HD Logos not applying in some places?
I've been testing quite a few wikis on Vector and in the wikipedia cases - I'm seeing logos for higher dpi - however after some more testing I noticed that other projects didn't seem to apply them - e.g. https://af.wiktionary.org - and the 1x PNG logo is the only thing applying. I realised that I made a mistake in my config change to only copy wgLogos to wgLogoHD when a Minerva logo exists. I'm finishing for the day but https://gerrit.wikimedia.org/r/570326 will need to be deployed ASAP to restore the higher dpi logos. To test we need to verify that when you open the inspector on https://af.wiktionary.org a @media (-webkit-min-device-pixel-ratio:2 media query wraps .mw-wiki-logo {

I've asked @phuedx or somebody else in the team to deploy this.

Change 570365 had a related patch set uploaded (by Jforrester; owner: Jforrester):
[mediawiki/core@master] Follow-up 8cd2e13: Setup: Check that 1x key has been set in wgLogos before using

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

Change 570326 merged by jenkins-bot:
[operations/mediawiki-config@master] Restore wgLogoHD to wikis without a MinervaCustomLogos defined

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

Mentioned in SAL (#wikimedia-operations) [2020-02-05T16:25:23Z] <jforrester@deploy1001> Synchronized wmf-config/CommonSettings.php: T232140 Restore wgLogoHD to wikis without a MinervaCustomLogos defined (duration: 01m 09s)

Change 570378 had a related patch set uploaded (by Jforrester; owner: Jforrester):
[operations/mediawiki-config@master] Set $wgLogos['1x'] (new style access) to $wgLogo (old style access)

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

Change 570379 had a related patch set uploaded (by Jforrester; owner: Jforrester):
[operations/mediawiki-config@master] Merge $wgLogo into $wgLogos

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

Change 570365 merged by jenkins-bot:
[mediawiki/core@master] Follow-up 8cd2e13: Setup: Check that 1x key has been set in wgLogos before using

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

Krinkle added a comment.EditedWed, Feb 5, 6:43 PM

[…]
HD Logos not applying in some places?
I've been testing quite a few wikis on Vector and in the wikipedia cases - I'm seeing logos for higher dpi - however after some more testing I noticed that other projects didn't seem to apply them - e.g. https://af.wiktionary.org - and the 1x PNG logo is the only thing applying. I realised that I made a mistake in my config change to only copy wgLogos to wgLogoHD when a Minerva logo exists. I'm finishing for the day but https://gerrit.wikimedia.org/r/570326 will need to be deployed ASAP to restore the higher dpi logos. […]

Previous state:

  • DefaultSettings (as deployed), wgLogo=false, wgLogoHD=[]
  • wmf-config/ InitialiseSettings: wgLogo = 1x logo, wgLogoHD = high res
  • Everything works.

What has changed so far:

  • wmf-config/ InitialiseSettings: wgLogoHD assignment changed to wgLogos. However, that config key doesn't exist yet in the deployed MediaWiki version, and once the new one rolls out, this vlaue is invalid because it is expected to contain both 1x and high-res. It is invalid to give it only the high-res values. This is not the laid out migration strategy that I saw proposed and discussed in the core patch.
  • wmf-config/ CommonSettings: $wgLogoHD = $wgLogos; added in https://gerrit.wikimedia.org/r/570326. This further invalates the config by letting the key wordmark that was added to the new wgLogos be exposed to wgLogoHD, where it is unexpected. Fortunately, it seems MediaWiki core gracefully handles this unknown key, although we did not test for that ahead of time afaik. (EDIT: Turns out, it didn't support that. Prod error now failed at T244405)

In order for stuff to keep working after the new branch the simplest path forward I think would be to revert the config changes made so far. The old config works natively on the current wmf branch. And the next wmf branch of MediaWiki both supports the new config key and implements it correct by default by simply combining wgLogo and wgLogoHD.

What was the reason for making the wmf-config changes ahead of the branch having rolled out?

Change 570378 merged by jenkins-bot:
[operations/mediawiki-config@master] Set $wgLogos['1x'] (new style access) to $wgLogo (old style access)

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

Change 570412 had a related patch set uploaded (by Jforrester; owner: Jforrester):
[mediawiki/core@master] Follow-up 8cd2e13: RELEASE-NOTES-1.35: Add new $wgLogos configuration

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

Change 570412 merged by jenkins-bot:
[mediawiki/core@master] Follow-up 8cd2e13: RELEASE-NOTES-1.35: Add new $wgLogos configuration

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

What was the reason for making the wmf-config changes ahead of the branch having rolled out?

My thinking was that since wgLogoHD was marked as deprecated we'd want to make sure wgLogo was set before the branch rolling to avoid any kind of deprecation spam in the logos. Did I misunderstand how the deprecation works?

wmf-config/ InitialiseSettings: wgLogoHD assignment changed to wgLogos. However, that config key doesn't exist yet in the deployed MediaWiki version, and once the new one rolls out, this vlaue is invalid because it is expected to contain both 1x and high-res. It is invalid to give it only the high-res values. This is not the laid out migration strategy that I saw proposed and discussed in the core patch.

My read of the code was that if 1x is not set on wgLogos it fills it with the value of wgLogo without any warning in the new configuration.
The only migration strategy I was concerned about was wgLogoHD to wgLogos and wgVectorPrintLogo to wgLogos. The former should work with identical values before and after and the latter requires the wordmark key being set on wgLogos to work after roll out. My thinking with the config change before the roll out was that wgLogos should be set before the roll out.

In order for stuff to keep working after the new branch the simplest path forward I think would be to revert the config changes made so far

Looking through the additional changes that have made (thank you James!) I'm pretty sure the config we have now is compatible now and post-branch cut. After branch cut, we can remove wgLogosHD, wgVectorPrintLogo. T244405 seems to be the only thing we need to fix. Am I missing something?

I'm sorry if I've misunderstood something here. If I am please help outline where the current config is problematic?

Change 570491 had a related patch set uploaded (by Jdlrobson; owner: Jdlrobson):
[mediawiki/core@master] Restore wordmark to Vector printed media

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

Change 570491 merged by jenkins-bot:
[mediawiki/core@master] Restore wordmark to Vector printed media

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

Krinkle added a comment.EditedThu, Feb 6, 11:58 AM

What was the reason for making the wmf-config changes ahead of the branch having rolled out?

My thinking was that since wgLogoHD was marked as deprecated we'd want to make sure wgLogo was set before the branch rolling to avoid any kind of deprecation spam in the logos. Did I misunderstand how the deprecation works?

Yes, in so far that wgLogoHD shouldn't be considered as deprecated yet. Deprecation works as follows: New code is introduced, then rolled out, then migrated toward, then the old deprecated, then the old removed. In that order. Trying to satisfy or opt-in to new code whilst simultaneously supporting old code needlessly complicates multiversion-aware configuration code, and is imho risky and indeed untested as we've now learned. It is also virtually untest-able because our unit tests are only aware of one given MediaWiki version at a time. We can't go back now to enforce in CI that new config works with the old code. The way we enforce that is by inputting the old config into the new code, including production. Thus going in one direction only, forwards.

Actual state

Below is the current state of production. Note how the wmf-config code is taking responsility to take its new config backwards to old MW branch - instead of letting the next MW branch take responsible for bringing the old config forwards.

Phase 1 (DefaultSettings)
// Current branches (wmf.16 / wmf.18)
$wgLogo = false;
$wgLogoHD = false;

// Next branch (master)
$wgLogo = false; // or string
$wgLogoHD = false; // or array with optional 1.5x/2x/svg works
$wgLogos = false; // or array with required 1x and optional 1.5x/2x/workmark/svg keys
Phase 2 (wmf-config/InitialiseSettings)
// All branches
$wgLogo = ' … ';
$wgLogos = [ '1.5x' => , '2x' =>  ];
// ^ (note the invalid wgLogos assignment, it is missing 1x).
Phase 3 (wmf-config/CommonSettings)
// All branches
if (  MinervaCustomLogos  ) {
  $wgLogos['wordmark'] = ;
}

$wgLogoHD = $wgLogos;
// ^ (note the invalid wgLogoHD assignment, it is has an unexpected wordmark key)
Phase 4 (Setup.php)
// Current branches (wmf.16 / wmf.18)
if ( $wgLogo === false ) {
	$wgLogo = "… default …";
}

// Next branch (master)
if ( $wgLogos !== false && isset( $wgLogos['1x'] ) ) {
	$wgLogo = $wgLogos['1x'];
}
if ( $wgLogo === false ) {
	$wgLogo = "… default …";
}
// ^ (note that wgLogos lacks a default, it migrates backwards instead of forwards
//     it does not fulfil to the default its documentation says it would have)
Phase 5 (RL/SkinModule)
// Current branches (wmf.16 / wmf.18)
if ( LogoHD ) {
 return LogoHD + [ '1x' => Logo ]
} else {
 return Logo
}

// Next branch (master)
logos = Logos
if ( !logos[1x] && Logo ) {
  logos1x = Logo
}
if ( LogoHD ) {
 wfDeprecated()
 // ^ unexpected, LogoHD not be deprecated yet as it is still used in production
 logos += LogoHD
}
if ( !logos[1x] ) {
  throw;
 // ^ unexpected, Logo has a default. It can't be missing under supported runtime conditions.
}
return logos

Also note that there is a split-brain where part of the migration happens in Setup.php, and part of it happens in SkinModule.php. This is super hard to reason about, and virtually impossible to unit test.

Below two simpler alternatives, which I hinted at during the core patch CR, however I wasn't able to see it through due to other priorities:

Alternative (1)
// DefaultSettings
$wgLogo = false; // or string
$wgLogoHD = false; // or array with optional 1.5x/2x/svg works
$wgLogos = false; // or array with required 1x and optional 1.5x/2x/workmark/svg keys 

// wmf-config (unchanged)
$wgLogo = ;
$wgLogoHD = ;

// Setup
if ( !wgLogos ) {
  // Compat for old LocalSettings, and default value
  wgLogos = wgLogoHD + [ 1x => wgLogo or …default… ]
}
// Compat for reading old config (deprecated)
wgLogo = wgLogos[1x]

// SkinModule (only consider new wgLogos)

Or, if you prefer to do more of the fallback at run-time (in exchange for slight duplication of code between Setup and SkinModule):

Alternative (2)
// DefaultSettings
$wgLogo = false;
$wgLogoHD = false;
$wgLogos = false;

// wmf-config (unchanged)
$wgLogo = ;
$wgLogoHD = ;

// Setup
if ( !wgLogos ) {
  wgLogos = [ 1x => …default… ]
}
if ( !wgLogo ) {
  // Compat for reading old config (deprecated) 
  wgLogo = wgLogos[1x]
}

// SkinModule (prefer wgLogos, fall back to wgLogoHD)

In either of these approaches, wmf-config and indeed all third party wikis remain unchanged until after the upgrade is completed, at which point they have until the next release to migrate their settings to the new format. Deprecation warnings are not added until initial rollout and migration is completed in production.

Krinkle added a subscriber: Tgr.Thu, Feb 13, 11:19 PM

Side note, wfDeprecated is used wrong here:

  • the third argument is for specifying the extension/library, using it for an extra message like here just adds to the confusion. If it's important (IMO not) put it in the first parameter.
  • by default caller offset is two, which is appropriate for deprecating a function (the deprecation warning tells which function called the function that calls wfDeprecated). Since it's not ResourceLoaderSkinModule::getAvailableLogos itself that's being deprecated, that's confusing here and a caller offset of 1 should be used.

Linting issue is now fixed. In future if I'm ever away please feel free to fix such linting issues rather than block on me returning.

Thanks for the suggestion on the test I tried incorporated it (PS7) but it didn't work sadly so I've reverted back to temporarily disabling it (PS8)

Change 572308 had a related patch set uploaded (by Jdlrobson; owner: Jdlrobson):
[mediawiki/core@master] Correctly use wfDeprecated function signature for wgLogoHD

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

Change 572322 by @Jdforrester-WMF and @Tgr

[mediawiki/core@master] Follow-up 37a69a2f: ResourceLoaderSkinModule: Fix wfDeprecated() syntax
https://gerrit.wikimedia.org/r/572322

Change 572308 abandoned by Thiemo Kreuz (WMDE):
Correctly use wfDeprecated function signature for wgLogoHD

Reason:
Obsolete via Iadeec95.

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

☝️ @Jdlrobson I've left a question about the deprecation notice for wgMinervaCustomLogos not being shown in one scenario.

Change 551670 merged by jenkins-bot:
[mediawiki/skins/MinervaNeue@master] Deprecate wgMinervaCustomLogos in favor of $wgLogos

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

Change 573419 had a related patch set uploaded (by Jdlrobson; owner: Jdlrobson):
[operations/mediawiki-config@master] Mobile logo should fall back to PNG if no SVG support

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

Is there a patch for ContentTranslation? Otherwise this'll emit a bunch of hard deprecation warnings in production.

Change 573419 had a related patch set uploaded (by Jdlrobson; owner: Jdlrobson):
[operations/mediawiki-config@master] Mobile logo should fall back to PNG if no SVG support
https://gerrit.wikimedia.org/r/573419

@Jdlrobson Which are the browsers you have in mind here. IE 6-8 shouldn't be our concern here and Android < 3 is also neglible. Falling back to text seems more reasonable here than caring for PNG automation implementation and maintenance.

Is there a patch for ContentTranslation? Otherwise this'll emit a bunch of hard deprecation warnings in production.

Oh geez i completely missed that ContentTranslation was using this in that way.

https://gerrit.wikimedia.org/g/mediawiki/extensions/ContentTranslation/+/881f4279ab78f95ee34553a75817ae7764baf08f/specials/ContentTranslationSpecialPage.php

My read of the code is that this won't lead to deprecation warnings in production as we are still defining the value in config and ContentTranslation is reading directly from config and catching exceptions not using the Minerva function. We will need to fix that for compatibility however ASAP before we can clean up the config.

Yeah, sorry, was told about that by Krinkle whilst looking at writing config patches myself; see https://gerrit.wikimedia.org/r/c/operations/mediawiki-config/+/572998

Change 572984 had a related patch set uploaded (by Krinkle; owner: Jforrester):
[mediawiki/extensions/WikimediaIncubator@master] Read from (and write to!) wgLogos, not the deprecated wgLogo

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

Change 572984 merged by jenkins-bot:
[mediawiki/extensions/WikimediaIncubator@master] Read from (and write to!) wgLogos, not the deprecated wgLogo

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

Change 573762 had a related patch set uploaded (by Jforrester; owner: Jforrester):
[mediawiki/extensions/ContentTranslation@master] Use wgLogos['wordmark'], not the removed wgMinervaCustomLogos

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

Change 573767 had a related patch set uploaded (by Jforrester; owner: Jforrester):
[mediawiki/skins/MinervaNeue@master] Follow-up 51a34809: Don't hard-deprecate something still set in config, you'll break prod

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

Change 573768 had a related patch set uploaded (by Jforrester; owner: Jforrester):
[mediawiki/skins/MinervaNeue@master] Hard-deprecate $wgMinervaCustomLogos being set

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

Change 573769 had a related patch set uploaded (by Jforrester; owner: Jforrester):
[mediawiki/skins/MinervaNeue@master] Drop support for $wgMinervaCustomLogos being set

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

Change 573816 had a related patch set uploaded (by Niedzielski; owner: Stephen Niedzielski):
[mediawiki/core@master] [doc] [PHP] fix wfDeprecated() description

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

Mentioned in SAL (#wikimedia-operations) [2020-02-21T13:38:15Z] <reedy@deploy1001> Synchronized php-1.35.0-wmf.20/includes/resourceloader/ResourceLoaderSkinModule.php: T245778 T245182 T232140 (duration: 01m 00s)

Jdlrobson reassigned this task from Jdlrobson to ovasileva.Fri, Feb 21, 6:19 PM

@ovasileva important question that needs answer before Tuesday: currently when the new changes roll out we will be dropping support for showing the logo on older devices eg. Android 2, IE6-8. If we want to retain that support I need you to move this into needs more work with a comment. If this is fine you can resolve (or arrange a later QA of logos everywhere).

This change is done. There is some config cleanup to do but that will be done separately outside this ticket.

Change 573767 merged by jenkins-bot:
[mediawiki/skins/MinervaNeue@master] Follow-up 51a34809: Don't hard-deprecate something still set in config, you'll break prod

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

Change 573816 merged by jenkins-bot:
[mediawiki/core@master] [doc] [PHP] fix wfDeprecated() description

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

@ovasileva important question that needs answer before Tuesday: currently when the new changes roll out we will be dropping support for showing the logo on older devices eg. Android 2, IE6-8. If we want to retain that support I need you to move this into needs more work with a comment. If this is fine you can resolve (or arrange a later QA of logos everywhere).
This change is done. There is some config cleanup to do but that will be done separately outside this ticket.

This is fine. Let's go to QA to capture a screenshot of what they would look like in these browsers, in case this comes up later.

ovasileva updated the task description. (Show Details)Mon, Feb 24, 9:15 AM

Change 573762 merged by jenkins-bot:
[mediawiki/extensions/ContentTranslation@master] Use wgLogos['wordmark'], not the removed wgMinervaCustomLogos

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

Jdlrobson updated the task description. (Show Details)Mon, Feb 24, 6:11 PM
Jdlrobson updated the task description. (Show Details)
Jdlrobson updated the task description. (Show Details)Mon, Feb 24, 6:13 PM

Change 574525 had a related patch set uploaded (by Jforrester; owner: Jforrester):
[mediawiki/core@master] Update you-should-let-a-logo reminder to point to $wgLogos, not $wgLogo

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

Change 573419 abandoned by Jdlrobson:
Mobile logo should fall back to PNG if no SVG support

Reason:
After discussion with Olga and Volker we have decided to no longer support these browsers. Those browsers will see a broken image (img tag pointing to unsupported SVG file)

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

Change 574525 merged by jenkins-bot:
[mediawiki/core@master] Update you-should-set-a-logo reminder to point to $wgLogos, not $wgLogo

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

ovasileva removed ovasileva as the assignee of this task.Tue, Feb 25, 6:06 PM

Change 570379 merged by jenkins-bot:
[operations/mediawiki-config@master] Merge $wgLogo and $wgLogoHD into $wgLogos

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

Mentioned in SAL (#wikimedia-operations) [2020-02-27T00:13:15Z] <jforrester@deploy1001> Synchronized wmf-config/CommonSettings.php: T232140: Stop setting wgLogoHD from wgLogos (duration: 01m 05s)

Mentioned in SAL (#wikimedia-operations) [2020-02-27T00:15:12Z] <jforrester@deploy1001> Synchronized wmf-config/InitialiseSettings.php: T232140: Merge definition of wgLogos and wgLogo (duration: 01m 04s)