Last modified: 2010-05-15 15:33:09 UTC

Wikimedia Bugzilla is closed!

Wikimedia has migrated from Bugzilla to Phabricator. Bug reports should be created and updated in Wikimedia Phabricator instead. Please create an account in Phabricator and add your Bugzilla email address to it.
Wikimedia Bugzilla is read-only. If you try to edit or create any bug report in Bugzilla you will be shown an intentional error message.
In order to access the Phabricator task corresponding to a Bugzilla report, just remove "static-" from its URL.
You could still run searches in Bugzilla or access your list of votes but bug reports will obviously not be up-to-date in Bugzilla.
Bug 1850 - Non-inline links to missing images / image description pages should be marked as broken
Non-inline links to missing images / image description pages should be marked...
Status: RESOLVED FIXED
Product: MediaWiki
Classification: Unclassified
Parser (Other open bugs)
1.4.x
All All
: Normal normal with 10 votes (vote)
: ---
Assigned To: Nobody - You can work on this!
http://commons.wikimedia.org/wiki/Use...
:
: 2782 2853 (view as bug list)
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2005-04-08 16:23 UTC by Daniel Kinzler
Modified: 2010-05-15 15:33 UTC (History)
3 users (show)

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


Attachments
HEAD patch for parserTests.txt (906 bytes, patch)
2005-06-22 16:48 UTC, Zigger
Details

Description Daniel Kinzler 2005-04-08 16:23:58 UTC
Links to images (non-inlined, like [[:Image:something.png]]) should be red if
the image does not exist. This would make life easier in discussions and work
lists, esp. to be able to see if an image has already been deleted. Also, the
current behaviour is inconsistent with the representation of other "broken" links.

Presumablly, the trouble with this is that it is unclear if this should test for
the existence of the image or the image description page. Images that are used
from the commons often don't have a description page - should links to those be
considered broken? It would probably be best to check for the image, not the
description page. But that may be quite slow, as it requires a lookup on the
filesystem, possibly on a different box. Alternatively, one could query the
image table of the commons database, that would probably be more efficient.

This seems to be related to the question about how to find out on which wikis a
commons-image is used, and, in reverse, to find out which commons-images a
specific wiki uses. The first is important for maintenance, the second for
creating dumps.
Comment 1 Daniel Kinzler 2005-06-14 16:05:57 UTC
I think the links should at least be red if shared upload is disabled - i.e. on
the Commons, for example - that would be very useful.
Comment 2 Zigger 2005-06-22 16:08:40 UTC
From bug 1702 comment 1 (2005-04-21) :
> In CVS HEAD for 1.5, Image: links to nonexistent files now produce a red link
which goes to the upload page.

In the 1.5alpha versions, :Image: links to nonexistent files are still blue.
Comment 3 Zigger 2005-06-22 16:48:37 UTC
Created attachment 635 [details]
HEAD patch for parserTests.txt

Patch to parser tests for the Image and :Image cases.
Comment 4 Zigger 2005-06-24 01:06:44 UTC
(Set a three-keyword combo for previously attached parsertest patch.)
Comment 5 Zigger 2005-07-10 10:36:18 UTC
*** Bug 2782 has been marked as a duplicate of this bug. ***
Comment 6 Zigger 2005-07-14 02:11:19 UTC
*** Bug 2853 has been marked as a duplicate of this bug. ***
Comment 7 Brion Vibber 2005-09-02 05:09:03 UTC
Removing patch keyword since there's not an actual fix patch yet.
Comment 8 Jamie Hari 2005-11-12 02:27:47 UTC
This is fixed in 1.5, is it not?
Can we close this now since 1.4 is coming to its end?
Comment 9 lɛʁi לערי ריינהארט 2005-11-12 03:26:16 UTC
(In reply to comment #0)

> Links to images (non-inlined, like [[:Image:something.png]]) should be red if
> the image does not exist. This would make life easier in discussions and work
> lists, esp. to be able to see if an image has already been deleted. Also, the
> current behaviour is inconsistent with the representation of other "broken" links.
> 
> Presumablly, the trouble with this is that it is unclear if this should test for
> the existence of the image or the image description page. Images that are used
> from the commons often don't have a description page - should links to those be
> considered broken? It would probably be best to check for the image, not the
> description page. But that may be quite slow, as it requires a lookup on the
> filesystem, possibly on a different box. Alternatively, one could query the
> image table of the commons database, that would probably be more efficient.
> 
> This seems to be related to the question about how to find out on which wikis a
> commons-image is used, and, in reverse, to find out which commons-images a
> specific wiki uses. The first is important for maintenance, the second for
> creating dumps.

What was the original issue:
Should the *inline* links (as [[:Image:foo.png]]) be red? These are also used in
discussion pages. This is *not* the case.
Should the image inclusions (as [[Image:bar.png]]) be red? This is the case.

> Presumablly, the trouble with this is that it is unclear if this should test for
> the existence of the image or the image description page.

This realy is the case:
a) The existance of the file ({{ns:Media}}) can *be* seen / detected by
referencing to the media namespace.
b) However the existence of the description page ({{ns:Image}}) can *not* be
detected. To me this is *inconsistent* to the existence of pages in other
namespaces.

