Page MenuHomePhabricator

An image redirect from a foreign shared File Repository overrides local wiki page.
Open, MediumPublic

Description

Reproducible on both trunk and enwikipedia.

Steps to reproduce:
*Have some thingy thats not a redirect in the file namespace.
*Make it a redirect to some other file
*Go in the history, and look at the old (non-redirect) revision of the page.

Expected behaviour:
*You see the old version
Actual behaviour:
*You see the this page is a redirect thingy, for even the non-redirect old versions.

ImagePage.php overrides how redirects are displayed to user, and does it differently then how its normally done. Presumably there is better handling for this in Article.php. With only looking at the code for about 5 seconds, it seems like there should be a better way to do this without the duplication.

I think T29857 has the same root cause.

Relevant example on 'pedia: http://en.wikipedia.org/w/index.php?title=File:Bierstadt_Albert_Lower_Yellowstone_Falls.jpg&action=history

Issue originally reported by Chzz on irc.


Version: unspecified
Severity: normal
See Also:
T38118: When a local image and an image redirect on Commons have the same name, the wrong description page is linked

Details

Reference
bz28299

Event Timeline

bzimport raised the priority of this task from to Medium.Nov 21 2014, 11:24 PM
bzimport set Reference to bz28299.

TBrophey wrote:

IMO, the above description does not accurately report the problem with File:Bierstadt_Albert_Lower_Yellowstone_Falls.jpg, for the associated redirect is on Commons and has only one version. Therefore it is to be expected that viewing a historic version on Wikipedia would not affect the redirect on Commons.

IMO the steps to redirect are:
*Find a redirect in File space on Commons
*Create a text-only page in File space on Wikipedia.
*Display the resulting Wikipedia page.

Expected behavior:
*The text on Wikipedia is shown in addition to (or instead of) the Commons page.
Actual behavior:
*The text on Wikipedia has no effect on the display.

My apologies, I misunderstood the issue. (Well actually both issues are present, but the one you're reporting seems more serious). Changing bug title to reflect actual issue.

One complication of this. Lets say [[image:foo.jpg]] is a redirect to [[image:Bar.jpg]] on commons, Someone creates the page image:Foo.jpg on enwikipedia as a normal non-redirect. Someone else puts [[image:Foo.jpg]] on an article. Since [[image:Foo.jpg]] is no longer a redirect, should inserting [[image:Foo.jpg]] into a page still display [[image:Bar.jpg]]. I'm leaning towards it shouldn't, but not really sure.

TBrophey wrote:

(Revising comment #1)
I can’t believe I wrote that. In case it is not obvious, what I meant to say in my second paragraph was:

IMO the steps to reproduce are:
*Find a redirect in File space on Commons
*Create a text-only page in File space on Wikipedia with the same name as the redirect.
*Display the resulting Wikipedia page.

It appears this is an actual bug to be fixed, not an enhancement request. reclassifying.

I'm dropping this from 'highest' as it's not a huge problem, but keeping at 'high' rather than 'normal' is it sounds like it may be hard to work around for the case where it hits.

Bumping back to 'normal' as nobody seems terribly freaked by it. :)

Bug 36118 is stated to be a possible duplicate.

Removing assignment from some tasks I'm not actively working on. Volunteers welcome, I'm happy to help if pinged!

Xaosflux renamed this task from An image redirect from a foreign File Repo overrides local wiki page. to An image redirect from a foreign shared File Repository overrides local wiki page..Mar 19 2019, 12:28 AM

Breaking the redirect on the remote shared repository page (such as in https://commons.wikimedia.org/w/index.php?title=File:Lee_Dixon.jpg&oldid=343164913 ) restores the local projects access.

Example on beta cluster: https://en.wikipedia.beta.wmflabs.org/w/index.php?title=File:Test_Commons_shadow.jpg&redirect=no

Without redirect=no you just see a poop emoji.

By adding redirect=no it behaves as would have been expected. Incredible that this bug still survives after a decade. If the page exists locally, redirects on Commons should be ignored.