@LuciferianThomas Are you sure that this isn't related to the issues caused by the hkrail resets? have you seen it on any other wikis?

It happens miraheze-wide actually. Although I can't vouch for that but, I'm sure of my wikis and many other wikis I've tried it on.

I'm also aware this is a valid Miraheze issue, that has happened for a very long time. My guess is some conflict with ManageWiki but I was never certain. I also never looked to in-depth either. But it is worth an investigation.

While on T10173: Handling of hkrail.miraheze.org after database recovering and T10384: Resetting hkrail.miraheze.org, I noticed that imports (especially when done from the backend) consistently does not want to import correctly with sanitized-css. In T10384, we ran into content model issues like last time, which we managed to mostly fix by manually mapping the content models upon wiki reset. I have however noticed that even with TemplateStyles and other extensions adding content models installed on the wiki, there seems that sanitized-css was not added into the content models data table. I feel like this might be related to what exactly happened here, and I believe there wouldn't be a separate content models table for extensions (seeing that Scribunto is listed separately in the MediaWiki documentation on content handlers but works together with the main table), so this could be the cause of what causes this bug.

Related to T4699: Module /doc subpages not using wikitext as page content model

Interesting findings via eval.php

On metawiki running MediaWiki 1.39:

> var_dump($wgTemplateStylesNamespaces);
array(2) {
  [0]=>
  int(10)
  [1]=>
  int(-1)
}

On metawikibeta running MediaWiki 1.40:

> var_dump($wgTemplateStylesNamespaces);
array(1) {
  [10]=>
  bool(true)
}

In T10379#218610, @Agent_Isai wrote:

Interesting findings via eval.php

On metawiki running MediaWiki 1.39:

> var_dump($wgTemplateStylesNamespaces);
array(2) {
  [0]=>
  int(10)
  [1]=>
  int(-1)
}

On metawikibeta running MediaWiki 1.40:

> var_dump($wgTemplateStylesNamespaces);
array(1) {
  [10]=>
  bool(true)
}

That looks like something on the ManageWiki side is causing the configuration to be borked. The configuration for metawiki is not valid. I think this is a case of wgTemplateStylesNamespaces should be using type vestyle instead of check in ManageWikiNamespaces.php