Verified

Those 2 were the only extensions deployed on Wikimedia wikis.

In T392232#10818940, @RamzyM-WMF wrote:

@jrbs upon further discussion we'd like to have the email notification enabled -- is this something that you could change from your side?

Is this is how the form is intended to look after the change?

The timestamp comes from ParserOutput, I guess…

Thanks!

Verified locally using the steps from T306207#10786194.

This code was removed completely in https://gerrit.wikimedia.org/r/c/mediawiki/extensions/CentralAuth/+/1130751, there are no more errors logged since then.

Please don't automatically abandon changes just because they are old. I've had that happen when trying to contribute to other open source projects (I've also had my bug reports closed just because they were old) and it was very discouraging.

Well… I think it'd be better to show the counter. But it's up to y'all to declare that this is expected 🤷‍♂️

I feel like this idea is mostly covered by the newly added "global log context": T142313: Add global information to debug logger context

As reported at https://en.wikipedia.org/wiki/Wikipedia:Village_pump_(technical)#First_watchlist_item_messed_up, this change has an unintended effect on narrow screens, due to the legend box reducing available space. The patch I proposed should fix that.

I've done some work in https://gerrit.wikimedia.org/r/c/mediawiki/extensions/Echo/+/1125608 and https://gerrit.wikimedia.org/r/c/mediawiki/extensions/Echo/+/1147068 to make Minerva less of a special case. It should be feasible now to introduce such an option.

Not really. The error message indicates a bug somewhere else in the editor – it's a last-minute check that was added to prevent data corruption if something tries to load the wikitext source into the visual editor, or the other way round. (To be clear, it's a VE bug, not a user error.) But where the problem with that something is happening, I do not know.

(the very first time this happened an error popped up. Regrettably, I did not write it down or take a screen shot, and the error has not reappeared since. My recollection is it was something about being "in the wrong mode 'source editor'")

There are no more messages in MediaWiki known to be used as raw HTML output. If you discover one, please file a security bug.

This was caused by a typo in translation, fixed in this change: https://translatewiki.net/w/i.php?title=MediaWiki:Echo-notification-alert/ky&diff=prev&oldid=13085062

Updated documentation:

• https://www.mediawiki.org/w/index.php?title=Heading_HTML_changes&diff=prev&oldid=7631566
• https://www.mediawiki.org/w/index.php?title=Manual:$wgParserEnableLegacyHeadingDOM&diff=prev&oldid=7631564

Done: https://www.mediawiki.org/w/index.php?title=Manual:$wgAllowRawHtmlCopyrightMessages&diff=prev&oldid=7629509

In T393837#10810355, @Tacsipacsi wrote:

Isn’t this exactly the kind of markup that gets converted to {{1x|xxx}} when I save the edit? Or does that conversion happen in PHP, and we have no JS implementation for doing so?

I see there's already a task about noc@ being a dead end: T393404.

(sent too early) As for the "right" way to solve this, I think there isn't really one, but there are workarounds:

• Just list all of the aliases explicitly in "autoload" in your composer.json. At that point it's probably easier to also keep the class_alias in the same file as the real class. This shouldn't be too bad if you don't have many of them.
• Do this silly thing, which I just accidentally found by codesearching for "classmap-authoritative". I suppose this fake class definition makes Composer find it when generating its classmap. I wonder if it breaks Phan or IDEs…

The missing piece of the puzzle is the fact that in the mediawiki/vendor repo, composer.json uses "classmap-authoritative": true:

• https://gerrit.wikimedia.org/g/mediawiki/vendor/+/bafb02fe55a71418da510cf74582b4031806a701/composer.json#4
• https://getcomposer.org/doc/articles/autoloader-optimization.md#optimization-level-2-a-authoritative-class-maps

Following instructions in the commit message, I was able to create an account using API sandbox with password sent via email: https://test.wikipedia.org/w/index.php?title=Special:Log&logid=424666

Sorry it took us a while to get to this. The fix would be deployed next week per the usual schedule. I wonder if we should backport it earlier?

Ugh, needs backporting.

There is a class_alias, but Composer doesn't support generating autoload data for class aliases, so the class is not loaded when the alias is used.

Caused by rGPAReeabc4a0c220: Rename XMLSerializer to XHtmlSerializer / rMW1be5b7585b97: Bump wikimedia/parsoid to 0.22.0-a2

I wonder if the new Notification should be compatible with the hook we want to deprecate.

Please humor me with one more thing, I promise this is the last one :)

We're down from 142 to 105 lines. Current results:

Wow, thank you!

I'm not sure what you mean by plain text. It'd be possible to make the "computed" target editable (e.g. given wikitext like [[{{1x|xxx}}|link]], it could show "Xxx" as the link target). But editing such a link would lose the original markup, and so I think that it would be too easy for users to accidentally "corrupt" the article. I felt that allowing it to be deleted, but not edited, was an acceptable workaround.

In T67362#1480956, @nshahquinn-wmf wrote:

URLs followed by templates are still broken. However, they now seem to be broken differently: they display as regular links with broken syntax, rather than as alienated nodes.

The article has been edited since, but this was the affected revision: https://en.wikipedia.org/w/index.php?title=New_York_City_English&oldid=1176166207

Thanks for the additional details. I'm still struggling to understand how the data could be available for reading by MediaWiki for all these years, but could not be updated by the maintenance script that should have migrated it, but I'll take your word for it. I guess it's too late to hope to review the script logs?

They also all were originally created in a narrow time range, between 9 and 10 March 2009. According to Server Admin Log archives (2008 Oct - 2009 Jun → March 9-10), there was some trouble with the revision external storage on enwiki on those exact days:

In T393237#10807998, @Ladsgroup wrote:

In T393237#10807988, @Pppery wrote:

2- We confirmed they were corrupted before the migration. Mistake didn't happen in this case. Those edits all are old and from a time we had way less protections in production.

Thanks for the reminder. You can review the patches whenever you're ready.

Thanks for fixing, and I'm sorry I missed that in review.

I think it is a blocker. I will just restore the aliases, and leave it for whoever wants to remove them to figure out how to communicate the breaking change.