This is because of calls to Module:TemplateExist, and this report should be closed as invalid. cc @A2569875, the author of that module.

According to the protection log by Xiplus-abot, some "templates" already have 1026 transclusions as of 30 January.

In T361177#9744616, @SD_hehua wrote:

Or is it just cache? I cannot reproduce it stably.

In T282499#9730874, @cscott wrote:

1. Current Parsoid calls back to the legacy Parser to handle various types of content. That can cause there to be multiple $parser objects used on a given page. Most *present* issues with "linear parsing" are due to the fact that, even though the parse is technically in order, data being attached to the Parser object is lost because there are multiple parsers in play.

The current implementation of var_final (after commit 9597f365) is nothing more special than others, if anything will break in the future, that would be the whole extension.

In T361177#9669232, @daniel wrote:

So the fix would be this line? https://gerrit.wikimedia.org/r/c/mediawiki/core/+/1013392/9/includes/objectcache/ObjectCacheFactory.php#106

In T361177#9668964, @daniel wrote:

In T361177#9668179, @Func wrote:

Caused by commit d372626b97e83ec1f82b88e75fbaadf99ad2f89b for T358346

Can you explain how that patch is causing the problem? I fail to see the connection.

Caused by commit d372626b97e83ec1f82b88e75fbaadf99ad2f89b for T358346

I don't see any differences in the contents downloaded from GitHub and the extension distributor. Could you reproduce this reliably? I suspect the exception was either transient or due to the method you upload files to the server, e.g. some files failed to upload if you decompressed the tarball before uploading.

The $wgAllowImageTag config was removed in commit 4c6898362353aef5d4971ae8d1910bb6d0a30e6a.

In T203531#9392775, @Func wrote:

If we only consider the Variables extension itself, we can use an instance for Parser::setFunctionHook() calls, so it can carry the data along the parsing.
But the difficult part is that other extensions need to interact with Variables. While they can still use the Parser::callParserFunction() method, there are extra overheads compared to calling the ExtVariables::setVarValue() method directly.

Oh, I see, thanks. I would say at that time they just removed a broken feature, so let's not call this a regression.

Which code change removed the support? According to T255350#6863215, they use site JS to hide them, so it seems was not supported by the MW core.

Enabled but not displayed in the menu? Why tagged Regression, I don't think this has ever been implemented.

Which wiki though? They might removed the mw prefix or cleared the interwiki table (un)intentionally, the built-in interwiki list has not changed in 3 years and some dead sites are still there, not to mention the living mw prefix.

In T356739#9522256, @Kghbln wrote:

No, I cannot tell when MW stopped providing a predefined set of interwiki links. Definitely before MW 1.39.x or starting with MW 1.39.x latest.

In T331608#9535285, @Kghbln wrote:

Another question I already asked twice or thrice: Is this wiki, now on MW 1.39, unstable if it has these three extra fields? Can this wiki be used, or is this situation detrimental?

In T331608#9534356, @Kghbln wrote:

This means the table still contains rev_text_id, rev_content_format, and rev_content_mondel even though they should not.

In T331608#9525699, @Kghbln wrote:

This is after the second attempt. Using the original 1.34 database backup again this time, I did not try to update from 1.34 to 1.39 directly but did 1.34 --> 1.35 --> 1.39. Still, "update.php" failed for the update from 1.35 to 1.39. If I am right and the table looks as intended, it may be an issue about the file failing to detect that all of the work was done.

Regardless, this would also mean that the wiki is cool, and users can confidently continue editing?!

I created a secret Gist with two files, which holds what "update.php" printed for both runs. It also includes my action commenting the patch file.

In T356191#9513464, @Func wrote:

In T356191#9501355, @gerritbot wrote:

Change 994373 had a related patch set uploaded (by Func; author: Func):

[wikimedia/portals@master] Follow-up 110950f6: Use the stripped language name for top 10

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

@Jdrewniak, could you please check this before the coming portal deployment window? It's important to fix my mistake in the previous patch.

Not needed anymore per patch for T355001.

In T356191#9501355, @gerritbot wrote:

Change 994373 had a related patch set uploaded (by Func; author: Func):

[wikimedia/portals@master] Follow-up 110950f6: Use the stripped language name for top 10

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

Page name with : in the talk namespace: https://quarry.wmcloud.org/query/79991

The main issue is that vector 2022 would display a TOC no matter there are more than 3 sections or not.

I didn't read through the Wikimedia Portals code, but my theory is:
Without the json array entry below, it failed to merge zh-hans or zh-hant translations into the i18n array for zh subdomain and thought there was no such site.

"wikinews": {
}

@Winston_Sung Wikimedia:Portals-wikinews.slogan/zh and Wikimedia:Portals-wikinews.slogan/zh also need to be restored.

Patches for T171647 (older, removed some zh.json entries and claim to use the fallback table to build slogan in the "simp / trad" format) and T308009 (newer, adding back translated slogans separated with /) are doing the opposite things, so I guess unfortunately:

@Kitabc12345 You hardly ever can push a trivial task in this situation forward, because you can not force someone to review the code.

Similar to T350670, the Chinese Wikinews didn't show up around the circle maybe because the Wikinews slogan is missing in the translation - the translatewiki page for it was deleted.

Duplicate of T315650, which already have a patch by me pending review.

This seems to be the expected behaviour. The wikis around the circle are chosen by views per day, e.g. the most recent portal auto-build (not merged yet): the last one (10th) is it.wikinews.org with 27,000 views/day.

I am not sure if this is the right way forward: these stored as extension data but would never be used after parsing while they are in the ParserOutput and ParserCache.

In T291656#9369346, @Jdlrobson wrote:

Hmmm yeh this sounds like a new bug. I wonder what changed. Could you open a new ticket for us? (If not I can do this later in the week!)

This dialog is provided by the VariantAllyDialog gadget, you should raise this issue to the village pump.

Sorry, it's not safe to place deletion template on message page, so I have undone your change.

The lookup sequence for en-gb of this particular instance is: /en-gb message subpage (does not exist)->en-gb.json (got the message here, stop)->message base page (en)->en.json
This is to avoid fallback too aggressively, it might be acceptable for en-gb to always fallback to en local overrides, but it's not true for other languages.

That's by design. en-gb has its own software-defined message, which may or may not very differ from the one from en, so it would not fallback to the created override for en.
If the difference is not necessary, you may proceed to translatewiki to delete the en-gb subpage.

HTMLForm has been widely used in the core and many extensions, if the bug is only reproducible with interfaces created by the ManageWiki extension, there must be some unusual pattern in that extension.

Is this issue persistent?
I bumped the cache version in that commit, the old cache should have been replaced before causing any issues.