In T351024#9324881, @Ammarpad wrote:

It depends on how you're making the request.

https://commons.wikimedia.beta.wmflabs.org/w/api.php?action=help&modules=query%2Bdeletedrevisions
The value must be between 1 and 5,000.

You're seeing this because you're probably doing this request while logged in (which uses your apihighlimits right)

Without content: https://commons.wikimedia.beta.wmflabs.org/w/api.php?action=query&prop=deletedrevisions&drvslots=*&drvlimit=5000&titles=User:AJ/move1&drvprop=ids|timestamp|flags|comment|user
With content: https://commons.wikimedia.beta.wmflabs.org/w/api.php?action=query&prop=deletedrevisions&drvslots=*&drvlimit=5000&titles=User:AJ/move1&drvprop=ids|timestamp|flags|comment|user|content

And then you're doing this while logged out (or with less privileged account)?

Cryptic mailed the missing pages again and this time they arrived. So I don't think it was a filter.

@jcrespo thanks for letting me know. I misunderstood Bawolff's comment.

https://en.wikipedia.org/wiki/Wikipedia:Village_pump_(proposals)#RfC:_Increasing_the_maximum_size_for_uploaded_files

https://archive.org/details/Scotichronicon was extracted from 4K video. The text is readable but not particularly sharp. This is the only digital version of the Scotichronicon in existence as far as I know, and it exists by virtue of CGP Grey including a time-lapse in one of his videos where he shows himself turning the pages as he searches the book for a name. If the original video had been 8K120 there would be fewer missing pages and the text would be crisper. If it had been 1080p.. woof.

In T344605#9306930, @Tgr wrote:

In T344605#9305651, @AlexisJazz wrote:

Recently some files were uploaded to betacommons. It had been quiet for a while.

It had been quiet for a while because of T340908: Unable to upload files on Beta Commons.

That task was filed in July 2023 but the last upload before that was in December 2022. But maybe it was broken the whole time.

Adding some recent uploaders from betacommons who might have been confused by the lack of thumbnails.

Recently some files were uploaded to betacommons. It had been quiet for a while.

Taking a shot in the dark: maybe in the transition from Phabricator to Phorge (or some other major change, but this was relatively recent) one of the servers didn't get the memo, so if the loadbalancer sends you to that server you get the error, but it resolves when you refresh the page as the loadbalancer takes you elsewhere?

In T344465#9277046, @MNeisler wrote:

@ppelberg I've checked and confirmed that events are being logged as expected in VisualEditorFeatureUse. See summary of checks and some initial data counts below:

The data below reflects all editing sessions where an edit notice was shown (feature: notices, action: show) from 11 October through today:

• Events logged on both desktop and mobile web platforms following 11 October deployment:

Are these numbers for all projects and languages combined, minus those that use ENOM?

I want to test an issue but can't do it properly because beta cluster has no thumbnailer. I could perhaps test locally, but I'd rather test on beta cluster.

In T307337#9252080, @matmarex wrote:

The message is removed, but I didn't try to do anything about the information leak.

In T348605#9242633, @TheDJ wrote:

Likely a cache invalidation issue. This is master, so the urls change all the time (after each commit and merge basically). The current url for me was: https://doc.wikimedia.org/mediawiki-core/master/js/data-09e2f9d739eec7e7f66a57691ce0b97d.js

If you have an older index.html cached somewhere, than it might try to load the old javascript url, and that might not be available any longer.

This is duplicate with T257188: MediaWiki JS documentation on doc.wikimedia.org loads infintely, shows "TypeError: Docs.data is undefined"

@Aklapper I figured anyone could reproduce this easily. Okay, here's the console info for Firefox 102:

Loading failed for the <script> with source “https://doc.wikimedia.org/mediawiki-core/master/js/data-09ee2e87d700cdcc44f40c7e47fc8718.js”. js:16:1
Uncaught TypeError: Docs.data is undefined
    <anonymous> https://doc.wikimedia.org/mediawiki-core/master/js/app-0c945a27f43452df695771ddb60b3d14.js:1
app-0c945a27f43452df695771ddb60b3d14.js:1:87592
Content Security Policy: The page’s settings blocked the loading of a resource at https://fonts.googleapis.com/css?family=Exo (“style-src”).

Firefox 118 (zero addons):

