Since upgrading from Ikiwiki 2.20 to 2.32.3 (from Debian Lenny), I don't get hyperlinks to items which have a colon in their name anymore. This applies to both the normal and the archive view. Before the update, the links have been created as relative links, so they weren't usable either as the browser tried to take the part before the colon as protocol specification (as in e.g. http:). Iirc, this applied to the archive view only, links in the normal view were ok (will check this out again if it's important). Is there a way to quote each colon as %xy in the hyperlinks? Perhaps it's only a problem with my config, and not an actual bug...?
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.
The solution seems not to use colons.
In any case, htmlscrubber should get a new regexp, courtesy of dato:
[^:]+($|\/). I have tested and verified this.
Commit/patch be0b4f60 fixes this.
July 21 2008: I update this bug report as it still seems to be an issue: E.g. when creating a subpage whose name contains
a colon by inserting an appropriate wikilink in the parent page: the new page can be created using that link, but afterwards
there won't be a link to this page. Like madduck said above it seems to be htmlscrubber removing this link. However everything
works fine if the same page is being linked to from another subpage because in that case the resulting link starts with ../.
At the moment I see two possible solutions:
let all relative links at least start with
./. I haven't tested this.Escape the colon in page titles. I created the following patch which worked for me:
--- IkiWiki.pm.2.53-save 2008-07-08 15:56:38.000000000 +0200 +++ IkiWiki.pm 2008-07-21 20:41:35.000000000 +0200 @@ -477,13 +477,13 @@ sub titlepage ($) { my $title=shift; - $title=~s/([^-[:alnum:]:+\/.])/$1 eq ' ' ? '_' : "__".ord($1)."__"/eg; + $title=~s/([^-[:alnum:]+\/.])/$1 eq ' ' ? '_' : "__".ord($1)."__"/eg; return $title; } sub linkpage ($) { my $link=shift; - $link=~s/([^-[:alnum:]:+\/._])/$1 eq ' ' ? '_' : "__".ord($1)."__"/eg; + $link=~s/([^-[:alnum:]+\/._])/$1 eq ' ' ? '_' : "__".ord($1)."__"/eg; return $link; }
What do you think about that? Does the patch have any side-effects I didn't see?
I almost really fixed this in 2.53, but missed one case. All fixed now AFAICS. --Joey
Hmm, did you fix it now in 2.54? If so, I suspect there is still one little case left (might well be the last one, at least I hope so
Because wikilinks cannot have spaces, convert to underscores. --Joey
As it is put in the list of blog posts as a relative link, it starts with
<word><colon>-- this makes the browser think that "test" is a protocol specification which is to replacehttp, so it complains (at least Opera and Firefox/Iceweasel on my Debian Etch do). What I described above for subpages with this name pattern also still happens on my local install (ikiwiki 2.54 on Debian Etch), but this is basically the same problem.I think the cleanest solution would be to quote colons in page names (like it is currently done for slashes)? Starting the links with "
./", as I proposed above, now seems a bit ugly to me... --Mathias