Note: ideally the central notice banner becomes visible on the next page after the "get started" banner is dismissed. AKA dismissing "get started" doesn't make the central notice pop up immediately until navigating to the new page or page reload.

Change #1272598 had a related patch set uploaded (by EMcFarland; author: EMcFarland):

[mediawiki/extensions/GrowthExperiments@master] [DNM] [WIP] HomepageHooks: Add onCentralNoticeAfterHook

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

Some questions to consider:

• How is this arrow inserted? What hook or HTML element does it insert to?
• Where are CentralNotice banners inserted?
• Do hooks in MediaWiki have a way to override previous/later consumers of the same hook and end early?
• Are CentralNotice banners the only thing that can appear in the siteNotice space? Or is the problem not specific to CentralNotice banners?
• Could this Growth widget be put into the correct place above this space, instead of below it?
• Have we hid site notices before in Wikipedia's history?
  • Assuming yes, how is this usually done?
  • What mechanism might CentralNotice already offer for this?
  • What mechanism might MediaWiki core offer for this?

Change #1272598 abandoned by EMcFarland:

[mediawiki/extensions/GrowthExperiments@master] [DNM] [WIP] HomepageHooks: Add onCentralNoticeBeforeHook

Reason:

I decided to take an approach that doesn't require adding a new hook

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

Change #1275383 had a related patch set uploaded (by EMcFarland; author: EMcFarland):

[mediawiki/extensions/GrowthExperiments@master] CentralNoticeBanner: Hide Central Notice Banner when Growth Site Discovery Notice is Visible

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

Change #1272666 had a related patch set uploaded (by EMcFarland; author: EMcFarland):

[mediawiki/extensions/CentralNotice@master] CentralNoticeHookRunner: Add CentralNoticeAfterChoicesHook

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

Change #1272598 restored by EMcFarland:

[mediawiki/extensions/GrowthExperiments@master] [DNM] [WIP] HomepageHooks: Add onCentralNoticeBeforeHook

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

Change #1275383 abandoned by EMcFarland:

[mediawiki/extensions/GrowthExperiments@master] CentralNoticeBanner: Hide Central Notice Banner when Growth Site Discovery Notice is Visible

Reason:

I am abandoning this change because it caused the Central Notice banner to flash in front of the user

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

Change #1275969 had a related patch set uploaded (by EMcFarland; author: EMcFarland):

[integration/config@master] GrowthExperiments: Add CentralNotice as a dependency

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

Change #1275969 merged by jenkins-bot:

[integration/config@master] Zuul: [mediawiki/extensions/GrowthExperiments] Add CentralNotice dependency

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

Mentioned in SAL (#wikimedia-releng) [2026-04-23T12:56:32Z] <James_F> Zuul: [mediawiki/extensions/GrowthExperiments] Add CentralNotice dependency, for T422082

Thank you @Krinkle for the feedback. Few thoughts:

Where are CentralNotice banners inserted?

On the client side, in extensions/CentralNotice/resources/ext.centralNotice.startUp/index.js (this would make it possible to make use of JavaScript hooks instead, doing all of this on the client side instead). At first, this adds div#centralNotice to the page (currently, as a child of #siteNotice). Later on (in extensions/CentralNotice/resources/ext.centralNotice.display/index.js), CentralNotice adds its own HTML into the div#centralNotice.

Or, use SiteNoticeBefore to disable sitenotice/anonnotice first, because CN isn't the only issue, right?

Unfortunately, this is not really an option. When there is no site notice, Skin::getSiteNotice() returns an empty div. CentralNotice then locates that empty div and adds its own stuff there (after everything has been sent to the browser already). SiteNoticeBefore cannot be used to not add the div#siteNotice element into the page at all.

In theory, we can change that, and introduce a hook that would control the full output of Skin::getSiteNotice(), allowing us to get rid of the wrapping div. At that point, CentralNotice would still run something like $( '#centralNotice' ).prepend( ... ) to add the banner (and it would consider that as an impression internally), but no banner would be shown. However, given it would mislead CentralNotice's impression numbers, I'm not sure if that is a good idea.

It might also be possible to (somehow) set wrapSiteNotice to false (in skin options); maybe there is a hook already for that. However, that would have the same issues as described above.

That being said, it is a good point that CN isn't the only possible source of the problem, but as far as I can see, it would need to be resolved independently, unfortunately.

Could this Growth widget be put into the correct place above this space, instead of below it?

The location is not the only problem. Certain central notice banners are widening the sitenotice space beyond what it usually is, causing the Growth widget point to an incorrect place. We might want to hardcode the size of the widget into our code though :).

Have we hid site notices before in Wikipedia's history?
Assuming yes, how is this usually done?

I'm not aware of any such attempts. Happy to learn about them though!

What mechanism might CentralNotice already offer for this?
What mechanism might MediaWiki core offer for this?

