Feature Proposal: A link that looks like an image should not become an inline image

Motivation

I have users trying to link to metadata pages on the web that are on wikipedia (and at least one other source), where the URL looks like an image file, but is actually a metadata page (HTML).

From Tasks.Item2507:

Here is some verbatim TML with a URL presented three different ways, where only the first form renders properly via the view script:

[[http://commons.wikimedia.org/wiki/File:Nypa_fruticans_Blanco2.386-cropped.jpg][test]]

[[http://commons.wikimedia.org/wiki/File:Nypa_fruticans_Blanco2.386-cropped.jpg]] 

http://commons.wikimedia.org/wiki/File:Nypa_fruticans_Blanco2.386-cropped.jpg

These three forms are now repeated below, without verbatim, and the expected behaviour is that the last two forms should be clickable links like the first - but instead nothing (ie. only one clickable link - the first - instead of three):

---

test

---

The other problem is that the WYSIWYG editor which sees the [[foo.com/bar.jpg]] as a simple TML link, no longer looks anything like the rendered topic which replaces that with an image.

Description and Documentation

The current assumption that all links to image-ish URLs, even bracketed links are to become an inline image is surprising to some users and in this case, detrimental for the user who just wants a hyperlink.

Paraphrasing the user: "It didn't work properly just pasting the URL, so I tried putting the square brackets around it, but that didn't work either".

Options added 06 Jan 2009

1. Don't generate images from [[URL] (original proposal)
2. Don't generate images from [[external URL]] (current proposal)
   • Using the WYSIWYG editor's image dialogue is a more natural place to be inserting images.
3. Document the [[URL][URL]] work-around (I doubt if even 5% of my users have read any of the wiki documentation)
   • The current behaviour of [[foo.com/bar.jpg]] creating an <img is not documented next to all the other [[syntax]] examples, the only mention is this example:

     Write %ATTACHURL%/myco.gif to see this: to see this

The current behaviour is surprising to users even if they appreciate it, and the casual user that actually wanted a hyperlink feels as if their task is impossible (the work-around is to use [[url][url]] )..

On the other hand, this might be a case where legacy and other reasons will trump my assumption that this needs to be fixed.

Examples

Impact

WhatDoesItAffect:

%WHATDOESITAFFECT%

edit

Implementation

Modification is required in Render.pm. Looks as if an extra parameter needs to be passed to _externalLink() via _handleSquareBracketedLink() in getRenderedVersion().

-- Contributors: PaulHarvey - 29 Dec 2009

Discussion

Just a quick thought: I don't know by heart how other wiki engines treat this case in general, but if we could assume/make sure that all 'pseudo-external' links are normalised (maybe a future feature proposal?) or their handling is not a problem -- i.e., we're really only dealing with 'true' external references in this context, then...
...wouldn't ExternalLinkPlugin be the better place to look for extensions/modifications rather than touching Render.pm (that is, if the hook in question offers the needed functionality)? This way, legacy considerations aren't an issue.

-- MarkusUeberall - 30 Dec 2009

The problem isn't that the link is external, but that it points to HTML content even though the URL "sounds like" an image.

The issue is that Foswiki renders an <img tag instead of an <a and the browser fails to load the "image".

If I wrote [[this-is-a-html-file.png]] I would expect a hyperlink, not an <img

A plugin fix did cross my mind, but thought this might be of general enough concern to fix in the core.

-- PaulHarvey - 30 Dec 2009

There's quite a lot of processing of these links - for example, odd char removal, wikiword making - that could equally be interpreted as "wrong". I suspect that your proposed change is going to break quite a lot. I'm inclined to agree with Markus, that only image linking of off site image-like urls be suppressed.

-- CrawfordCurrie - 06 Jan 2010

Ok, off-site URLs only.

I did a search of all the documentation in the System web. The only mention whatsoever of links to image-ish URLs generating an inline image is this sentence a couple of times:

Write %ATTACHURL%/myco.gif to see this: to see this

Updated proposal to suggest not generating images from [[external URLs]]

Reset commitment date as the proposal has changed.

If everybody would rather the "leave it alone", documentation approach, please feel free to chip in. Perhaps we can one day add some junk to the WYSIWYG editor to warn about broken image links, and offer the [<nop>[url][url]] work-around in a dialogue.

-- PaulHarvey - 06 Jan 2010

After thinking about this more, a change like this will probably be detrimental to more users than helpful.

A better solution would be to have the WYSIWYG editor accurately reflect the behaviour of these links. This would be an improvement for everybody, and would help the occasional user falling into this trap at least understand where to begin to debug their link.

Parking.

-- PaulHarvey - 06 Jan 2010