In T299724#7640650, @Umherirrender wrote:

starttimestamp is to detect conflicts with page deletion and avoids recreation of the page if deleted in the meantime
basetimestamp/baserevid is used for edit conflict detection and avoids override of the page content if edited in the meantime

In T299724#7638969, @matmarex wrote:

I think the intended usage is to specify both starttimestamp and basetimestamp:

• starttimestamp is the timestamp of when the user opened the editor, you can ask MediaWiki for the current time by adding &curtimestamp=1 to any other query, example (this avoids dealing with timezones, time formatting, and unsynchronized clocks between the client and server)
• basetimestamp is the timestamp of the latest revision of the page at the time when the user opened the editor, obtained from the prop=revisions query (you can get the page wikitext using the same query)

Note that basetimestamp is almost-but-not-quite deprecated (T58849), and baserevid should be used instead.

api.postWithEditToken( {
format: 'json', title: 'User_talk:AJ-test', action: 'edit', summary: 'test', text: '==section test 1==\ntest barfoo8 this edit has a basetimestamp and starttimestamp of 2022-01-20T22:56:34Z', starttimestamp: '2022-01-20T22:56:34Z', basetimestamp: '2022-01-20T22:56:34Z'
} )

Yeah, that got rejected as an edit conflict!
Okay. If you don't mind me asking: why do starttimestamp and basetimestamp exist and why would both be required? If you have basetimestamp, you could just throw starttimestamp away. If you have starttimestamp, you could simply look for the last revision that predates starttimestamp. The only point of that is to avoid making a request to obtain the actual revision ID/time. But if starttimestamp doesn't work without basetimestamp, what's the point anyway?

var api = new mw.Api();
api.postWithEditToken( {
format: 'json', title: 'User_talk:AJ-test', action: 'edit', summary: 'test', text: '==section test 1==\ntest barfoo7 this edit has a basetimestamp of 2022-01-20T22:56:34Z', basetimestamp: '2022-01-20T22:56:34Z'
} ).done( function ( data ) {
} );

Result: https://commons.wikimedia.beta.wmflabs.org/w/index.php?title=User_talk:AJ-test&diff=258468&oldid=258467

There is https://www.wikidata.org/wiki/Q19754486 (Template:Photo of art / Template:Licensed-PD)

In T68606#7624720, @AdamCuerden wrote:

I should probably give an example, to show the problem is widespread.

https://en.wikipedia.org/wiki/Wilkinson_Call#/media/File:Wilkinson_Call_-_Brady-Handy.jpg

Two creators, Media Viewer strips one from the list.

@Nardog I did a quick search and found https://en.wikipedia.org/wiki/User:Nardog/IPAInput-core.js and https://en.wikipedia.org/wiki/User:Ykhwong/Gadget-tabPreview.js that include "aria-disabled" and some OOUI stuff. Don't know if either will be affected though.

In T293959#7621695, @matmarex wrote:

Risky Patch! 🚂🔥

• Change: https://gerrit.wikimedia.org/r/753557 Update OOUI to v0.43.0
• Summary: OOUI v0.43.0 is an unusually big release, with an unusual amount of refactoring and cleanup. There may be bugs and accidental compatibility breaks. Looks like T299191 is the first one (and some would-be bugs were caught by unit tests in various extensions).

@Perhelion

Can't remember where I'm supposed to report possible blockers, but it seems serious.

In T298970#7612666, @Urbanecm wrote:

Do you plan to use that wiki for some specific tests? Is there anyone else planning to? Setting up a wiki is non-trivial work, and we shouldn't do that just because theoretically someone might need it.

https://meta.wikimedia.beta.wmflabs.org/wiki/Special:SiteMatrix should have been more clear this is a closed test wiki.

In T298884#7611296, @matmarex wrote:

On thwikibooks, you'll have worse problems, as the Thai projects also use a different calendar – note how all the dates are in 2562 or so.

I hadn't actually tested it yet so I added the timezone for thwikibooks to Bawl to see. It actually does work even without that, but you have a valid point: I should add support for various calendars as this relies on a less accurate fallback method. Still won't be as annoying as having to make an API call to get the timezone.

In T298884#7610892, @Aklapper wrote:

@AlexisJazz: Maybe I misunderstood - are there different gadgets currently using *different* (emphasis mine) approaches to get that same wgLocaltimezone data (so their approaches should be standardized)?

In T298884#7610735, @Aklapper wrote:

