Page MenuHomePhabricator

Incomplete migration of Wikimedia CH "members" wiki: artefacts on pages under unexisting namespace 90 and 91
Closed, ResolvedPublic1 Estimated Story Points


Hoping to be useful to posterity,

This page covers an issue addressed by my dear @Iopensa while talking together as usual about this and that and the Wikimedia CH members' wiki.
She discovered that some of her contributions were, uhm, weird / not accessible anymore / appearing like in a kind of deletion / censored state.

I was able to reproduce the issue visiting her [[Special:Contributions]] page and discovering broken inaccessible entries like this one:

  • [[Special:Badtitle/NS90:Talk:Board/Resolutions/Wikimedia CH involvement in Wikimania Esino Lario/Proposal]]

And yes these pages were not accessible:

image.png (571×938 px, 74 KB)

So we started working in troubleshooting this. Well, trying to debunk a range of conspiracy theories.

Macro zoidberg-heckle: CENSORS! THIEVES! We want OUR pages BACK!!

As an interesting side note it seems that the [[Page:Badtitle]] is used as a fallback title for broken pages. For example this is a snippet from the core:

// T34276: allowing the skin to generate output with $wgTitle or
// $this->context->title set to the input title would allow anonymous users to
// determine whether a page exists, potentially leaking private data. In fact, the
// curid and oldid request  parameters would allow page titles to be enumerated even
// when they are not guessable. So we reset the title to Special:Badtitle before the
// permissions error is displayed.

// The skin mostly uses $this->context->getTitle() these days, but some extensions
// still use $wgTitle.
$badTitle = SpecialPage::getTitleFor( 'Badtitle' );
$this->context->setTitle( $badTitle );
$wgTitle = $badTitle;

Thanks to that snippet and the hint given by [[Special:Badtitle/NS90:...]] we discovered more than 200 inaccessible pages in the database stored under the unknown namespace 90:

mysql dbwiki_members
$ SELECT COUNT(*) FROM members_page WHERE page_namespace = 90;
| COUNT(*) |
|      202 |

And I was able to quickly apply a quick and dirty temporary patch defining a custom namespace:

$wgExtraNamespaces[90] = "Dummy";
$wgExtraNamespaces[91] = "Dummy_talk";

This allowed us to make the pages reappear again and understand what we had in our hands: broken wikitext.

Then we discovered that the namespace 90 was a well-known and standardized MediaWiki namespace provided by a legacy extension called LiquidThreads:

Ns IDNs PrefixConstant

MediaWiki's Extension default namespaces § 90–99: LiquidThreads

At this point @Ilario confirmed that the Wikimedia CH members' wiki adopted that extensions for a while at some point in its history and that probably it was a missing piece from this migration:

This was a rational explanation because during that migration we were not able to examinate the legacy's filesystem and so we were not able to look at its legacy LocalSettings.php and that's why we may have forgotten some pieces.


In short we installed again the LiquidThreads extension in the members2 server. We adopted the version for MediaWiki 1.31 (currently in use) and now this set of 200 legacy pages is working again as a charm under the new Thread: namespace provided by this extension.

WARNING: Yes. These pages are now accessible again. This means they are ugly as hell again. This is an unmaintained extension, after all.
NOTE: Probably in the future it would be better to migrate all these structured discussions as normal wikitext to get rid of this unmaintained extension, as system hardening.

In short: it works now again. Ya-hi!

Thanks everybody.