Last modified: 2011-01-25 00:33:22 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 T2539, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 539 - Allow images that link somewhere other than the image page (using normal link syntax)
Allow images that link somewhere other than the image page (using normal link...
Status: RESOLVED FIXED
Product: MediaWiki
Classification: Unclassified
File management (Other open bugs)
unspecified
All All
: Low enhancement with 34 votes (vote)
: ---
Assigned To: Rowan Collins [IMSoP]
http://cvs.berlios.de/cgi-bin/viewcvs...
:
: 3330 5332 5573 9059 9347 10168 12114 (view as bug list)
Depends on: 688 689
Blocks:
  Show dependency treegraph
 
Reported: 2004-09-20 15:32 UTC by Alan Barrett
Modified: 2011-01-25 00:33 UTC (History)
21 users (show)

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


Attachments
Limited and not-very-tested patch for 1.3 (11.95 KB, patch)
2004-10-02 02:40 UTC, Rowan Collins [IMSoP]
Details
A slightly better patch, against 1.4 (10.12 KB, patch)
2005-02-17 22:29 UTC, Rowan Collins [IMSoP]
Details

Description Alan Barrett 2004-09-20 15:32:08 UTC
At present, any image that is placed on a page using the [[Image:...]] 
syntax generates HTML output that includes a clickable link to the image 
page itself.  For example, [[Image:Foo.jpg]] generates something vaguely 
like <a href="http://server/wiki/Image:Foo.jpg"><img src="..."></a>.  
Thumbnailed and framed images similarly include <a href="..."> links to 
the image information page, but the details are different.

People sometimes want the <a href="..."> link to go somewhere else 
instead of to the image information page.  For example, on [[en:Main 
Page]], people want the image associated with the featured article of 
the day to be a clickable link to the article, not a clickable link to 
information about the image.

Please add new syntax such as [[Image:Filename.ext|link=[[Link to wiki 
page]]|more|options|here]] and [[Image:Filename.ext|link=[http:
//link/to/external/page]|more|options|here]].
Comment 1 John Gonzalez 2004-09-23 18:34:58 UTC
We are interested in getting this functionality added to Mediawiki as well. We
will make a $25/donation to the Wiki drive when it is completed.
Comment 2 Rowan Collins [IMSoP] 2004-09-29 22:26:06 UTC
Just to note that I've got a half-finished patch for this, which I will probably
attach for testing tomorrow. [ Or "mañana", as they say... :/ ]
Comment 3 John Gonzalez 2004-09-29 23:31:20 UTC
(In reply to comment #2)
> Just to note that I've got a half-finished patch for this, which I will probably
> attach for testing tomorrow. [ Or "mañana", as they say... :/ ]

Rowan,

Excellent. Thx for keeping up on this.
Comment 4 Rowan Collins [IMSoP] 2004-10-02 02:40:55 UTC
Created attachment 61 [details]
Limited and not-very-tested patch for 1.3

This feature is causing me to run into more problems than I expected, so sorry
for the delay (as I said, "mañana"!) However, here is a patch which should add
limited image-aiming functionality to a 1.3 release. I'm going to code a more
complete version for hopeful inclusion in 1.4.

This patch:
* creates a new "magic word" (MAG_IMG_LINK) in Language.php, which recognises
by default "link=" or "target=" as valid image parameters [incidentally, it
fixes some broken handling of such magic words]
* as long as the text of these links is valid as an internal page title, this
will cause the image to point at that page
* no special handling is made for non-existent pages
* interwiki links *will* work, but this is currently the only way to link to an
external page (I hope to have proper ext. links handled in the final feature,
but they require wider changes to get right)
* it should work for images with and without frame / thumbnail options
selected; the "zoom" icon (magnifying glass) on thumbnails should still link to
the image description page.

Example use: 
* [[Image:Foo.jpeg|thumb|link=The article at the end of the link|Alt text]]
* [[Image:WPLogo.png|frame|link=Wikipedia:Main_Page|Wikipedia is ace!]]

***THIS PATCH COMES WITH NO GUARANTEES WHATSOEVER***
I really haven't tested it very much, or thought about security implications,
and it's now 3:30AM, so I don't intend to just yet. Feel free to test it
yourself, but I make no guarantee that it is safe to use this on a live site.
It probably is, but you never know.
Comment 5 John Gonzalez 2004-10-03 00:13:37 UTC
Rowan,

I have tested this briefly and it appears to work fine. I will be making the
donation and I'll post a link here with some info on the donation. Thanks for
your effort!

Here's the donation, actually:

 	 Payment  	 To  	 Wikimedia Foundation, Inc.  	 Oct. 2, 2004  	 Completed  	
Details  	   	-$25.00 USD   	$0.00 USD 
Comment 6 JeLuF 2004-10-11 17:41:42 UTC
This patch does not provide any means to access the image description page.
On GFDL wikis this is a potential problem. The revision history must be
easily available.
Comment 7 Rowan Collins [IMSoP] 2004-10-11 18:12:05 UTC
(In reply to comment #6)
> This patch does not provide any means to access the image description page.
> On GFDL wikis this is a potential problem. The revision history must be
> easily available.

Yes, for the completed version of this patch I intend to implement the following
behaviour:
* if an image uses the |thumb| parameter, the existing "zoomicon" will continue
to link to the description page (already implemented)
* if an image uses the |frame| parameter, an additional icon (I propose an "i"
for info) will link to the desc. (this should probably be displayed whether or
not clicking the image also takes you there, for consistency)
* if an image uses neither, but uses a |link=$1| parameter (i.e. is otherwise
unframed, but clicking the image does not provide the info page), put it in a
frame anyway with a message such as "<small>View image details and copyright
status.</small>" where the caption would otherwise be (i.e. assume that the user
did not intend a visible caption).
Comment 8 Adam Katz 2005-01-31 00:09:02 UTC
To include an image within a link to a specified page, like <a href="foo"><img
src="bar.jpg"></a>.

On mediawiki 1.3.9, this was possible as:              [[en:Foo|[[Image:Bar.jpg]]]]
On mediawiki 1.4beta5, this is rendered as if saying: 
<nowiki>[[en:Foo|]]</nowiki>[[Image:Bar.jpg]]

I am running:  Apache/1.3.33 Ben-SSL/1.55 (Debian GNU/Linux)
(apache-ssl 1.3.33-3)

Please change Hardware and OS to Any (currently PC/NetBSD).
Comment 9 Alan Barrett 2005-02-06 13:16:22 UTC
(In reply to comment #7)
> * if an image uses neither, but uses a |link=$1| parameter (i.e. is otherwise
> unframed, but clicking the image does not provide the info page), put it in a
> frame anyway with a message such as "<small>View image details and copyright
> status.</small>" where the caption would otherwise be (i.e. assume that the user
> did not intend a visible caption).

There needs to be a way of disabling that.  Perhape <nowiki>[[Image:whatever|link=...|noinfo|..
.]]</nowiki>. For example, on a page like [[meta:Template:WikipediaSister]], people want images 
that link to various places, but a "view image details" link would be inappropriate.  Also, at 
[[meta:Www.wikipedia.org portal/Catherine]], the big round logo and the small bookshelf images 
should ideally appear just as raw images, without linking anywhere, without frames, without 
"enlarge" or "view image details" icons, but with alt text.  It would be nice if we could say 
something <nowiki>[[Image:whatever|link=|noinfo|Alt text here]]</nowiki> to get something that 
translates to HTML as <nowiki><img src="whatever" alt="Alt text here"></nowiki>, without any 
<nowiki><a href="...">...</a></nowiki>.
Comment 10 Rowan Collins [IMSoP] 2005-02-17 22:29:50 UTC
Created attachment 293 [details]
A slightly better patch, against 1.4

I've re-implemented the patch against 1.4, and also added some features to it.
Current behaviour:

* As with the previous patch, this includes the fix to bug 688, which really
ought to have been checked in by now, but hasn't been.

* To enable the feature, you need to set $wgAllowTargettedImages=true; in
LocalSettings.php (This allows it, in theory at least, to be checked in, turned
off by default, rather than people having to patch it themselves.)

* Once enabled, it will recognise the parameters "link=..." and "target=..." in
image markup (defined by the MAG_IMG_LINK entry in Language.php, override in
LanguageXX.php as appropriate).

* Anything that looks like an external link (as would be recognised by
Parser.php) is linked to there *as long as it is followed by a space* - e.g.
[[Image:Foo|link=http://example.com |foo]]. Without that, the "|foo" becomes
part of the ext link, and everything goes screwy because the parser turns it
into an HTML link. Eventually, I hope to be more sane, but right now image
syntax isn't parsed in Parser.php, so it's mighty awkward.

* Anything that looks like an internal page title is assumed to be one of
those.

* Anything else is just ignored. There is no way of linking to nothing, because
I don't see the need for it.

* This patch *does not* enforce an additional link for the description page,
because that defeats the purpose many people will want to put this to. (Yes, I
know that's a controversial attitude, but that's why I suggest it be disabled
by default.)

All feedback and testing welcome.
Comment 11 Alan Barrett 2005-02-19 12:11:23 UTC
(In reply to comment #10)
> There is no way of linking to nothing, because
> I don't see the need for it.

So, where do you think the big round logo at http://www.wikipedia.org/ should 
link to?  Similarly with the word "Wikipedia" and the bookshelf images on that 
page.  I think they shouldn't link anywhere.  (And they currently don't link 
anywhere, which is possible because the page was written in HTML.)
Comment 12 Rowan Collins [IMSoP] 2005-02-19 15:46:19 UTC
(In reply to comment #11)
> So, where do you think the big round logo at http://www.wikipedia.org/ should 
> link to?  Similarly with the word "Wikipedia" and the bookshelf images on that 
> page.  

Hm, I guess you have a point there; maybe there *are* times when linking to
nothing would be nice. Although I'm beginning to be a bit concerned that if the
patch implements link to local page, link to external URL *and* link to nothing,
all via one configuration switch, people are going to start wanting one without
the others. But I guess in that case, they can just hack the code and comment
out the bits they don't like...

Unfortunately, this is a little more complicated an addition than it at seems at
first sight, since we don't really want to link to "nowhere", we want to not
link at all. I think I'll therefore go back and finish my larger rewrite (bug
689) before implementing that. In the meantime, you'll have to put up with every
image linking *somewhere*, even with this patch.
Comment 13 Erik Moeller 2005-02-20 02:56:20 UTC
Regarding the licensing, this is a non-issue if used responsibly and should be a
matter of policy. To give an example, if the thumbnails on the Main Page point
to the articles instead of the images, these articles include larger versions of
the images, hence, the licensing information remains available.
Comment 14 Michael Zajac 2005-04-12 22:34:32 UTC
If an image is explicitly linking somewhere, a link to the Image: description page should go into the image's longdesc attribute.  This usage 
would closely follow the HTML standard and accessibility recommendations.  Most browsers don't give access to the longdesc URL, but an 
interface could be provided using CSS and/or Javascript.

Comment 15 Rowan Collins [IMSoP] 2005-08-30 20:49:41 UTC
In a discussion on mediawiki-l, somebody proposed a quick hack of an extension
for doing this - see
http://meta.wikimedia.org/wiki/User:Sysy/Joshua_Oreman%27s_icon_extension
Comment 16 T. Gries 2005-08-30 21:29:16 UTC
See www.enotifwiki.org and especially this extension (originally written by
Brion)
http://cvs.berlios.de/cgi-bin/viewcvs.cgi/enotifwiki/enotifwiki/extensions/ImageLink.php
Comment 17 Julien BENNET 2005-09-20 14:42:18 UTC
Since the extension ImageLink did not exactly worked for me, and did not exactly
satisfied me with the limited syntax, I came with a personal extension tested
against 1.4.9 (should work with 1.5, too).
http://meta.wikimedia.org/w/index.php?title=User:Jbennet/Navigational_images

The principle is simple : it will substitute the target url of the generated
image code, by the target URL of any other wiki code (e.g. [[My Page]] or
[http...mysite/]). It allows you to specify any Image syntax, and any kind of
destination, only with wiki code.
Comment 18 Rowan Collins [IMSoP] 2005-10-18 23:10:58 UTC
Magnus Manske suggested in a mailing list post that there could be a message
shown on the target page, similar to the "Redirected from" one - something along
the lines of "Information on the image you clicked is at [[:Image:$1]]". Of
course, this is no good for images with external (or interwiki) targets, or with
no link at all, but it's an interesting thought.
Comment 19 bdk 2005-12-26 22:09:06 UTC
*** Bug 3330 has been marked as a duplicate of this bug. ***
Comment 20 Trần Thế Trung 2005-12-30 10:46:52 UTC
Have any one requested image map yet?

If no, I am doing it now.

I have seen the encourage works here on image that link to article. Thank you
all and keep it up.

Now I am requesting that an image can link to several articles, depending on
which region on the image we click.

This is harder to edit by non-experienced, so it may be implemented on a
different name such as [[ImageMap: ... ]] or <imagemap> ... </iamgemap>

This would be so nice for the map (e.g. map of the world, when you click on each
country, you get the article on that country, then click on the province in the
map in that article, then you get to the province, and so on, ... ) on diagram
of instrument (e.g. diagram of a car, when you click on ...  well you get it by
now), ...

A donation of 20 euro to Wikipedia drive promissed for progress on this.
Comment 21 Trần Thế Trung 2005-12-30 13:01:04 UTC
I've just noted that my comments is a duplication of Bug 1227 
Comment 22 Rowan Collins [IMSoP] 2006-01-21 13:40:08 UTC
See also http://en.wikipedia.org/wiki/Template_talk:Click, which uses a weird
CSS trick for achieving this.
Comment 23 Nick Jenkins 2006-02-11 03:38:12 UTC
Question: If we have this syntax for an image:
[[Image:car.jpg|thumb]]

And this syntax for an external link:
[http://www.test.com/ This is a test]

Then logically, wouldn't the syntax for an image that is also an external link
be this? :
[http://www.test.com/ [[Image:car.jpg|thumb]]]

I've tried this, and unfortunately it doesn't work (and also the thumbnailing of
the image is ignored).
Comment 24 Rob Church 2006-02-15 01:51:36 UTC
(Patch was against 1.4, will now need to be against 1.6. Marking as obsolete and
removing keyword.)
Comment 25 Rowan Collins [IMSoP] 2006-02-16 17:44:15 UTC
(In reply to comment #23)
> Then logically, wouldn't the syntax for an image that is also an external link
> be this? :
> [http://www.test.com/ [[Image:car.jpg|thumb]]]

No, because 
* it looks really ugly (and confusing to the user)
* it would be a nightmare to parse correctly
* what would [http://www.test.com/ [[Ordinary page]]] mean?
... or [http://www.test.com/ [[Image:car.jpg|thumb|Caption]]]?
... or, logically valid, [http://www.test.com/ [[Image:car.jpg|thumb|Caption
with an [http://example.com external link]]]]?

If this is implemented at all, it will be as an option inside the image markup
specifying the target, not the other way around.
Comment 26 Nick Jenkins 2006-02-17 00:06:16 UTC
> If this is implemented at all, it will be as an option inside the image markup
> specifying the target, not the other way around.

Fair enough, that all makes good sense to me.

I also think a link to nowhere (or rather, no link) would be very useful too.
That's because I'd like to convert this: http://roubin.com/ into a personal
wiki, so as to make it easier to update - but it uses images for internal links,
for external links, and images with no links; It also uses image maps, but it
doesn't strictly have to, although it'd be nice (but that's bug 1227). I figure
if that page can successfully be made into a wiki page, and look & behave the
same way as it does now, then most/all static text+image pages can.
Comment 27 Omegatron 2006-03-04 20:34:48 UTC
Can't this be implemented simply by allowing span tags to have background: and
padding: attributes?  Then you can add a CSS background image to a link that
appears as an icon next to it.  Currently, they're stripped out on save.
Comment 28 Minh Nguyễn 2006-03-05 04:36:11 UTC
That would be a simple solution, but implementing a special argument to the
image syntax will keep the What Links Here feature working for image description
pages. Also, CSS background images in the MediaWiki stylesheets (like
[[MediaWiki:Monobook.css]]) don't always work: for [[vi:Tiêu bản:Sơ khai]], for
example, the background image is a thumbnail of an SVG image at Commons. I have
to periodically recreate that thumbnail, but upload.wikimedia.org gets rid of it
from time to time.
Comment 29 Minh Nguyễn 2006-03-05 04:37:06 UTC
That would be a simple solution, but implementing a special argument to the
image syntax will keep the What Links Here feature working for image description
pages. Also, CSS background images in the MediaWiki stylesheets (like
[[MediaWiki:Monobook.css]]) don't always work: for [[vi:Tiêu bản:Sơ khai]], for
example, the background image is a thumbnail of an SVG image at Commons. I have
to periodically recreate that thumbnail, because upload.wikimedia.org gets rid
of it from time to time.
Comment 30 Brion Vibber 2006-03-23 02:57:15 UTC
*** Bug 5332 has been marked as a duplicate of this bug. ***
Comment 31 Robert Shimmin 2006-04-08 11:48:40 UTC
This feature is now necessary to do chemical structures linked to the article on
the chemical compound, as described on [[en:Wikipedia talk:Wikiproject
Chemistry]] and up to now handled through image redirect pages, but now failing
b/c admin insists on image use tags on the image page (rather than its talk
page), and this breaks the ability to use image redirects.
Comment 32 Rob Church 2006-04-14 18:11:37 UTC
*** Bug 5573 has been marked as a duplicate of this bug. ***
Comment 33 Minh Nguyễn 2006-08-03 04:38:37 UTC
A small note: the "manual thumb" feature allows you to link to different image
pages, but not yet to anything outside of the image namespace. See "thumb=xyz"
under [[m:Help:Magic words#Image modifiers]].
Comment 34 Omegatron 2006-12-20 17:34:30 UTC
Really, clickable images should only be possible in the case of navigational
images; templates or other similar "extensions" to the software.  Encyclopedic
images, like the ones found in article text, should never be allowed to be
clickable, because of license and thumbnail functionality.  Any solution that
allows clickable images needs to take this into account.

In effect, the images used in navigational templates and the like are actually
part of the site's software instead of part of the encyclopedia text, and need
to be licensed as such.

(And things like the featured article star, admin mop, and the like should be
implemented directly in the software with magic words or something; not CSS
kludges.)
Comment 35 Quiddity 2006-12-20 19:31:35 UTC
Previous comment is in regards to this current thread at TfD:
[[w:Wikipedia:Templates for deletion/Log/2006 December 17#Template:Click]]. It'd
be great if someone could create a better solution than Template:Click ...
Comment 36 Sy Ali 2006-12-22 02:36:55 UTC
In response to comment #34 .. I have a few ideas:

1)

Well, since there is already a feature to allow mediawiki to understand the
license terms of a new upload.. this feature could be implemented but restricted
to the appropriate license fees.

2)

Or if necessary a separate licensing dropdown selection could be made in the
upload form.. and thus an image upload could be 'flagged' as available for use
by this feature.

3)

Either this, or some new feature has to be made:
* The admin uploads images to a special directory.
* These images are available via some kind of thing like <command
link="http://destination">imagename.jpg</command>
Comment 37 Rob Church 2006-12-22 02:56:25 UTC
MediaWiki doesn't understand what a licence is, per se; all it knows is that if
a specific message is defined, it can parse that message to get a template name
and a label for a combo box such that, when the upload form is submitted,
depending on what's selected, the appropriate template is transcluded onto the
bottom of the image description page. The licence isn't stored in metadata form
at present.

How about we work out an implementation, and trust people to be sensible about
using it; communities leap on copyright infringement fairly well at present, so
why can't we trust them to beat the living daylights out of abusers of this
functionality, metaphorically speaking, of course?
Comment 38 the wub 2007-01-17 18:09:39 UTC
http://www.mediawiki.org/wiki/Extension:ImageMap allows this
Comment 39 Raimond Spekking 2007-01-17 18:13:30 UTC
(In reply to comment #38)
> http://www.mediawiki.org/wiki/Extension:ImageMap allows this

So I will close this bug as FIXED
Comment 40 Rob Church 2007-03-02 17:59:35 UTC
*** Bug 9059 has been marked as a duplicate of this bug. ***
Comment 41 Nick Jenkins 2007-03-20 04:20:09 UTC
*** Bug 9347 has been marked as a duplicate of this bug. ***
Comment 42 John Doe 2007-03-21 16:02:38 UTC
I found a "bug" in that extension. It doesn't have the ability to link to
another part of the same page. I'm trying to get it going for this page:
http://en.wikibooks.org/wiki/Paint.NET/Contents/Tools

This is a short version of my code:

<imagemap>
Image:Pdntoolsmenu.png

rect 9 26 20 37 [[Paint.NET/Contents/Tools#Rectangle_Select|Rectangle Select]]

desc none
</imagemap>


What happens is that it just discludes "#Rectangle_Select" in the url. Is there
a workaround for this, is this fixable, or is it just hopeless? If it is
hopeless, I may just make separate pages for the tools (there's a lot of info on
each one of them).
Comment 43 Raimond Spekking 2007-04-18 11:30:10 UTC
(In reply to comment #42)
> I found a "bug" in that extension. It doesn't have the ability to link to
> another part of the same page. I'm trying to get it going for this page:
> http://en.wikibooks.org/wiki/Paint.NET/Contents/Tools
> 
> This is a short version of my code:
> 
> <imagemap>
> Image:Pdntoolsmenu.png
> 
> rect 9 26 20 37 [[Paint.NET/Contents/Tools#Rectangle_Select|Rectangle Select]]
> 
> desc none
> </imagemap>
> 
> 
> What happens is that it just discludes "#Rectangle_Select" in the url. 

This is bug 8917 and fixed now with r21299.
Comment 44 Michael Daly 2007-05-22 20:34:39 UTC
This can be done with the imagemap extension.

<imagemap>
Image:myimage.jpg
default [[page title]]
</imagemap>

It will create an imagemap where the entire image "myimage.jpg" links to the page "page title".  There is an information icon that will be placed in the corner of "myimage.jpg" that links to the image's information page.

It will also work with external links (if external links for imagemaps are enabled) and for headings on a page (as noted in the previous comment by Raimond).

I guess this bug can be closed.
Comment 45 Aryeh Gregor (not reading bugmail, please e-mail directly) 2007-05-25 01:23:43 UTC
Bug 9059 was marked duplicate of this, for whatever reason.  It probably makes more sense to keep that open and separate.
Comment 46 Brion Vibber 2007-06-06 14:57:01 UTC
*** Bug 10168 has been marked as a duplicate of this bug. ***
Comment 47 Jesse (Pathoschild) 2007-06-27 04:06:46 UTC
I've closed this as fixed per comment #39 and comment #44.
Comment 48 Phillip Stewart 2007-06-27 04:15:21 UTC
Isn't this bug about getting this capability in MediaWiki without using an extension?
Comment 49 Jesse (Pathoschild) 2007-06-27 04:23:10 UTC
What's wrong with adding the feature through an extension? It's easy to install, not needed on most wikis, and already enabled on all Wikimedia wikis.
Comment 50 Aryeh Gregor (not reading bugmail, please e-mail directly) 2007-06-27 04:38:08 UTC
The expected syntax, [[Target|[[Image:Picture.png]]]], doesn't work.  That was the original intent of this bug.  That feature should be in core, and can only be fixed in core in any case.  Image maps are a workaround for this, and can stay out of core.
Comment 51 Rob Church 2007-06-27 04:38:35 UTC
I kept the bug open because I felt that a slightly easier syntax for the
straight case this bug asks for might be more desirable.

If you feel that the syntax used by the extension is good enough, feel free to
close as fixed.
Comment 52 Thomas Bleher 2007-11-27 21:17:05 UTC
*** Bug 12114 has been marked as a duplicate of this bug. ***
Comment 53 René Kijewski 2007-11-29 02:52:00 UTC
There are two major issues with imagemap: It does not evaluate parameters and it is only an extension. Would it be this difficult to look up for a parameter "link"? I think one could even do it without square brackets for simplicity.
Comment 54 Juliano F. Ravasi 2008-04-20 23:21:02 UTC
Just to note that I counted about 17,000 pages on the main article namespace that transcludes [[Template:Click]] in the English Wikipedia (this is a rough estimate by counting how many 500-entry pages the following query returned):

http://en.wikipedia.org/w/index.php?title=Special:WhatLinksHere/Template:Click&limit=500&namespace=0

I think that is quite a lot of pages, for a wiki with such a strong policy of enforcing image links to lead to the image description page. I have also seen many bot user pages with the "red panic button" using the CSS hack to redirect to the Special:Blockip.

I think that both arguments, for allowing and for disallowing image links to arbitrary pages, are very strong, and we may think about some kind of solution that aids both needs.

I propose a namespace-whitelist for such special feature. If the [[Image:...]] link is expanded within a page in -- or transcluded from -- a whitelisted namespace, it allows the image to link somewhere else, otherwise, the current behavior is kept.

So, for Wikipedia, since this feature is demanded only for some templates, NS_TEMPLATE would be the only whitelisted namespace (or, perhaps, NS_MEDIAWIKI). For other wikis, their administrators have the option of whitelisting the main namespace (and this includes www.mediawiki.org, where there are three big clickable images right in the main page using the [[Template:Click]] hack).
Comment 55 MZMcBride 2008-10-06 08:15:55 UTC
Fixed by Tim in r41727.
Comment 56 Church of emacs 2008-10-06 18:55:57 UTC
I believe this to be quite problematic, as there are major copyrights issues here:
When an image is used that requires attribution, it *must* link to the description page of the image, otherwise it's a copyright violation. There should be at least the desc image (blue i) on one of the image corners that links there (that's what is being used for Extension:ImageMap). (Please forgive my ignorance if this is already the case)
Comment 57 Juliano F. Ravasi 2008-10-06 19:14:26 UTC
(In reply to comment #56)
> When an image is used that requires attribution, it *must* link to the
> description page of the image, otherwise it's a copyright violation.

For images with these constraints, you should use other means of enforcing that it doesn't contain the new click= parameter.

Note that nothing blocks you today from making the image page inaccessible, there is [[Template:Click]] ready for you to use, but using it for the wrong purpose will probably cause your changes to be quickly reverted by someone else.

With this change, the same policy today applied for the use of [[Template:Click]] will be applied also for the click= parameter. Nothing changes in this regard, and for the valid uses, we will avoid annoying and ugly hacks.
Comment 58 Brion Vibber 2008-10-06 19:15:52 UTC
Any reason to use 'click' instead of 'link'? (Particular when 'no-link', not 'no-click', suppresses the link.)

(In reply to comment #56)
> I believe this to be quite problematic, as there are major copyrights issues
> here:
> When an image is used that requires attribution, it *must* link to the
> description page of the image, otherwise it's a copyright violation.

That's actually not true:

1) Attribution usually requires a name or reference to the original author -- this is often not going to be the image description page URL (though it might be *on* the image description page).

2) Attribution could be included another way, such as putting it in a caption or a list of credits.

3) As is, a printout of a page containing an image would fail to include any visible reference to the description page. Unlike inline URL references, these are not currently expanded on printout.

> There
> should be at least the desc image (blue i) on one of the image corners that
> links there (that's what is being used for Extension:ImageMap). (Please forgive
> my ignorance if this is already the case)

This would interfere with the primary requirement -- using certain images as navigational elements.

My recommendation remains adding some sort of image credits caption list; this should definitely be done for printable pages, but could include on-screen credit footers for images like this anyway.

Currently we don't really have good metadata for attribution requirements; the minimum would be to add links to the description pages for now (which presumably have the rest of the data.)
Comment 59 Melancholie 2008-10-06 23:05:05 UTC
(In reply to comment #58)
> Any reason to use 'click' instead of 'link'? (Particular when 'no-link', not
> 'no-click', suppresses the link.)
> 

I totally agree!
I think Tim did so because people are used to [[Template:Click]].

You really could rename (or copy) 'click' to 'link', but do so before r41727 goes live (if possible), as people will use 'click' instantly when the long awaited feature is finally available ;-)
Comment 60 Brion Vibber 2008-10-07 00:32:52 UTC
In r41789, changed from 'click' to 'link' and added 3 parser test cases.
Comment 61 Alan Barrett 2009-02-06 20:50:11 UTC
This doesn't seem to work properly.  See test cases at [[w:en:Wikipedia:Images linking to articles]].  When used with a caption, the link is to the wrong target; and when ued without a caption, the alt text and title text are wrong.
Comment 62 MZMcBride 2009-02-06 20:56:07 UTC
I believe you're referring to [[bugzilla:16912]].

Re-marking this as RESOLVED FIXED. Please file a new bug for any further issues.
Comment 63 Alan Barrett 2009-02-07 13:11:17 UTC
Bug [[bugzilla:17398]] filed.

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


Navigation
Links