(This doesn't look like something frontend, or to standardize across several codebases.)

Still an issue.

In T298422#7592714, @Zabe wrote:

As far as I know wether an edit is a bot edit is only saved in the recentchanges table, which only contains changes which are less than $wgRCMaxAge seconds (default value is 90 days) old. So that would need to be changed first, before this can really be tackled.

@GoingBatty asked me to report this in https://en.wikipedia.org/wiki/User_talk:GoingBatty#Removed/fixed_incorrect_author_parameter(s) as their bot routinely wipes Condé Nast.

@Bugreporter I don't think this is a duplicate. T13181 is from 2007 and the comments suggest that edits couldn't be marked as bot edits at all back then. Now they can ( see https://en.wikipedia.org/w/api.php?action=help&modules=edit) and the watchlist uses this information, but other pages do not.

In T298407#7592102, @Aklapper wrote:

Who/what adds "The following file is a duplicate of this file:" to pages? What is the current workflow?

In T297373#7559360, @JoKalliauer wrote:

Maybe duplicate of T20463 see https://commons.wikimedia.org/wiki/Librsvg_bugs#Pattern

@AlexisJazz : Could you provide a Minimal (not) working example

Also reproducible on beta cluster: https://commons.wikimedia.beta.wmflabs.org/w/index.php?title=User:AJ/Sandbox&diff=257063&oldid=257062

In T296505#7536032, @matmarex wrote:

This is expected. Icons are not all always loaded, they must be loaded by the code that is using them.

To do that, you'd load a ResourceLoader module named oojs-ui.styles.icons-<pack>, where <pack> is chosen from the list at https://doc.wikimedia.org/oojs-ui/master/demos/?page=icons. For example, the 'settings' icon is a part of the 'interactions' pack, so you'd load oojs-ui.styles.icons-interactions. (You can also add the module to dependencies if you're building a gadget.)

Note that you also need to load the ResourceLoader modules for the OOUI code you're using, or just oojs-ui to load them all. When I try your snippet while logged out, I get an error saying that ButtonWidget is undefined.

So, overall, you'll need something like this:

mw.loader.using( [ 'oojs-ui', 'oojs-ui.styles.icons-interactions' ] ).then( function () {
	button = new OO.ui.ButtonWidget( { framed: false, icon: 'settings', label: 'Settings', id: 'test', invisibleLabel: false } );
	$( '.vector-menu-content' ).append(button.$element);
} );

In T287327#7297603, @Aklapper wrote:

I don't think this use case is so common that it justifies adding yet another user preference.

It's broken again.

In T296125#7518351, @LucasWerkmeister wrote:

Web requests to the Beta cluster (e.g. https://en.wikipedia.beta.wmflabs.org/) are currently broken with the same message, but were still working 2 hours ago (otherwise this CI build, which makes requests against Beta, would’ve failed).

Request ID: YZke7tJMQlo-5vnBpYjveAAAAEk
Uncaught ConfigException: Failed to load configuration from etcd: (curl error: 60) SSL peer certificate or SSH remote key was not OK in /srv/mediawiki/php-master/includes/config/EtcdConfig.php:205

In T296113#7517683, @RhinosF1 wrote:

Yes I've noticed that but it still impacted the whole of beta. Someone can dig on the task from yesterday into why it lasted so little time.

In T296000#7517667, @Urbanecm wrote:

In T296000#7517657, @RhinosF1 wrote:

@Urbanecm: can you check the upload hosts? I believe something needs restarting for them.

Reloaded trafficserver-tls at cache-upload06, and it works for me now. Acmechief already distributed the right cert, so a reload was the last missing thing.

In T296113#7517666, @RhinosF1 wrote:

Upload hosts are just more broken than the rest. Yes I'm 1000% sure it's the exact same issue and it's the exact same steps to fix as it has been every 90 days for the last I've forgot how long.

In T296113#7517658, @RhinosF1 wrote:

In T296113#7517656, @AlexisJazz wrote:

@RhinosF1 : en.wikipedia.beta.wmflabs.org is already working again but upload.wikimedia.beta.wmflabs.org isn't.

It's the same issue but it's just not been finished.

@RhinosF1 : en.wikipedia.beta.wmflabs.org is already working again but upload.wikimedia.beta.wmflabs.org isn't.

In T280926#7480672, @Legoktm wrote:

@AlexisJazz is it OK if we close this task? I believe all the issues in this ticket are covered by either T274589: No atomic section is open (got LocalFile::lockingTransaction) or T295009: Improve download speed from archive.org on appservers or T295007: Upload by URL should use the job queue, possibly chunked with range requests.

In T292954#7473355, @Legoktm wrote:

In T292954#7470343, @Yann wrote:

I tried again to upload a 491 MB TIFF file from https://archive.org/details/clevelandart-1916.1044-gardener-s-house-at and it failed
Direct link: https://archive.org/download/clevelandart-1916.1044-gardener-s-house-at/1916.1044_full.tif
(upload-by-url on Commons)

Request from 90.112.25.87 via cp3064 cp3064, Varnish XID 452004418
Error: 503, Backend fetch failed at Sun, 31 Oct 2021 20:15:12 GMT

MediaWiki has a 180 second (3 minutes) timeout that it has to download the file in. It took me ~4 minutes to download the file at home, and AFAICT the bandwidth limitation is not on my side. On a production appserver it's even slower, currently saying it's going to take 15 minutes (I wonder if they're rate limiting us?) - see P17649. Now, even if the file does download in 180 seconds, there's a 200 second overall MediaWiki timeout. So it would need to upload to Swift, extract metadata, and update the databases in 20 seconds, which is cutting it pretty close. Unfortunately there's no chunked-upload-by-url system I'm aware of, in the meantime I think the best solution is to download the file locally or to Toolforge and then chunked upload to Commons.

Copy of my comment on T292954#7469361:

In T292954#7469436, @Koavf wrote:

Just noting that I had a lot of trouble uploading a large file: y2commons didn't work, ChunkedUpload didn't work, publishing from my stash didn't work (a half-dozen times), and one last try at ChunkedUpload/stash failed so badly that the special page for my stash wouldn't load. I have no clue what is up. Another user helped me by uploading the file to en.wp but it needs to be ported over to Commons and overwrite the malformed version there: https://en.wikipedia.org/wiki/File:David_Pakman_talks_to_Rebel_Wisdom_about_politics_and_media.webm

Can anyone do that?

*Edit*: Oh, the above.

Using bigChunkedUpload.js I uploaded a 921MB video:

In T293946#7454077, @Aklapper wrote:

@AlexisJazz: Please see https://www.mediawiki.org/wiki/Bug_management/Phabricator_etiquette and stay on-topic. Thank you. :)

@Jdforrester-WMF please remove your -1 from https://gerrit.wikimedia.org/r/c/operations/mediawiki-config/+/732705/ or change it into a +1. Developers shouldn't stand in the way of deploying a change the community has voted for because of their personal opinion.

In T293946#7451494, @ovasileva wrote:

Hey everybody, we’ve done an initial review on this request and have come up with the following as a rough outline of the process we’d like to follow before implementing the change:

• Before implementing the change, we would like to collectively define some success criteria for the feature (this is standard practice for any new feature introduction on the mobile site). In particular, we’re interested in measuring any significant increase to revert rates to edits on talk pages. In the past, we’ve studied how anons and new editors approach the talk page on mobile and have noted some amount of confusion - people think it’s a general discussion, similar to a comments section on other websites, while others assume it’s a place to ask questions about the wikis in general, such as “how do I edit?” I think this creates a potential risk for high revert rates on mobile.

• We would also like to research whether readers who are not attempting to edit will understand the purpose of a talk page link shown at a prominent location. We can focus on performing some additional research on readers that will allow us to understand how these readers will interact with the link. A potential evaluation here might include studying how long people spend on a talk page after they click, as well as additional user testing focused on understanding their expectations for the page.

• I know the goal of adding the talk page link is to make it easier to discuss with anonymous editors. Are there any additional things we want to measure around this goal? For example, we could look at a decrease in reverts for anons overall, or an overall decrease in blocks to all anon editors.

Potential next steps:

1. We can begin by adding the talk link to the bottom of the page, which would alleviate the concern for creating confusion for readers above. This implementation would still carry some risk for revert rates, however, so we should be ready to report on reverts to talk page edits before and after the change. In terms of timeline, if no new instrumentation is required, we can make the first change within two weeks of agreeing on the success criteria.
2. If the revert rates from the first change are within a reasonable range (TBD), continue with identifying potential user testing scenarios for readers. Due to other commitments, the timeline for this would be within the next 4-5 months.

How does all this sound?

In T294044#7448927, @Aklapper wrote:

(Please include relevant info.) The original file is ‎(SVG file, nominally 1,350 × 500 pixels, file size: 4 KB) and that seems to be sorted last here.

In T293701#7438899, @Zabe wrote:

Is this a dupe of T293558?

In T293070#7434071, @Lucas_Werkmeister_WMDE wrote:

That seems to have fixed the URL in the task description, at least. Though some other URLs, such as this Rheinwerk URL in the T271808 task description and also just https://upload.beta.wmflabs.org/, are apparently returning 421 Misdirected Request?

More failures: T283514

November 13, 2020: T267858
January 12, 2021: T271808

https://commons.wikimedia.org/wiki/File:Carnival_Trump_burning.webm
https://commons.wikimedia.org/wiki/File:Donald_Trump_Drinks_Disinfectant.webm