Page MenuHomePhabricator

Special:WantedFiles does not look on shared repositories
Closed, ResolvedPublic

Description

Author: crochet.david

Description:
This special page list all need image, but, in most case, the image are in Wikimedia Commons, so the special page indicate bad information (for the moment i presum).

Maybe that indication in the top page of the special page to say that would be better for the moment.


Version: 1.14.x
Severity: normal
URL: http://wikimediafoundation.org/wiki/Special:WantedFiles

Details

Reference
bz15688

Event Timeline

bzimport raised the priority of this task from to Medium.Nov 21 2014, 10:20 PM
bzimport set Reference to bz15688.
bzimport added a subscriber: Unknown Object (MLST).

Ew :(

The only solution I'd see would be to run each of the "bad" titles through the repo stack to see if they match any foreign repos, but it wouldn't be very efficient, imo.

Maybe an "il_foreign" field in the imagelinks table?

Added URL, prio to normal, component: file/repo -> special pages

bugs wrote:

(-> used a URL to a Wikimedia wiki)

The imagelinks table shouldn't store properties of the target; we organize them the way they are so they don't have to change. :)

But indeed I'm not too sure what's a better way to do it, especially in general (eg, foreign repo may be by API, so no database we can easily query). :P

Perhaps a separate table of 'images we've touched at some point which we know exist offsite'... bleh.

(In reply to comment #5)

The imagelinks table shouldn't store properties of the target; we organize them
the way they are so they don't have to change. :)

But indeed I'm not too sure what's a better way to do it, especially in general
(eg, foreign repo may be by API, so no database we can easily query). :P

Perhaps a separate table of 'images we've touched at some point which we know
exist offsite'... bleh.

I know ForeignApiRepo caches this stuff really heavy (every single external HTTP request is cached), but it shouldn't need to be that way, not to mention it doesn't help those who have CACHE_NONE set...

An extra table seems icky though, I agree there...

ahmad.m.sherif wrote:

*** Bug 18275 has been marked as a duplicate of this bug. ***

forrester.wikipedia wrote:

Is there any progress on that issue?

the_herd_of_the_horses wrote:

Is there any progress on this issue?

  • This bug has been marked as a duplicate of bug 6220 ***