I'm not aware of any such mechanisms. The only two hooks that MW core has for sitenotices that I know about are onSiteNoticeBefore and onSiteNoticeAfter, neither of them impacts CentralNotice (mostly because CentralNotice constructs the banner HTML on the client side, not in PHP).

The more I think about it, the more I lean towards adding a banner choice client side hook to CentralNotice, which GrowthExperiments could then implement. But I'm curious about possible risks I might be overlooking here.

Change #1279311 had a related patch set uploaded (by Sergio Gimeno; author: Sergio Gimeno):

[mediawiki/extensions/GrowthExperiments@master] Hack: intercept CentralNotice startup by setting max campaigns to 0

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

Hi @Krinkle, thank you for the feedback. I discussed it with Martin in a 1:1 and wanted to follow up here, too.

Have we hid site notices before in Wikipedia's history?
Assuming yes, how is this usually done?

I did find an artifact that showed fundraising tech hiding Central Notice campaigns when it wasn’t 2023. https://meta.wikimedia.org/w/index.php?title=MediaWiki:FundraisingBanners/CoreJS-2018.js&diff=prev&oldid=26137440. This made me wonder if would be possible to hide the central notice using a javscript script, but I wasn’t able to make this approach succeed (so far).

I also tried to address the issue of the CentralNotice css interfering with the DiscoverySiteNotice css, which happened both when the CentralNotice was hidden and when the CentralNotice was placed below the DiscoverySiteNotice. I tried using the all css property (https://developer.mozilla.org/en-US/docs/Web/CSS/Reference/Properties/all) but did not succeed with this approach.

I am also curious what you think about Martin's suggestion of a banner choice client side hook. Please let us know if there are any issues that we might be missing. Thanks!

I agree a JS hook seems the least expensive solution to pursue. I gave it a try but there aren't obvious mechanisms to cancel a campaign. There's a promising "hook" in ext.centralNotice.display/index.js#133 that would cancel the banner display for a campaign. I tried to register one of this hooks, eg:

( function () {
	const preBannerHandler = function ( mixinParams ) {
		// Fail banner display
		if ( true ) {
			return;
		}
	};

	mw.loader.using( 'ext.centralNotice.startUp' ).then( () => {
		const cn = mw.centralNotice,
			mixin = new cn.Mixin( 'bannerSequence' );
		mixin.setPreBannerHandler( preBannerHandler );
		cn.registerCampaignMixin( mixin );
	} );
}() );

but I'm failing to always associate this hook with any attempted campaign.

In T422082#11871074, @EMcFarland-WMF wrote:

I did find an artifact that showed fundraising tech hiding Central Notice campaigns when it wasn’t 2023. https://meta.wikimedia.org/w/index.php?title=MediaWiki:FundraisingBanners/CoreJS-2018.js&diff=prev&oldid=26137440. This made me wonder if would be possible to hide the central notice using a javscript script, but I wasn’t able to make this approach succeed (so far).

I believe that worked because it was added to core and it run before CentralNotice startUp module.

I also found a hack to avoid the display in 1279311, the good thing is it vanishes after navigation, but I haven't reviewed if it has side effects in terms of impressions, other hide rules, cookie settings, etc.

I looked at Sergio’s patch and I don’t think it would interfere with impression data. Since the impressions are logged in extensions/CentralNotice/resources/ext.centralNotice.display/index.js in reallyRecordImpression, and since that script doesn’t run when wgCentralNoticeMaxCampaignFallback is set to zero, it shouldn’t be a problem.

Change #1280492 had a related patch set uploaded (by Sergio Gimeno; author: Sergio Gimeno):

[mediawiki/extensions/GrowthExperiments@master] GetStarted notice: prevent CentralNotice banners from showing

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

Change #1280493 had a related patch set uploaded (by Sergio Gimeno; author: Sergio Gimeno):

[mediawiki/extensions/CentralNotice@master] PoC: unconditionally register GrowthGetStarted mixin to all campaigns

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

I posted a PoC a bit more intentional that makes use of CentralNotice's mixins to cancel the banner display when in conflict with Growth's. I'm having trouble though finding the docs for CN's Campaign Mixins if there are any to clarify how "deprecated" are these, and if it's fine to use them internally, only I've found is https://www.mediawiki.org/wiki/Extension:CentralNotice/Banner_mixins_(deprecated), but that seems to refer to banners not campaigns.

A Campaign Mixin should be fine to use - those are not deprecated. The drawback of the wgCentralNoticeMaxCampaignFallback hack is that it will prevent us from recording a reason that the banner was not shown, so our pageview / impression ratio will be off.

In T422082#11884534, @Ejegg wrote:

A Campaign Mixin should be fine to use - those are not deprecated. The drawback of the wgCentralNoticeMaxCampaignFallback hack is that it will prevent us from recording a reason that the banner was not shown, so our pageview / impression ratio will be off.

Thanks for clarifying this, is there any additional documentation for mixins to https://www.mediawiki.org/wiki/Extension:CentralNotice/Notes/Campaign-associated_mixins_and_banner_history. Or some example? I'm looking to hard-code/configure a mixin for every campaign rather than something that user-facing configurable (mind I'm new to CentralNotice and still getting familiar with it's components). Ty!

Hmm, it would certainly be cleaner to have a real hook that other extensions could subscribe to. Let me see if I can add one of those.

Change #1282396 had a related patch set uploaded (by Ejegg; author: Ejegg):

[mediawiki/extensions/CentralNotice@master] Add centralNotice.chooseCampaign JavaScript hook

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

Change #1280493 abandoned by Sergio Gimeno:

[mediawiki/extensions/CentralNotice@master] PoC: unconditionally register GrowthGetStarted mixin to all campaigns

Reason:

Solved in Ia4d62c24b6fb8fcd9d62025959f1bf29ca4ae37f

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

In T422082#11887259, @Ejegg wrote:

Hmm, it would certainly be cleaner to have a real hook that other extensions could subscribe to. Let me see if I can add one of those.

Thank you for quickly providing the hook Elliot, I've updated my patch accordingly.

Change #1279311 abandoned by Sergio Gimeno:

[mediawiki/extensions/GrowthExperiments@master] Hack: intercept CentralNotice startup by setting max campaigns to 0

Reason:

this wouldn't record the reason for the failed impressions, re-worked in I528754db778267a7f8447c35f994b839145d984c

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

Change #1283709 had a related patch set uploaded (by EMcFarland; author: EMcFarland):

[mediawiki/extensions/CommunityConfiguration@master] [WIP] [DNM] NamespacesControl: Make filterSearchQuery case insensitive

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

Hi, please disregard Change #1283709, which was linked to this task. I had multiple phabricator tasks open and accidentally copied the wrong task into the Bug: field. My mistake.

Change #1272598 abandoned by Urbanecm:

[mediawiki/extensions/GrowthExperiments@master] CentralNoticeHooks: Add onCentralNoticeAfterChoicesHook

Reason:

in favour of the client-side approach

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

Change #1272666 abandoned by Urbanecm:

[mediawiki/extensions/CentralNotice@master] CentralNoticeHookRunner: Add CentralNoticeAfterChoicesHook

Reason:

in favour of the client-side approach

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

Change #1285504 had a related patch set uploaded (by Krinkle; author: Krinkle):

[mediawiki/extensions/CentralNotice@master] Move ext.centralNotice.startUp from onBeforePageDisplay to onSiteNoticeAfter

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

CentralNotice already disables itself server-side in onBeforePageDisplay when:

• If a special page
• If action=edit
• If action=history
• If a diff

I suggest we add to this one extra condition: If sitenotice is disabled.

Today, there is only one code path in production that disables the sitenotice, which is the CentralAuth extension (source) when logging-in on auth.wikimedia.org.

I suggest the GrowthExperiments extension adds a second case, the same way, by disabling the site notice in their specific case (which is right after account creation, when logging-in and first returning to the homepage, where they display their own welcome banner).

Note that the GrowthExperiments extension has to handle onSiteNoticeBefore either way, as otherwise the same bug described in this task will still happen with regular site notices.

Change #1286304 had a related patch set uploaded (by EMcFarland; author: EMcFarland):

[mediawiki/extensions/GrowthExperiments@master] [DNM] [WIP] HomepageHooks: Add onSiteNoticeBefore hook

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

Today, there is only one code path in production that disables the sitenotice, which is the CentralAuth extension (source) when logging-in on auth.wikimedia.org.

Hi, could you please help me to understand how the CentralAuth extension disables the sitenotice in the linked code? I did something similar in HomepageHooks onSiteNoticeBefore by setting siteNotice to equal an empty string and returning false, but it does not appear to disable the sitenotice. Thanks!

Change #1286887 had a related patch set uploaded (by Krinkle; author: Krinkle):

[mediawiki/core@master] Document and improve sitenotice hooks

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

Change #1286887 merged by jenkins-bot:

[mediawiki/core@master] Document and improve sitenotice hooks

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

Change #1286304 abandoned by EMcFarland:

[mediawiki/extensions/GrowthExperiments@master] [DNM] [WIP] HomepageHooks: Add onSiteNoticeBefore hook

Reason:

I am abandoning this work after a conversation with product and design

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

Change #1285504 abandoned by Krinkle:

[mediawiki/extensions/CentralNotice@master] Move ext.centralNotice.startUp from onBeforePageDisplay to onSiteNoticeAfter

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

Change #1282396 abandoned by Ejegg:

[mediawiki/extensions/CentralNotice@master] Add centralNotice.chooseCampaign JavaScript hook

Reason:

Not the proper solution, per Timo's code ordering comment

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