Loading failed for the <script> with source “https://doc.wikimedia.org/mediawiki-core/master/js/data-09ee2e87d700cdcc44f40c7e47fc8718.js”. js:16:80
Uncaught TypeError: can't access property "localStorageDb", Docs.data is undefined
    <anonymous> https://doc.wikimedia.org/mediawiki-core/master/js/app-0c945a27f43452df695771ddb60b3d14.js:1
app-0c945a27f43452df695771ddb60b3d14.js:1:87592
Content-Security-Policy: The page’s settings blocked the loading of a resource at https://fonts.googleapis.com/css?family=Exo (“style-src”). js:404:13

Chromium 108:

GET https://doc.wikimedia.org/mediawiki-core/master/js/data-09ee2e87d700cdcc44f40c7e47fc8718.js net::ERR_ABORTED 404
app-0c945a27f43452df695771ddb60b3d14.js:1 Uncaught TypeError: Cannot read properties of undefined (reading 'localStorageDb')
    at app-0c945a27f43452df695771ddb60b3d14.js:1:87605
(anonymous) @ app-0c945a27f43452df695771ddb60b3d14.js:1
(index):404 Refused to load the stylesheet 'https://fonts.googleapis.com/css?family=Exo' because it violates the following Content Security Policy directive: "style-src 'unsafe-inline' 'self'". Note that 'style-src-elem' was not explicitly set, so 'style-src' is used as a fallback.

Chromium 116:

GET https://doc.wikimedia.org/mediawiki-core/master/js/data-09ee2e87d700cdcc44f40c7e47fc8718.js net::ERR_ABORTED 404
app-0c945a27f43452df695771ddb60b3d14.js:1 Uncaught TypeError: Cannot read properties of undefined (reading 'localStorageDb')
    at app-0c945a27f43452df695771ddb60b3d14.js:1:87605
(anonymous) @ app-0c945a27f43452df695771ddb60b3d14.js:1
(index):404 Refused to load the stylesheet 'https://fonts.googleapis.com/css?family=Exo' because it violates the following Content Security Policy directive: "style-src 'unsafe-inline' 'self'". Note that 'style-src-elem' was not explicitly set, so 'style-src' is used as a fallback.

In T175512#9236896, @Don-vip wrote:

I can't get a working thumbnail for https://commons.wikimedia.org/wiki/File:Center-Filled_LIMA.jpg

I always face http 429 errors but I'm pretty sure it has nothing to do with the actual error. Example:

Request from 2a01:e0a:4e5:6b30:51ca:c1ac:4415:a99d via cp6001 cp6001, Varnish XID 234078745
Upstream caches: cp6001 int
Error: 429, Too Many Requests at Mon, 09 Oct 2023 20:19:11 GMT

In T307337#9233873, @Tgr wrote:

