Page MenuHomePhabricator

Visiting Special:Homepage is not recognised on urwiki
Open, HighPublicBUG REPORT

Description

NOTE: The issue was hotfixed in production by removing the offending alias from GrowthExperiments.aliases.php. The underlying issue was not fixed. There is a Patch Demo instance (https://be7f4471b8.catalyst.wmcloud.org/) which allows the issue to be reproduced (standard Patch Demo / patchdemo1 credentials should work).

Steps to replicate the issue (include links if applicable):

What happens?:

image.png (432×842 px, 53 KB)

What should have happened instead?:

Homepage is rendered!

Event Timeline

Restricted Application added a subscriber: Aklapper. · View Herald Transcript

(At least) high, if not UBN. Moving to sprint, as it is a quite serious bug.

Credits go to @Trizek-WMF for discovering this bug.

Change #1207914 had a related patch set uploaded (by Urbanecm; author: Urbanecm):

[mediawiki/extensions/GrowthExperiments@master] hotfix: Disable Urdu alias for Special:Homepage

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

Change #1207919 had a related patch set uploaded (by Urbanecm; author: Urbanecm):

[mediawiki/extensions/GrowthExperiments@wmf/1.46.0-wmf.3] hotfix: Disable Urdu alias for Special:Homepage

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

Change #1207920 had a related patch set uploaded (by Urbanecm; author: Urbanecm):

[mediawiki/extensions/GrowthExperiments@wmf/1.46.0-wmf.2] hotfix: Disable Urdu alias for Special:Homepage

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

Change #1207920 merged by jenkins-bot:

[mediawiki/extensions/GrowthExperiments@wmf/1.46.0-wmf.2] hotfix: Disable Urdu alias for Special:Homepage

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

Change #1207919 merged by jenkins-bot:

[mediawiki/extensions/GrowthExperiments@wmf/1.46.0-wmf.3] hotfix: Disable Urdu alias for Special:Homepage

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

Change #1207914 merged by jenkins-bot:

[mediawiki/extensions/GrowthExperiments@master] hotfix: Disable Urdu alias for Special:Homepage

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

Mentioned in SAL (#wikimedia-operations) [2025-11-20T17:36:41Z] <urbanecm@deploy2002> Started scap sync-world: Backport for [[gerrit:1207920|hotfix: Disable Urdu alias for Special:Homepage (T410666)]], [[gerrit:1207919|hotfix: Disable Urdu alias for Special:Homepage (T410666)]]

Mentioned in SAL (#wikimedia-operations) [2025-11-20T18:04:50Z] <urbanecm@deploy2002> urbanecm: Backport for [[gerrit:1207920|hotfix: Disable Urdu alias for Special:Homepage (T410666)]], [[gerrit:1207919|hotfix: Disable Urdu alias for Special:Homepage (T410666)]] synced to the testservers (see https://wikitech.wikimedia.org/wiki/Mwdebug). Changes can now be verified there.

Mentioned in SAL (#wikimedia-operations) [2025-11-20T18:18:39Z] <urbanecm@deploy2002> Finished scap sync-world: Backport for [[gerrit:1207920|hotfix: Disable Urdu alias for Special:Homepage (T410666)]], [[gerrit:1207919|hotfix: Disable Urdu alias for Special:Homepage (T410666)]] (duration: 41m 57s)

If MediaWiki returns "No such special page", it means SpecialPageFactory::getPage( $name ) has returned null (=special page is not existing). What is confusing that if I copy the title directly from the URL address (خاص:صفحۂ_اول, or صفحۂ_اول without namespace [which is what SpecialPageFactory expects), this method works:

> get_class(\MediaWiki\MediaWikiServices::getInstance()->getSpecialPageFactory()->getPage('صفحۂ_اول'))
= "GrowthExperiments\Specials\SpecialHomepage"

>

It turned out that WebRequest::getTitle() passes all received values through Language::normalizeUnicode(). If I pass the same string through that method, it fails:

> \MediaWiki\MediaWikiServices::getInstance()->getSpecialPageFactory()->getPage(\MediaWiki\MediaWikiServices::getInstance()->getContentLanguage()->normalize('صفحہ_اول'))
= null

>

I can also put all of this togehter using SpecialPageFactory::getLocalNameFor( 'Homepage' ), to show the difference between having the normalization and not having it:

> $spf = \MediaWiki\MediaWikiServices::getInstance()->getSpecialPageFactory()
= MediaWiki\SpecialPage\SpecialPageFactory {#4972}

> $contLang = \MediaWiki\MediaWikiServices::getInstance()->getContentLanguage()
= MediaWiki\Language\Language {#722 …8}

> get_class($spf->getPage($spf->getLocalNameFor('Homepage')))
= "GrowthExperiments\Specials\SpecialHomepage"

> $spf->getPage($contLang->normalize($spf->getLocalNameFor('Homepage')))
= null

>

What I don't know is the fix. I'm not sure if the normalisation is the problem, or if the problem is the translation that was in the GrowthExperiments.alias.php file.

Either way, even if someone commits an unnormalised alias, it probably should not work. I'd expect a CI failure, or a more meaningful error than "no such special page".

I also run a short Python script to verify where this is an issue:

import requests
import pandas as pd
import wmpaws

wikis = wmpaws.get_dblist('growthexperiments')
wikisDf = pd.read_csv('https://gitlab.wikimedia.org/repos/data-engineering/canonical-data/-/raw/main/wiki/wikis.tsv?ref_type=heads', sep='\t')
wikisDf.set_index('database_code', inplace=True)

for wiki in wikis:
    r = requests.get('https://{domain}/wiki/Special:Homepage?uselang=en'.format(domain=wikisDf.loc[wiki].domain_name), headers={
        'User-Agent': 'Martin Urbanec, testing script'
    })
    if r.status_code != 200:
        print(f'{wiki}: Failed to load Special:Homepage ({r.status_code})')

the output was:

urwiki: Failed to load Special:Homepage (404)

and nothing else. So, this seems to be a urwiki-specific problem.

Change #1207931 had a related patch set uploaded (by Urbanecm; author: Urbanecm):

[mediawiki/extensions/GrowthExperiments@master] Revert "hotfix: Disable Urdu alias for Special:Homepage"

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

Test wiki created on Patch demo by Martin Urbanec (WMF) using patch(es) linked to this task:
https://be7f4471b8.catalyst.wmcloud.org/w/

For the purpose of other engineers looking at this bug, I've created a Patch Demo where the bug can be seen. If you login to https://be7f4471b8.catalyst.wmcloud.org/ using the Patch Demo / patchdemo1 account, you should see the failure:

image.png (400×1 px, 60 KB)

Probably the alias as specified in the aliases file isn't in normalized form and needs to be.

Probably the alias as specified in the aliases file isn't in normalized form and needs to be.

Or alternatively, MediaWiki should normalize both URL and loaded aliases.

Cross-posting #engineering-all post in WMF Slack for transparency:

Hi! The Growth team had issues with a Special page alias having non-normalised Special page aliases (see https://phabricator.wikimedia.org/T410666).
I'm not sure what is the proper path forward here:

  • Should alias files always have normalised names in them? If so, should we ensure this by a structure test?
  • Alternatively, should MediaWiki normalise special page aliases when loading the file?

The first case seems somehow quicker (the normalisation happens only once), but if we eventually make special page names translatable in other-than-make-a-commit-way (T42707), it could be more important than it is now.
The second is a bit slower (as the normalisation happens on every i18n load), but it is more on the end of treating special page aliases as config (which might be incorrect) rather than code.
Does anyone have any preference on the right path forward here?

@Nikerabbit I think your team would have the most information to advise how to proceed. Would you mind taking a look, please?

I think a structure unit test would probably be easiest solution for this. Normalization might make sense for input coming via LocalSettings.php but I would not do it for everything.