Last modified: 2011-02-08 21:56:30 UTC

Wikimedia Bugzilla is closed!

Wikimedia migrated from Bugzilla to Phabricator. Bug reports are handled in Wikimedia Phabricator.
This static website is read-only and for historical purposes. It is not possible to log in and except for displaying bug reports and their history, links might be broken. See T17688, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 15688 - Special:WantedFiles does not look on shared repositories
Special:WantedFiles does not look on shared repositories
Status: RESOLVED DUPLICATE of bug 6220
Product: MediaWiki
Classification: Unclassified
Special pages (Other open bugs)
1.14.x
All All
: Normal normal with 9 votes (vote)
: ---
Assigned To: Nobody - You can work on this!
http://wikimediafoundation.org/wiki/S...
:
: 18275 (view as bug list)
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2008-09-22 10:15 UTC by David Crochet
Modified: 2011-02-08 21:56 UTC (History)
13 users (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Attachments

Description David Crochet 2008-09-22 10:15:31 UTC
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.
Comment 1 Chad H. 2008-09-22 12:01:47 UTC
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.
Comment 2 Alex Z. 2008-09-23 22:08:56 UTC
Maybe an "il_foreign" field in the imagelinks table?
Comment 3 Siebrand Mazeland 2008-10-05 11:08:00 UTC
Added URL, prio to normal, component: file/repo -> special pages
Comment 4 Casey Brown 2008-10-05 12:09:57 UTC
(-> used a URL to a Wikimedia wiki)
Comment 5 Brion Vibber 2008-10-28 22:26:25 UTC
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.
Comment 6 Chad H. 2008-10-28 22:30:03 UTC
(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...
Comment 7 Ahmad Sherif 2009-03-31 20:36:26 UTC
*** Bug 18275 has been marked as a duplicate of this bug. ***
Comment 8 forrester.wikipedia 2009-08-05 18:25:51 UTC
Is there any progress on that issue?
Comment 9 the_herd_of_the_horses 2010-01-13 01:25:30 UTC
Is there any progress on this issue?
Comment 10 Krinkle 2010-06-15 21:32:31 UTC
See also https://bugzilla.wikimedia.org/show_bug.cgi?id=6220
Comment 11 p858snake 2010-06-20 01:17:50 UTC

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

Note You need to log in before you can comment on or make changes to this bug.


Navigation
Links