Yes this is safe (T59081: Privacy: User names shouldn't be exposed outside domain (CentralAuth)). Although it does leak the fact that you are centrally logged in on Wikimedia to some unspecified account, not sure how concerning that is

I'm unsure. I don't know if it would be a problem legally (GDPR and other privacy laws). Advertisers (that includes Google) may value knowing whether any given individual has a Wikimedia account, as some product categories are probably easier/harder to sell to Wikimedians. Some thought should be given to China given https://en.wikipedia.org/wiki/Wikimedia_censorship_in_mainland_China.

In T312587#9233011, @DLynch wrote:

Okay, it's because my beta-account is using mobile VE, and this only happens in wikitext mode.

This is because the path taken to create the edit notices is different between the modes -- EditorGateway's getContent method is only called in SourceEditorOverlay, and it filters the API response different from VE's methods. Specifically, the VE API filters out editnotice-notext (and editpage-head-copy-warn, but that's not relevant here), which is the message that's appearing here.

editnotice-notext is an edit notice that's set when no other edit notices are set for the page. It's empty by default, but a bunch of wikis have made it not-technically-empty but instead hidden by CSS. We should probably filter it out just like the VE API does, honestly.

From the code comments: "// The contents of an edit notice is unlikely to change in the 24 hour expiry window, so just record that a notice with this key has been shown." I think this was written by @Esanders?

@DLynch try opening the link in a new private/incognito window, because I can reproduce that one too. Both in Firefox and Chrome.

In T312587#9231785, @Ryasmeen wrote:

@Esanders : I checked this on patchdemo and Beta cluster, the modal looks good for pages that have edit notices on them. However, for every page that does not have any edit notice, the modal is still appearing with an empty alert.

In T312587#9221655, @DLynch wrote:

QA testing note: because of the throttling of notices, you'll either need to find a new page with a notice to test each time you look at it, or you'll need to run localStorage.clear() in your browser console before loading the editor.

In T312587#9209218, @Quiddity wrote:

@ppelberg I think we might need to rework that a bit. Ideally a Tech News item would primarily link to a translatable documentation page (not to Enwiki)

I just created https://meta.wikimedia.org/wiki/EditNoticesOnMobile which could be made translatable I think.

In T304073#9161657, @Umherirrender wrote:

See also T270057 for a way to get the current expiry in the browser

In T346115#9164332, @Nux wrote:

Did you ever thought of using NodeJS?

You could keep some of your code, but do it in an automated manner. You can loop over many pages to gather data and save locally (as files or in DB).
Then deploy this to Wikipedia in a simple script.

I've recently discovered this JS module for doing API request to MediaWiki: MWN JS library.

Saving things back to Wikipedia can be done either directly with MWN or if you generate file then you can use WikiployLite which kind of makes thing easier (you only provide configuration for that). When you use either of those methods you can use a local Jenkins installation that just runs your scripts on certain time.

You can find an example of how to use MWN here:
https://github.com/Eccenux/wiki-wd-mass-modyfication/blob/b1f8e19c89c17eed1a68bbea255a2d5b41378b96/runBot.js

You'll find that WikiBotLite is even a thinner layer over MWN then WikiployLite is:
https://github.com/Eccenux/wiki-wd-mass-modyfication/blob/b1f8e19c89c17eed1a68bbea255a2d5b41378b96/src/WikiBotLite.js

This was the original task description before Aklapper replaced it with the log :

In T344999#9169383, @Aklapper wrote:

Thus I will be helpful once more and reopen this task to allow for more input.

I'd still decline this as input seems to have been provided...

In T344822#9147204, @SBisson wrote:

In T344822#9147119, @AlexisJazz wrote:

I reported this over a year ago, but um sure I guess.

If you do fix it the Wikistories will actually break completely due to T344605.

Thanks for letting us know. We'll wait for a fix there before switching our config to the beta Commons.

You might find running https://en.wikipedia.org/wiki/User:Alexis_Jazz/EverybodyLikesPie.js to be of some help on these projects. See https://it.wikisource.org/w/index.php?title=Utente:Alexis_Jazz/Sandbox&oldid=3227820 for example.

@Nux Thanks, it works now. :-)

I suppose an alternative option would be some additional "extend-expiry-but-don't-overwrite-indefinite-watching" parameter added to everything, but I imagine that'd be far more confusing.

I filed T304073 for that. (which didn't exist yet when this ticket was opened)

I made a proof of concept: https://en.wikipedia.org/wiki/User:Alexis_Jazz/EverybodyLikesPie.js

In T345960#9159886, @Aklapper wrote:

@AlexisJazz: Please stay on-topic. Random past board or ban stuff has nothing to do with guiding site admins about technical issues. This is not a forum. Thanks!

In T345960#9158596, @Jdlrobson wrote:

The key bit of information in this task description is We should be doing more to guide site admins on when they are introducing performance/SEO problems to the site. (key word "guide" not prevent :-))

For a single library that is loaded by many users as it's required for VE I think those are some nice savings on both traffic and localStorage. Thank you. :-)

In T345960#9154974, @Izno wrote:

In T345960#9154958, @AlexisJazz wrote:

The developers are in for a world of hurt if CommRel doesn't get involved in this.

I think you're mischaracterizing this task. It's only to know and provide info on, not to do anything listed in "Future uses". Some of the items in that list likely have some communications desirability and working through with communities, but being able to provide numbers to users seems like a reasonable thing to do without any particularly adverse impact.

In T345960#9154923, @Aklapper wrote:

This task does not look like a task requesting support from CommRel-Specialists-Support

If it's possible to check this quickly on edit

I can't reproduce this anymore on betacommons so seems good to me. :-)

In T111565#9141090, @Msz2001 wrote:

In T111565#9141088, @matmarex wrote:

In T111565#9139046, @Msz2001 wrote:

It's worth noting that mobile MediaWiki already supports collapsible class, which is almost the same as mw-collapsible in appearance.

That doesn't work for me. I don't think it's a MediaWiki feature, but it's a fairly common on-wiki customization (older than mw-collapsible).

Ah, appears that you're right. I must have missed the on-wiki code that supports it.

I reported this over a year ago, but um sure I guess.

In T340705#9006917, @Jdlrobson wrote:

In T340705#8986782, @stjn wrote:

I have added targets=desktop to some gadgets because I was receiving reports from users and seeing some errors in consoles after this change, and now I have to ask: what to do, for example, about https://ru.wikipedia.org/wiki/MediaWiki:Gadget-collapserefs.js if targets=desktop goes away? Like, I would be perfectly fine with throwing it away entirely, but since I don’t have that power, outside of that: it is a gadget that allows some users to collapse references by default. It doesn’t make sense to have it in mobile Minerva since it collapses all sections, but people can use desktop Minerva and expect this gadget to be there. Unless we’re giving up on the plan to remove targets=desktop, of course, then disregard my comment.

@stjn in the case of https://ru.wikipedia.org/wiki/MediaWiki:Gadget-collapserefs.js I would suggest limiting it to Minerva skin. Very few people use desktop Minerva and I doubt those that do would care for this gadget.

In T343131#9140322, @Ladsgroup wrote:

One new and easy low-hanging fruit:

Remove template styles for Template:Information and cc-by-sa license: https://commons.wikimedia.org/wiki/Module:Information/styles.css and https://commons.wikimedia.org/wiki/Template:Cc-by-sa-layout/styles.css
Move them to common.css instead.
Why?

Yeah, why not https://commons.wikimedia.org/wiki/MediaWiki:Filepage.css ?

For individual cases/articles, navboxes (and other templates that mobile users are normally excluded from) can be forced using https://en.wikipedia.org/wiki/Template:Strip_nomobile.

In T111565#9137021, @matmarex wrote:

As there are people opposed to making this change in MediaWiki core, I would suggest doing it in your wiki's MediaWiki:Common.js or a gadget, as long as your community finds that agreeable.

@Tossrock while this seems already solved, for future reference you can use !important to override style-defined attributes. For example:

.sidebar-collapse{background:blue !important}'

In T111565#9135498, @Izno wrote:

In T111565#9135467, @AlexisJazz wrote:

I can't find the relevant comment, but this is deemed to be an insufficient UX on touchscreens by the WMF devs.

You're probably looking for the patch commentary in https://gerrit.wikimedia.org/r/c/mediawiki/skins/MinervaNeue/+/859605/ . It's the only place I've seen an objection along this line in recent times.

TBH I'm in the party of "the perfect is currently being the enemy of the good" regarding allowing things to be collapsed. I get the concern regarding button size, but OTOH I don't see it as major enough to block the enhancement that collapsing things brings.

In T111565#9135136, @Msz2001 wrote:

Hi! What's the status of this task now? Some time ago ResourceLoader modules became targetted at desktop,mobile by default and it appears that running the following line in the browser console on a mobile version works as intended:

mw.loader.using('jquery.makeCollapsible').then(() => $('.mw-collapsible').makeCollapsible());

Tested at: https://m.mediawiki.org/wiki/Manual:Collapsible_elements/Demo/Advanced

In T312587#9130294, @Esanders wrote:

EditNoticesOnMobile and edit notices in VE on desktop provide this button

For ENOM the button is only visible on tablet-width devices, so the vast majority of users don't see this button. I don't think this is a problem.

In T344999#9121843, @RhinosF1 wrote:

I suspect UBN! wouldn't have been appropriate as I think (but I could very well be wrong) that only applies to considerable issues on production.

Anything that blocks the train is unbreak now

In T344999#9121700, @abi_ wrote:

Thank you @AlexisJazz for reporting the issue in question (T344635). I want to apologize for dropping the ball on that ticket.

When I reviewed the ticket, I immediately made the assessment that the issue is severe, triaged it as high priority and submitted a fix for it. I was not sure about marking at as UBN!, and a train blocker, but went ahead and submitted a back-port patch in case someone judged that it was a train blocker. Looking back, I should have marked it a train blocker and back-ported it. Note to self: when in doubt, err on the side of caution, make noise and get multiple inputs.

I do not have a lot to add to the current discussion, the processes that come to my mind are a bit redundant to what we already have. In general, I think It would be nice to have more eyes on high priority bug reports after group0 deployment in order to reduce the impact of error in judgements.

In T344999#9120985, @Aklapper wrote:

so why didn't YOU tag T344635 as a train blocker? As you see, playing the blame game is easy, but it doesn't help anyone.

Either nobody realized that it should have been marked as a train blocker, or nobody considered it a train blocker given human judgement at that point in time.
I tried to explain above how anyone who thinks an issue might be a train blocker could mark it as such regarding current workflows.

Personally, I didn't realize it. I have a lot on my mind, am unpaid (it's unreasonable to hold me to the same standards as the paid workforce) and the workflow is not intuitive.

