Hi, @Aklapper I am not sure whether you really intended to change the scope of this task? Bundling in MW release is different from 'folding into core' which is what I proposed. A separate task can be made for bundling proposal, because in my view bundling in release is not worth it as the extension will still need to exist despite something in core depending on it to function properly.

@Ammarpad: You're right (of course). I guess the "bundle" in the task summary misled me; I tried to rephrase again.

Moving this into core does make sense to me, but I'd love to hear from a few other perspectives, particularly somebody explaining why we wouldn't move this to core (even if they are only acting as a devils advocate).

In the last few days, it became impossible to dismiss the site notice on projects like ru.wikivoyage.org and ru.wikimedia.org. Is this problem related to the current issue? Is it temporary, or needs special attention?

@Atsirlin please see T259858

Change 631177 had a related patch set uploaded (by Ammarpad; owner: Ammarpad):
[mediawiki/core@master] Provide native support to dismiss sitenotice in core (part 1).

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

In T259903#6374226, @Jdlrobson wrote:

Moving this into core does make sense to me, but I'd love to hear from a few other perspectives, particularly somebody explaining why we wouldn't move this to core (even if they are only acting as a devils advocate).

This may be a bit late, but here’s another perspective: why not do the other way round, i.e. remove all of sitenotice from core and move everything in the extension (and probably bundle the extension with MediaWiki)? This is a handy feature, but not crucial, I can imagine that many third-party wikis would never want to use it, especially ones that reach a very limited audience (like personal wikis running on one’s laptop, or intranet wikis). This is a well-defined, discrete function that is (hopefully) not interconnected with everything else. (The current status quo with functionality spread over the extension and core is far from ideal, though.)

Fun fact: this was originally done (rSVN41679) and reverted (rSVN41958) some 12 years ago.

Change 631177 merged by jenkins-bot:
[mediawiki/core@master] Provide native support to dismiss sitenotice in core.

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

next deploys would be undeploying the extension in January after confirming the transition has been seamless!

In T259903#6609737, @ashley wrote:

Fun fact: this was originally done (rSVN41679) and reverted (rSVN41958) some 12 years ago.

It would be nice to understand the reasoning that led to the current merger, and whether these concerns were considered, and e.g. why they no longer apply and/or how they can be mitigated afterwards and whether there is commitment to doing that prior to deployment and/or 1.36 release.

Change 654460 had a related patch set uploaded (by Krinkle; owner: Krinkle):
[mediawiki/core@master] Revert "Provide native support to dismiss sitenotice in core."

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

Change 654461 had a related patch set uploaded (by Krinkle; owner: Krinkle):
[mediawiki/core@wmf/1.36.0-wmf.25] Revert "Provide native support to dismiss sitenotice in core."

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

Change 654460 merged by jenkins-bot:
[mediawiki/core@master] Revert "Provide native support to dismiss sitenotice in core."

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

Change 654461 merged by jenkins-bot:
[mediawiki/core@wmf/1.36.0-wmf.25] Revert "Provide native support to dismiss sitenotice in core."

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

Mentioned in SAL (#wikimedia-operations) [2021-01-07T19:53:42Z] <urbanecm@deploy1001> Synchronized php-1.36.0-wmf.25/includes/skins/: rMW59866730ea75: Revert "Provide native support to dismiss sitenotice in core." (T271365; T259903; 1/3) (duration: 01m 04s)

Mentioned in SAL (#wikimedia-operations) [2021-01-07T19:55:01Z] <urbanecm@deploy1001> Synchronized php-1.36.0-wmf.25/resources/: rMW59866730ea75: Revert "Provide native support to dismiss sitenotice in core." (T271365; T259903; 2/3) (duration: 01m 05s)

Mentioned in SAL (#wikimedia-operations) [2021-01-07T19:56:27Z] <urbanecm@deploy1001> Synchronized php-1.36.0-wmf.25/includes/DefaultSettings.php: rMW59866730ea75: Revert "Provide native support to dismiss sitenotice in core." (T271365; T259903; 3/3) (duration: 01m 03s)

In T259903#6726908, @Krinkle wrote:

It would be nice to understand the reasoning that led to the current merger, and whether these concerns were considered, and e.g. why they no longer apply and/or how they can be mitigated afterwards and whether there is commitment to doing that prior to deployment and/or 1.36 release.

The dismissable sitenotice system is not great but obviously better than non-dismissable site notices. Since it wasn't improved in the last 12 years, I don't think waiting some more so maybe it gets improved makes sense.
(Well, it's not entirely true, the "spite the anons" thing has been fixed in 1.26. Still...)

In T259903#6374226, @Jdlrobson wrote:

Moving this into core does make sense to me, but I'd love to hear from a few other perspectives, particularly somebody explaining why we wouldn't move this to core (even if they are only acting as a devils advocate).

I think the main concern would be that maybe other wikis solved dismissability of site notices in other ways (including possibly via gadgets / site scripts) and this could break that. So probably we should review Category:SiteNoticeAfter extensions and reach out to the non-Wikimedia MediaWiki forums.

Also, in case someone relied on non-dismissable site notices (there are reasonable use cases for that, e.g. important legal text), is that still going to be possible?

In T259903#6600300, @Tacsipacsi wrote:

This may be a bit late, but here’s another perspective: why not do the other way round, i.e. remove all of sitenotice from core and move everything in the extension (and probably bundle the extension with MediaWiki)?

While a reasonable approach in theory, I'd expect it to be way more work than worth it. Site notices have been around for a decade and a half; a bunch of extension rely on them and would require introducing extension dependencies which is not super well supported in MediaWiki's extension framework (including that basically all skins would have to depend on the extension, or we'd have to keep some abstraction of notices in core which wouldn't be all that different from the full thing); lots of documentation would have to be updated or would become incorrect; it would take lots of outreach to do it without creating a poor upgrade experience.

In T259903#6729784, @Tgr wrote:

In T259903#6600300, @Tacsipacsi wrote:

This may be a bit late, but here’s another perspective: why not do the other way round, i.e. remove all of sitenotice from core and move everything in the extension (and probably bundle the extension with MediaWiki)?

While a reasonable approach in theory, I'd expect it to be way more work than worth it. Site notices have been around for a decade and a half; a bunch of extension rely on them and would require introducing extension dependencies which is not super well supported in MediaWiki's extension framework (including that basically all skins would have to depend on the extension, or we'd have to keep some abstraction of notices in core which wouldn't be all that different from the full thing); lots of documentation would have to be updated or would become incorrect; it would take lots of outreach to do it without creating a poor upgrade experience.

I see, so it is interconnected with everything else. Apart from keeping core as small as reasonably possible, I don’t see any strong argument against merging in core, so in this case let’s do this way.

We already broke this in desktop improvements, because the code as currently set out divided between extension and core is not very easy to maintain. It's my preference this is in core, as it seems like a useful, commonly used and important feature and I think the code will get more love if in core.

Longer term this also helps us with T259955.

Was just looking in DSN for a on-wiki discussion - not sure if these should be their own tasks - but if this isbeing overhauled: the "dismiss id" currently seems to only store 1 value, and is not in line with the documentation about needing "incrementing" values. Possible improvements to move from cookies to LSO; and that an array of dismissed values should be stored (currently it seems only one value is stored in a cookie.

Storing all dismissed notices doesn’t seem like a good idea – local storage doesn’t expire (as far as I remember, this is why we don’t use local storage a lot), and neither do cookies if they’re regularly updated by adding more and more dismissed notices. So the number of remembered IDs should be limited, I don’t think it makes sense to store more than 5 or 10 IDs.