deactivating certain/all banner types at https://meta.wikimedia.org/wiki/Special:Preferences#mw-prefsection-centralnotice-banners doesn't seem to work as well.

fwiw, I can't replicate that issue — I have banners hidden via that (global) preference, and it works as expected.

On a secondary account (banners enabled, cookies allowed, localstorage cleared prior etc.), I visited https://en.wikipedia.org and clicked through around 30 articles.

No banners were displayed at any time.

The following key:value pairs were logged to localstorage:

CentralNoticeKV|global|impression_diet_AKI2023generalcookie

{"expiry":1709935727,"val":{"seenCount":5,"skippedThisCycle":0,"nextCycleStart":1679004523265,"seenThisCycle":5}}

CentralNoticeKV|global|impression_diet_wmftou2023cookie

{"expiry":1709935729,"val":{"seenCount":7,"skippedThisCycle":0,"nextCycleStart":1679004529294,"seenThisCycle":7}}

CentralNoticeKV|global|impression_diet_WLF2023Int

{"expiry":1709935703,"val":{"seenCount":2,"skippedThisCycle":0,"nextCycleStart":1678399702904,"seenThisCycle":2}}

CentralNoticeKV|global|impression_diet_IWD2023

{"expiry":1709935729,"val":{"seenCount":5,"skippedThisCycle":0,"nextCycleStart":1678802917725,"seenThisCycle":5}}

CentralNoticeKV|global|buckets

{"expiry":1684793280,"val":"AKI 2023 General!277628800!5270340!0*Wiki Loves Folklore 2023 International!275209600!7689540!1*International Women's Day 2023!277873600!4491000!1*WMF ToU 2023!276937600!7775940!0"}

Visiting a page logged out did display a banner (cn-WikiLovesFolklore2023International), and added the following localstorage:

CentralNoticeKV|global|impression_diet_WLF2023Int

{"expiry":1709936052,"val":{"seenCount":1,"skippedThisCycle":0,"nextCycleStart":1678400052220,"seenThisCycle":1}}

CentralNoticeKV|global|buckets

{"expiry":1682979252,"val":"Wiki Loves Folklore 2023 International!275209600!7689540!1"}

@Johannnes89 could you provide device, browser, OS information?

MacBook Pro 2017, macOs 13.2.1. I tried this with Safari Version 16.3 and Google Chrome Version 111.0.5563.64

We checked my cookie details in Chrome and while other wikimedia cookies were being set, there were no cookies related to any centralnotice banners.

This is happening to me constantly. I have all banners disabled except 'Maintenance' and 'Special'. I always visit Wikipedia logged in. I see at least a banner a day. Probably a lot more. Most recent one, a few minutes ago, was for Wikimania Singapore. It seems to also happen from Android, but for today's purposes, I'm reporting what I see from my Windows browser. I'm using a Surface Laptop 2, Windows 10 Home 21H1, and Firefox 110.0 (64-bit). I'm in the United States.

I just tried deleting the wikipedia cookie and logged in again. I immediately got 'Join us to Celebrate Women'! I confirmed my banner preferences were still set to only display 'Maintenance' and 'Special'. I will report back if the problem continues.

Edit: I went to https://en.wikipedia.org/wiki/Cheese . Got ''The Wikimedia Foundation is updating our Terms of Use.'

Went to 'Cheese' page again. Got 'Join us to Celebrate Women'! Again.

Went to 'Cheese' again. Got 'Wiki loves folklore'

Went to Cheese again. Got 'Wikimania Singapore'

Went to Cheese again. Got 'Wikimania Singapore'

Went to Cheese again. Got 'Africa Environment WikiFocus'

Went to Cheese again. Got 'Wikimania Singapore'

This is *worse* since I deleted my cookie and logged back in. I'm reliably getting a banner every singe pageload.

I'm using the Vector legacy (2010) skin.