In T344999#9120647, @Aklapper wrote:

Unlike you, I'm not getting paid so telling me how I should work, especially when it's not particularly intuitive, is unlikely to pay off.

Sure. That's why I pointed out existing workflows, and not using existing workflows definitely won't pay off either... :-/

In T344999#9120614, @Aklapper wrote:

and it clearly didn't help.

We won't fix either a social or a workflow problem by introducing competing workflows. :) Thus declining.

In my understanding, going to Edit Related Tasks... and selecting Edit Parent Tasks is the workflow to mark an issue as a train blocker, after looking up the current train task ID.

In T344999#9120584, @taavi wrote:

How would this be different from Beta-Cluster-reproducible?

In T344680#9111471, @Aklapper wrote:

(For the records, I once created T279421: Update Vue and Codex documentation for WMF staff and community developers about the insufficient documentation and communication at that time.) Its original title was Document and communicate status of Vue things (Codex) and future of OOUI, WVUI, etc.

In T344704#9109942, @Johannnes89 wrote:

Note: Multiple dewiki users were reporting a similar problem regarding the IP 10.80.1.7 which also doesn't belong to those users (same /28-range as 10.80.1.11)
https://de.wikipedia.org/w/index.php?title=Benutzer_Diskussion:XenonX3&oldid=236646961#Nutzersperre

