Thank you @matmarex for looking into the issue! Basically, the purpose of this task is to effectively inform users that a page is protected and no editing is possible.
I checked it today on protected pages for Flow and for the new discussion tool (Talk pages). Flow pages look good, so the task is Resolved. Protected Flow pages on mobile inform users that a page is protected and hide all edit buttons:

I can't reproduce this today.

Still the most-tokenized open issue :)

probably never happening

What actually happens is the user is asked to enter a captcha, enters it correctly and clicks save, gets the warning with no captcha present, then is asked to enter a 2nd captcha, and then clicking save will save the edit.

Rather than page properties, which are stored and indexed in a separate database table, probably ParserOutput::setExtensionData() would be sufficient for this use case.

This makes my week. Thank you :) (:

So I've posted a patch that is basically what I outlined in T35186#7487506. Rough next steps:

Change 973279 had a related patch set uploaded (by Legoktm; author: Legoktm):

[mediawiki/core@master] WIP: Implement file rotation via Shellbox

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

MediaWiki-extensions-DocBookExport now exists, which I guess doesn't quite resolve this task.

Changed from "stalled" to "open" since apparently the Wikidata issues mentioned before were resolved.

I have removed a log filter from Kibana MediaWiki New Errors dashboard which pointed back to this task. There is no hit over the last four weeks.

The MobileWebEditing schema, in which these errors were logged, has been decommissioned ages ago. I don't see anything unusual in the errors logged in the current EditAttemptStep schema. I'm afraid the cause of this issue has been lost to time.

Seems like this got fixed in core – the request URL now produces:

Change 65176 had a related patch set uploaded (by Winston Sung; author: Parent5446):

[mediawiki/core@master] Automatically move category members when redirected

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

These days there are a lot fewer browsers that are served JavaScript by MediaWiki, but not supported by VisualEditor (in fact there might not be any). I don't think this is worth building any more.

Agreed re: just offering 90/180/-90 for under-X-MB files. Raise that to 20MB and you'll cover most good/featured images.

I think simple rotating (let's leave cropping out of it for now) is a must for Commons and something that should be supported at production quality, especially given the recent emphasis on better multimedia and technical support for Commons. Anyways it seems like low hanging fruit.

@Legoktm @Ladsgroup it seems crop and rotate (by 90/180) are such a common use case they should be "on" by default, whether by closer integration of CropTool into the upload wizard or otherwise.

I can't reproduce. It's likely that some logging refactoring since 2015 fixed this.

Not a strict duplicate; the removal of the old code isn't done yet, and we don't have a solution for non-Vector users.

Change 274328 abandoned by Aklapper:

[mediawiki/core@master] [WIP][POC][OMGWTFBBQ] Replace the searchSuggest box with an OOUI widget

Reason:

T125725 is duped into T244392. T244392 is resolved.

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

Change 901233 merged by Giuseppe Lavagetto:

[operations/puppet@production] graphite::alerts: add alert on mediawiki account creation failures

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