Page MenuHomePhabricator

Fatal exception when attempting to view wiki page that should redirect to Media-namespace ("NS_MEDIA is a virtual namespace; use NS_FILE")
Closed, ResolvedPublicPRODUCTION ERROR

Description

If there is a redirect page to some file via the special Media: namespace, loading the page throws a MWException.

See for example https://en.wikipedia.org/wiki/User:Lahwaacz/test

Event Timeline

Thanks for reporting this. Please always include the complete error message in bug reports.

exception.file	       	/srv/mediawiki/php-1.32.0-wmf.20/includes/page/WikiPage.php:130
exception.message	       	NS_MEDIA is a virtual namespace; use NS_FILE.
exception.trace
#0 /srv/mediawiki/php-1.32.0-wmf.20/includes/MediaWiki.php(439): WikiPage::factory(Title)
#1 /srv/mediawiki/php-1.32.0-wmf.20/includes/MediaWiki.php(292): MediaWiki->initializeArticle()
#2 /srv/mediawiki/php-1.32.0-wmf.20/includes/MediaWiki.php(868): MediaWiki->performRequest()
#3 /srv/mediawiki/php-1.32.0-wmf.20/includes/MediaWiki.php(525): MediaWiki->main()
#4 /srv/mediawiki/php-1.32.0-wmf.20/index.php(42): MediaWiki->run()
#5 /srv/mediawiki/w/index.php(3): include(string)
#6 {main}
exception_id	       	W5Y6BgpAICIAAL1dzuUAAAAD
exception_url	       	/wiki/User:Lahwaacz/test
Aklapper renamed this task from Redirects to the Media: namespace throw a MWException to Redirects to the Media: namespace throw a MWException: "NS_MEDIA is a virtual namespace; use NS_FILE".Sep 10 2018, 9:33 AM
Krinkle renamed this task from Redirects to the Media: namespace throw a MWException: "NS_MEDIA is a virtual namespace; use NS_FILE" to Fatal exception when attempting to view wiki page that should redirect to Media-namespace ("NS_MEDIA is a virtual namespace; use NS_FILE").Sep 10 2018, 3:34 PM
Krinkle added a project: MediaWiki-Interface.
aezell added a subscriber: aezell.

I'm looking at this and I think I have a fix but want to make sure the result is appropriate.

It seems like the users are creating redirects to the NS_MEDIA namespace when they probably actually want to redirect to the NS_FILE namespace.

My approach is to catch these media redirects and change the namespace just before the redirect target is handed off to the page factory.

It works in my local setup but I want to check that's actually the desired result.

Change 464916 had a related patch set uploaded (by Aezell; owner: Aezell):
[mediawiki/core@master] Replace Media namespace redirects with File namespace

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

Change 464916 merged by jenkins-bot:
[mediawiki/core@master] Replace Media namespace redirects with File namespace

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

Krinkle added a subscriber: Krinkle.

Change 464916 merged by jenkins-bot:
[mediawiki/core@master] Replace Media namespace redirects with File namespace

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

Reverting for now because:

The test added by this commit is for a different issue that already worked before this change.
Modifying a Title object is unexpected and may cause a number of hard-to-detect issues.
The issue described in this task is still an issue with this patch applied.

The normalisation of urls that view "Media:" titles to be "File:" titles is done by MediaWiki::parseTitle().
This can be seen by viewing https://commons.wikimedia.org/wiki/Media:Example.jpg, which redirects to https://commons.wikimedia.org/wiki/File:Example.jpg.

The problem of this task is when viewing a title like "Sandbox" or "User:Example/sub" which contains a wikitext redirect to NS_MEDIA. Viewing such wiki page redirect currently causes a fatal. I've also verified this on Beta Cluster with this patch applied.

The bug described in this task likely needs to be fixed in different code, because tryNormaliseRedirect is about creating a new redirect that normalizes the url for the same title, it is not about resolving an existing redirect between two different titles.

@Krinkle Thanks for tending to this. I see now where I made the mistake. As part of a review, I moved the new code and didn't actually test the fix again in the application because the unit test passed. As you noted the unit test wasn't actually testing what I thought it was so it didn't catch that my fix no longer worked.

I appreciate the input and I think I have a better test and a better patch. The new test fails without my change and passes with it. The new patch also catches the issue much earlier in the redirect resolution and avoids modifying any Title objects as it happens before the Title object is created from the redirect DB record.

Should I create a new branch and push that as a new patchset?

Yes, that sounds perfect! Thank you for working on this.

Change 465444 had a related patch set uploaded (by Aezell; owner: Aezell):
[mediawiki/core@master] Fix media redirects

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

Change 465812 had a related patch set uploaded (by Krinkle; owner: Aezell):
[mediawiki/core@wmf/1.32.0-wmf.24] WikiPage: Fix viewing of wiki redirects to NS_MEDIA

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

Change 465444 merged by jenkins-bot:
[mediawiki/core@master] WikiPage: Fix viewing of wiki redirects to NS_MEDIA

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

Change 465812 merged by jenkins-bot:
[mediawiki/core@wmf/1.32.0-wmf.24] WikiPage: Fix viewing of wiki redirects to NS_MEDIA

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

Confirmed. Pages with a redirect to NS_MEDIA now render the same as pages with a redirect NS_FILE, which is - they show the destination title, not the destination content. This is correct because we don't allow automatic redirects from articles to files.

BeforeAfter
Screen Shot 2018-10-11 at 03.06.53.png (356×544 px, 35 KB)
Screen Shot 2018-10-11 at 03.06.53.png (356×544 px, 35 KB)
Screen Shot 2018-10-11 at 03.08.25.png (434×868 px, 88 KB)
Screen Shot 2018-10-11 at 03.06.44.png (384×690 px, 39 KB)

Mentioned in SAL (#wikimedia-operations) [2018-10-11T02:10:31Z] <krinkle@deploy1001> Synchronized php-1.32.0-wmf.24/includes/page/WikiPage.php: T203942 - Ib211d98498f (duration: 00m 49s)

mmodell changed the subtype of this task from "Task" to "Production Error".Aug 28 2019, 11:08 PM