URL containing .jpg interpreted wrongly as image

[DotMG]

The code below will be treated as if you wanted to insert an image, because Regex will find \.png  http://wikkawiki.org/ThisFileIsNotAnImage.pngCozItHasAnDotHtmlExtension. This will be the case if a website's domain name or url path contains .png, .gif, .jpg or .mm Ex:  http://www.jpgsrc.org/index.php will be treated as image.

File to modify: formatters/wakka.php Lines 127 and 131. Replace /^{(.*)\.(gif|jpg|png)/si by /\.(gif|jpg|png)$/si and /}(.*)\.(mm)/si by /\.(mm)$/si. I cannot do it now 'coz I don't have SVN client and I'm not yet familiar with.

[JavaWoman]

Actually, this RE occurs in a subclause of a condition with an RE which *itself* should be changed. And I thought we'd already agreed we shouldn't turn a 'raw' URL into an img tag.

Better to solve the whole URL-detection problem structurally, than to change an RE for something we shouldn't do in the first place...

My 2 (euro) cents.

[DarTar]

thought we'd already agreed we shouldn't turn a 'raw' URL into an img tag

Yes in principles, but what about backward compatibility?

[JavaWoman]

You can maintain a "type" of backward compatibility here by 1) spelling out the full URL and 2) adding a message that in order to embed the image the image action should be used.

In general, you cannot be completely backwards compatible with bugs - just make it as easy as possible to migrate to a more compliant document. By spelling out the URL people who can't edit the file can still copy & paste that into their browser if they want to see the image.

[DarTar]

OK, sounds reasonable

[DotMG]

Fixed [47]

[DarTar]

Hi DotMG, I was thinking of a way to preserve backwards compatibility and I find JW's suggestion above sensible - maybe we should add a message when inline images are parsed. I'll try to figure out what the most elegant solution is.