Edit 2: I didn't realize I had to click the 'x' to make the banner go away, and stay away. Did that as I cycled through a few pageloads and the banners seem to have stopped. I will report back if they return.

Same happening to me. Banners shown on every single page load, causing layout shifts, even on projects where I disabled all banners via preferences. I just ended up adding

#siteNotice {
	display: none;
}

to my global.css because it was just too annoying.

Thanks so much everyone for your input and effort on this, and many apologies for the delay.

I did a bit of digging, and it looks like there may indeed be a new bug in user preferences for opting out of different types of campaigns.

I'll update the task and post details later today.

Thanks again!!!

Change 897969 had a related patch set uploaded (by AndyRussG; author: AndyRussG):

[mediawiki/extensions/CentralNotice@master] Fix test for opted out banner types

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

Change 897969 merged by jenkins-bot:

[mediawiki/extensions/CentralNotice@master] Fix test for opted out banner types

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

Heyyy here are some quick notes:

• I was able to reproduce this on production just by disabling banner categories in my preferences and seeing what happened. Not sure why you're not seeing any banners, @TheresNoTime.
• The fix turned out to be quite simple. It has been merged and placed on this week's deploy train. It should be deployed to most Wikipedias on Thursday, and to most other projects and a few Wikipedias on Wednesday.

Apologies for the delay in getting to this, and for not writing more details just now. (FR-Tech is rushing to get a new payments integration finished this week.) I'll try to find time later this week to explain more and reply to some comments above.
Thanks again!!

Thanks for the work Andy!

Thanks @AndyRussG for fixing the preference bug!

However, it's pretty like the case that the cookie problem (none are set) is still be there. Certainly, it's nice to disable some banner categories when you are annoyed, but we as CentralNotice administrators must have an option to limit banner displays by cookies oon any kind of campaign for any kind of display as it has been in previous years. And unlike regular developers we don't have the skills to add cookie scripts to the JavaScript section of the banners, as WMDE does with its fundraising as far as I know—and likely you too do instead of the function on the attached photo which we report to be broken. Can you also take a look at that? Thank you!

In T331671#8690787, @DerHexer wrote:

Thanks @AndyRussG for fixing the preference bug!

:)

However, it's pretty like the case that the cookie problem (none are set) is still be there. Certainly, it's nice to disable some banner categories when you are annoyed, but we as CentralNotice administrators must have an option to limit banner displays by cookies oon any kind of campaign for any kind of display as it has been in previous years. And unlike regular developers we don't have the skills to add cookie scripts to the JavaScript section of the banners, as WMDE does with its fundraising as far as I know—and likely you too do instead of the function on the attached photo which we report to be broken. Can you also take a look at that? Thank you!

Hi! Apologies again for the lack of time to reply more fully and explain stuff. Just briefly, I don't see any indications anywhere here that this feature is somehow not working.

This feature does not use cookies, but rather uses localstorage to keep count of the number of banners displayed per campaign (or per the specified identifier), per device, and per project. That is, the counts are separate for each device, and even each browser on the same device, and also per wiki. No cookies are set for this feature.

I just double-checked that the correct data is indeed being placed in localstorage, at least for me. I also had a look at recent banner impression data (note: for privacy reasons, only available if you signed an NDA and were specifically granted access) and I see a normal proportion of banners being hidden due to too many having been shown.

If you wish to verify that this feature is working, you could count how many banners you see from a given campaign on a specific device and wiki. You should only see the number of banners from that campaign indicated by the campaign's configuration settings, as in the form you sent a screenshot of.

Hope this is helpful, thanks again!! :)

@AndyRussG Thanks for the helpful explanations! :) Do you have any technical documentation about CentralNotice which would help CN administrators like me to better understand the system?

With almost all community campaigns set by me with 3 or 5 impressions per week, I'm pretty sure that I've seen each of them way more often than these times (and not just me). = ) Therefore, I'm glad that you've double-checked that the correct data is indeed being placed in localstorage as well as banner impressions. As this doesn't really match perceptions of me and other, I will take another look and actually start to count and get back to you in this ticket. Maybe @Johannnes89 can also help to check it. We will also look for more complaints onwiki, too.