See http://yi.wiktionary.org/wiki/user:Gangleri/tests for examples.

regards reinhardt [[user:gangleri]]

P.S. probably *crosswiki* should be added as keyword because the existance of a
file on a common media server is a crosswiki issue
Comment 10 lɛʁi לערי ריינהארט 2005-11-12 03:28:37 UTC
see
http://commons.wikimedia.org/w/index.php?title=User:Duesentrieb/Test&action=history

The example was always about *inline* links. This is *not* fixed / activated at
WikiMedia projects until today.
Comment 11 Rob Church 2005-11-14 10:20:41 UTC
Are you therefore saying that the bug, as reported, is fixed in CVS HEAD? It's
still present, IIRC, in the 1.4 and 1.5.x branches.
Comment 12 Brion Vibber 2005-12-03 06:38:00 UTC
Fixed in HEAD.

Currently these will show an edit link, not an upload link; this is consistent with other _page_ 
links and also:

  [10:12pm] Bdka: brion_away, [[:Image:foo]] is *mainly* red because an
  image was deleted, and therefore it should show an edit link that users
  can easily get the infos on deletion imo

Additionally such links will start showing up in Special:Whatlinkshere where they were formerly 
just ignored; cf bug 360.
Comment 13 David Benbennick 2005-12-04 15:18:39 UTC
Apparently the fix to this bug created a new bug.  See
http://en.wikipedia.org/w/index.php?title=Arapahoe_County%2C_Colorado&action=history.
 The edit summary for the December 4 edit links to [[Image:Map of Colorado
highlighting Arapahoe County.svg]].  It uses a red link, presumably because the
image doesn't exist on EN, but only on the Commons.
Comment 14 Mark Pellegrini 2005-12-04 16:05:08 UTC
The link text should not be red if the linked file exists on commons. 

This bug fixed has created a rather unfortunate situation with the music
template, which (in order to fullfill attribution requires in copyright
licenses) automatically links to the image page of the linked image. 

For example: http://en.wikipedia.org/wiki/Beethoven#Media - almost all the info
links are now broken. 
Comment 15 Brion Vibber 2005-12-05 07:25:33 UTC
Ok, fixed to force-blue if the file is present, even if there's no local page.
Comment 16 David Benbennick 2005-12-07 17:49:58 UTC
Commons image links are still red in edit summaries in page histories.  See
http://en.wikipedia.org/w/index.php?title=User:Dbenbenn/sandbox&action=history
for example.
Comment 17 bdk 2006-01-09 01:23:18 UTC
An additional workaround to handle blue links to deleted files 
in the aim of transparency (after history info of deleted revisions 
is no longer displayed) is to edit [[MediaWiki:Noimage]].
Simply add two links to the deletion logs of the specific project 
and to the shared repository. See for example:
http://de.wikipedia.org/w/index.php?title=MediaWiki%3ANoimage&diff=12423454&oldid=7353141
Comment 18 JePe 2006-02-12 06:28:43 UTC
I noticed that an image that doesn't exists is linking directly to the
uploadpage now, instead of a page with the MediaWiki:Noimage text. On the Dutch
Wikipedia we have there like de.wikipedia some links to the deletion logs.

But for now it links directly to the uploadpage, so it is very difficult to
examine the reason of a deletion by a user. I think it has to do with this
bugfix of Magnus Manske with the log message: (bug 1850) Image link to
nonexistent file fixed.

http://article.gmane.org/gmane.org.wikimedia.mediawiki.cvs/11472

But here on this bugpage there is no comment by Magnus where he explains this
solution and why.

I think it is much better to link to the Mediawiki:Noimage text, because there
is also an upload link if the user wants to upload the image, and the user can
there simple retrieve the reason of deletion.
Comment 19 Mormegil 2007-07-19 10:26:53 UTC
(In reply to comment #18)
> I think it is much better to link to the Mediawiki:Noimage text, because there
> is also an upload link if the user wants to upload the image, and the user can
> there simple retrieve the reason of deletion.

Maybe yes, maybe not. But this bug has been fixed, because the original description
is no longer true. (Non-inline links to missing images / image description pages
currently _are_ red, marked as broken.) If you want a change in the behavior, create
a new bug report or feature request (possibly requesting a configuration variable to
control that).

Changing back to RESOLVED FIXED.

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


Navigation
Links