https://en.wikipedia.org/w/api.php?action=query&meta=userinfo&callback=&format=json&formatversion=2 now returns my actual IP. Thanks for the quick response!

I'm no longer blocked as on https://en.wikipedia.org/wiki/Special:Contributions/ST47ProxyBot this message can be read:

Forgot to mention: error happens both when logged in and not logged in.

In T312587#9106636, @DLynch wrote:

I don't think we can expect our users, especially on mobile devices, to open the browser console and enter a command to view the notice again

Oh, sorry, I thought you were just asking for testing purposes on the patchdemo.

This link is unrelated to my question, correct?

I might need some clarification as to what your question was, in that case?

In T312587#9106278, @DLynch wrote:

The patchdemo has no way to view the notice again after dismissing it, is this correct?

@AlexisJazz you could run localStorage.clear() in the console.

@ppelberg https://phabricator.wikimedia.org/rMEXTd046bc1d44faf877e2e71cd7f46b20371ef04e32 : "Won't show an edit notice with the same key on the same page for 1 day after it has been seen." is that it?

https://phabricator.wikimedia.org/rMEXTd046bc1d44faf877e2e71cd7f46b20371ef04e32 : " Edit notices are not shown if the user has the EditNoticesOnMobile gadget enabled."

In T341421#9104612, @Tacsipacsi wrote:

In T341421#9104345, @AlexisJazz wrote:

Maybe related to the changes made in T328610 ?

Yes, I think so.

In T341421#9000004, @AlexisJazz wrote:

You could use targets=desktop instead which has nearly the same effect.

“Nearly the same effect” includes causing this bug since 8af75aa…

Maybe if the gadget is unavailable due to the current skin/target, the option should be disabled rather than hidden? It would show some gadgets that are planned for non-default skins and thus irrelevant for most people, though.

Or don’t show all gadgets unavailable due to the current skin, but do show gadgets that are, while unavailable on the current skin, are available on the skin set in the preferences (which is Vector even when using the mobile domain), and show gadgets regardless of their target settings (the target setting should go away soon anyway).