It's also worth noting that localstorage is per site. So if a user is moving between different languages and projects, my understanding is they might see up to the impression limit on each of those sites.

@Pcoombe Yes, I sadly know. And in my opinion, I consider this a bug and not a feature. Many of us are active on more than one project and get annoyed by the same banners multiple times.

In T331671#8699130, @DerHexer wrote:

@Pcoombe Yes, I sadly know. And in my opinion, I consider this a bug and not a feature. Many of us are active on more than one project and get annoyed by the same banners multiple times.

Just to note, this is so because of browser privacy limitations. We don't plan to start storing more data about users on our servers, also for privacy reasons.

@AndyRussG Well, I haven't worked for years on SUL finalization as a volunteer when we don't use this for global settings (and we do so for other functionalities already!). ;)

Please consider moving CentralNotice from using local storage to some other kind of storage for global accounts. We already have that one global account, there is no change in privacy within this concept of one account per individual. However, I'm not an expert on browser privacy limitations so I don't know what's actually possible for global accounts wrt CentralNotice displays.

Just to confirm, the issue with user preferences not correctly hiding banners based on type: this part of the system now seems to be working as expected. Is anyone still experiencing this specific bug?

In T331671#8704189, @DerHexer wrote:

@AndyRussG Well, I haven't worked for years on SUL finalization as a volunteer when we don't use this for global settings (and we do so for other functionalities already!). ;)

Please consider moving CentralNotice from using local storage to some other kind of storage for global accounts. We already have that one global account, there is no change in privacy within this concept of one account per individual. However, I'm not an expert on browser privacy limitations so I don't know what's actually possible for global accounts wrt CentralNotice displays.

So, as with a lot of stuff, it can get complicated once you dig into the details. It's true that with cookies rather than LocalStorage there would be more opportunities for sharing cross-site (which in our case only means cross-project) data, though having lots of cookies for a site also causes a performance hit, which is why we specifically moved some stuff out of cookies and into LocalStorage some time ago (see T108849). Also, browsers' rules for how cookies can be shared across domains are themselves a moving target.

At the same time, there is a project being explored (T303075) to remove the banner bump, a longstanding source of annoyance. It'd be a huge project, and currently, as far as I know, we're still just at the stage of exploring feasibility. To make the proposed fix work, we would in fact have to move banner impression counts into a single cookie, which (I think! not positive...) could potentially open opportunities for sharing those counts across projects.

(I really don't think storing counts server-side for logged-in users would be feasible, and indeed could have privacy implications, though further discussion is of course fine if it seems important.)

Finally, I'd like to request, if possible, that separate tickets be filed for the various improvements that have been suggested here, including:

• Make counts for banner impression limiting apply across projects. (This could be a place to continue above discussions, as appropriate, if that's ok. :) )
• Show less banners generally.

Making these separate tasks would help us keep track of work and make it easier to follow conversations on these topics. Many thanks in advance!

See also: T332306 and T331890.

Thanks again!! :)

Hallo. For Tech News, please could you help draft a summary? If I understand correctly, something like this would be clear and accurate. (without bringing up the unconfirmed aspects, or confusions about cookies vs localstorage, that are also discussed above):

There was a problem with all types of CentralNotice banners still being shown even after turning off specific categories. This has now been fixed.

Please confirm, or amend that, within the next ~22 hours. Thank you!

Thanks @Quiddity! Certainly that's fine! Though it might also be clearer to mention that the settings to disable certain banner types are only available to logged-in users? What about something like this:

There was an issue with the banner system (CentralNotice). Logged-in users have the option to block banners by type, however these settings were being ignored, causing many users to see too many banners. This has now been fixed.

(Apologies for the extensive re-wording... Just an idea. Again, the original is also fine!)