Thanks for replying.

I know this ticket from 2018, but would the following extension be a good start?

Weirdly, this is still an unresolved issue. It's probably related to recent changes in thumbnail behaviour - see especially T360589 - but the labels ought to have changed accordingly.

Thanks for reporting because I had the exact same issue. For now, downgrading Composer latest (now 2.9.5) > 2.8.x is a temporary workaround that works for me, too.

FWIW, documented at the bottom of https://www.mediawiki.org/wiki/Manual:$wgReadOnly

FWIW. Although the syntax has changed by now (the above would now read php maintenance/run.php install [...] --confpath LocalSettings-wikifarmsite1.php [...]), the issue remains. Installer::getExistingLocalSettings() still ignores whatever is set in --confpath.

FWIW, I added a notification about this breaking change on https://www.mediawiki.org/wiki/API:Imageinfo - rephrase away if you think it is unclear.

Pleased to heart that!

Okay, that's a pity. I still don't understand why it needs to be moved out of Codex. I've tried it using in my Chameleon skin, which - said issues aside - works wonderfully well.

Good news, I don't know what version of Codex ships with MW 1.39.6 (my wiki), and it would have been helpful if such info were included on Special:Version, but it looks like issue no. 2 was fixed in some later patch.

Sorry for that, I'm afraid you caught it in action at the wrong moment. Hopefully here's a better illustration of what I mean by using the up/down arrows

Many thanks for your reply.

It's been a while since September. Any Wikimedia developer who wants to take a look at the patch and give the green light?

Patch superseded by this patch from September: https://gerrit.wikimedia.org/r/c/mediawiki/extensions/RegexFun/+/1072618

I am unsure if this is the right space to bring it up, but I was recently reminded by @Pppery that dynamic properties are deprecated in PHP 8.2 and who knows when they will be disallowed.

See now https://gerrit.wikimedia.org/r/q/If0ee9426958057f8589e96ec865157b7482cc67b

Thanks, I remember doing a quick rewrite because it was just a distraction at the time of trying to upgrade to MW 1.39. So what I have now may not survive closer scrutiny but I will have a proper look this time round.

Hey, that is really unfortunate. I'm still using this extension in MW 1.39, using a version that I must have patched up to make it compatible again. It is frequently used in conjunction with the regex functionality of the Arrays extension.

To add to the above. The line that would eventually leave the process hanging is this in RenderedRevision::getRevisionParserOutput() :

(Given yesterday's update, I just reorganised my notes for readability)

Thanks but isn't that a slightly different use case? <img> and other HTML5 elements don't use self-closing tags with a trailing slash.

Same thing in Vector.

Not that I'm aware of, though perhaps the Chameleon skin is attempting something.

I can confirm. The Save button is blocked from triggering a submit action until a textarea with VE is initialised anywhere in the form.

Apparently, it is a hard requirement, so I went ahead and clarified this in the documentation. There's an outstanding RFC which proposes to drop it: T165149.

Thanks for your reply. I never got that from the documentation myself nor did I experience issues before. Why create a namespace if you;re not going to use it? With over 20 custom namespaces, it would also create a lot of unnecessary.clutter.

Thanks, I'm on it.

Well, the first step is to establish whether or not we are, in fact, dealing with a bug or limitation of the software (MediaWiki core). Maybe there is something I'm not understanding, so I didn't want to pre-judge the whole thing. If it is a bug or an inconvenient limitation, and no workaround is available, I would have gone ahead and add a bug report or enhancement request. As for Page Forms, clearly something is broken.