urosm
/
ikiwiki
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

web commit by http://madduck.myopenid.com/: add analysis based on rfc3986 and suggest a new regexp

master
Joey Hess 2008-02-29 13:21:24 -05:00
parent 7129554701
commit 8ebf6acd80
1 changed files with 15 additions and 0 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

15
doc/bugs/No_link_for_blog_items_when_filename_contains_a_colon.mdwn
View File

@ -3,3 +3,18 @@ Since upgrading from Ikiwiki 2.20 to 2.32.3 (from Debian Lenny), I don't get hyp
EDIT: I just found that in this wiki under <http://ikiwiki.info/bugs/done/> the entry "mailto: links not properly generated in rss/atom feeds" also doesn't have a hyperlink - at least it's not a problem with my config only ;-)
[[madduck]]: I traced this down to `htmlscrubber`. If disabled, it works. If enabled, then `$safe_url_regexp` determines the URL unsafe because of the colon and hence removes the `src` attribute.
Digging into this, I find that [[rfc 3986]] pretty much discourages colons in
filenames:
> A path segment that contains a colon character (e.g., "this:that") cannot be
> used as the first segment of a relative-path reference, as it would be
> mistaken for a scheme name. Such a segment must be preceded by
> a dot-segment (e.g., "./this:that") to make a relative- path reference.
on the other hand, with `usedirs`, any link to another page will be prepended
by `../` anyway, so that makes them okay again.
The solution still seems not to use colons.
In any case, `htmlscrubber` should get a new regexp, courtesy of dato: `[^:]+($|\/)`. I have tested and verified this.