# Ensure url is not an empty link, and
# if it's relative, make that explicit to avoid colon confusion.
- if ($url !~ /\//) {
+ if ($url !~ /^\//) {
$url="./$url";
}
sub tagpage ($) { #{{{
my $tag=shift;
- if (exists $config{tagbase} &&
+ if ($tag !~ m{^\.?/} &&
+ exists $config{tagbase} &&
defined $config{tagbase}) {
$tag=$config{tagbase}."/".$tag;
}
* All rcs backends need to implement rcs_remove. (Done for svn, git).
* remove: New plugin that adds the ability to remove pages via the web.
(Sponsored by The TOVA Company.)
+ * tag: Allow tagbase to be overridden by starting a tag with "./" or "/".
+ (Simon McVittie)
+ * Really fix bug with links to pages with names containing colons.
+ Previous fix mised a few cases.
-- Joey Hess <joeyh@debian.org> Mon, 21 Jul 2008 11:35:46 -0400
[Commit/patch
be0b4f60](http://git.madduck.net/v/code/ikiwiki.git?a=commit;h=be0b4f603f918444b906e42825908ddac78b7073) fixes this.
-[[done]]
+
+**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]]
+
+[[tag done]]
--- /dev/null
+testing a link to [[colon:problem]]
having to write the full path to tags, if you want to keep them grouped
together out of the way.
+If you want to override the tagbase for a particular tag, you can use
+something like this:
+
+ \[[!tag ./foo]]
+ \[[!taglink /foo]]
+
[[!if test="enabled(tag)" then="""
This wiki has the tag plugin enabled, so you'll see a note below that this
page is tagged with the "tags" tag.
require a wiki rebuild when changed, and to 0 for values that only need the
wrappers to be refreshed.
-[[tag wishlist]]
+[[!tag wishlist]]