As reported by a user on huwiki, the WP25EasterEggs setting link is still present on mobile (signed out) view. The issue cannot be reproduced on desktop (example article)
Screenshots
Description
Description
Related Objects
Related Objects
Event Timeline
Comment Actions
I also noticed this. Adding any query string (e.g. https://hu.wikipedia.org/wiki/Kossuth_Lajos?x) makes the link disappear, and without the query string, the browser console shows a warning Skipped unavailable module ext.wp25EasterEggs, so I’m pretty sure it’s a caching issue. The extension shouldn’t have been undeployed before the HTML caches expire (if I understand https://wikitech.wikimedia.org/wiki/CDN#Retention correctly, 14 days).
Comment Actions
Yes it will take up to 14 days to disappear entirely from the site. This is expected and how our cache works. You can purge a page with action=purge to manually speed up this prroces.
Comment Actions
I know that the presence in the HTML is expected. However, this link used to be hidden by https://gerrit.wikimedia.org/r/plugins/gitiles/mediawiki/extensions/WP25EasterEggs/+/refs/heads/master/resources/ext.wp25EasterEggs/style.css before the extension got disabled in T422548: Deployment: Disable the config flag for extension:WP25EasterEggs – the unexpected part is the link actually appearing on screen. (We could try mass-purge all pages on all Wikipediae, but that would likely bring down wikis.)
Comment Actions
IMO this should have been something that was worked-around/prevented in some way prior to undeployment (either by not having disabled the extension just yet, as @Tacsipacsi suggests, if that would have prevented this; or by some other means).
IMO it looks (at least) a bit messy to have a random link to "Birthday mode (Baby Globe) settings" appearing at the top of some articles on mobile, especially as (a) it's now not clear to readers what this link is actually relating to (given that it doesn't now relate to any enabled feature), & (b) the link's styles seem to now just default to it appearing in the top-left corner of the page (with e.g. not enough padding for it to appear neatly, compared to the other elements on the page).
For one thing, I guess this just strikes me as a preventable, sub-ideal experience for readers.
If it is too late to do anything to resolve this for now (prior to the relevant caches expiring, assuming that would automatically fix this), I hope the Readers teams can/will take the points raised here as feedback for the future. cc @Jdlrobson-WMF @Jdrewniak (as a couple of Readers team members that I'm aware of)
Comment Actions
Thanks for raising this issue. As Jon points out, this is an unfortunate side-effect of how our caching it set up, which makes it difficult to ship features to anonymous users generally. We ran into similar issues with dark-mode, e.g. T373495 but this has been a topic of conversation for much longer than that, e.g. T124954#2404883
the reason that this cache mismatch happens is that MediaWiki sends a Last-Modified header based solely on when the article was last edited, ignoring things like skin/gadget/preference/communityConfig changes, whereas ResourceLoader (which sends the JS and CSS) has a cache lifetime of only about 10 minutes. The rationale for basing the Last-Modified header only on the articles last-edited date is that, there is a multitude of sources that can modify the html, and calculating those changes across all sources would be prohibitively expensive from a performance perspective (if not impossible).
Could we have done more to prevent this in this scenario? Perhaps, there are only about 2,500 pages with baby globe across 28 wikis, so in this specific situation, we could potentially target only those pages for a cache purge. However, every time this type of problem appears, we have to weigh the cost of developing a tailored solution against the 14 days that it takes for the issue to resolve itself, and more often than not, we choose to wait it out. I agree it doesn't look great, but: 1. The issue affects a very limited number of pages, 2. It doesn't obstruct the reading or editing experience. Because of that, we can't justify prioritizing a fix here and have to decline this ticket instead, unless someone can provide a more urgent justification (e.g. unable to read an article because of this issue, it affecting all pages etc.).
As Jon suggests above, appending ?action=purge to the url and purging the cache can resolve the issue on a page-by-page basis.