X-Git-Url: https://sipb.mit.edu/gitweb.cgi/ikiwiki.git/blobdiff_plain/361ce5d3a989076040422daa5fe22e8c4a5136a6..9ae956e829c9aa50d978e0629ec7cda4e2854717:/doc/bugs/No_link_for_blog_items_when_filename_contains_a_colon.mdwn

diff --git a/doc/bugs/No_link_for_blog_items_when_filename_contains_a_colon.mdwn b/doc/bugs/No_link_for_blog_items_when_filename_contains_a_colon.mdwn
index b9b6a23e9..019970899 100644
--- a/doc/bugs/No_link_for_blog_items_when_filename_contains_a_colon.mdwn
+++ b/doc/bugs/No_link_for_blog_items_when_filename_contains_a_colon.mdwn
@@ -2,4 +2,75 @@ 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.
+[[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](http://git.madduck.net/v/code/ikiwiki.git?a=commit;h=be0b4f603f918444b906e42825908ddac78b7073) 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:
+
+1. let all relative links at least start with `./`. I haven't tested this.
+
+2. 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 ;-) ): I just created a test post in the sandbox here: [[sandbox/test: with a colon in its name]]
+>> (btw, why doesn't this get a hyperlink here?).
+>>
+>>> 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 replace `http`,
+>> 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
+
+>>> No, it's all [[done]] in 2.55. --[[Joey]]