Merge branch 'master' into tova

Conflicts:

	debian/changelog
master
Joey Hess 2008-07-21 17:27:50 -04:00
commit 18d2403647
7 changed files with 51 additions and 4 deletions

View File

@ -538,7 +538,7 @@ sub beautify_urlpath ($) { #{{{
# 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";
}

View File

@ -25,7 +25,8 @@ sub getopt () { #{{{
sub tagpage ($) { #{{{
my $tag=shift;
if (exists $config{tagbase} &&
if ($tag !~ m{^\.?/} &&
exists $config{tagbase} &&
defined $config{tagbase}) {
$tag=$config{tagbase}."/".$tag;
}

4
debian/changelog vendored
View File

@ -6,6 +6,10 @@ ikiwiki (2.55) UNRELEASED; urgency=low
* 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

View File

@ -22,4 +22,39 @@ In any case, `htmlscrubber` should get a new regexp, courtesy of dato:
[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]]

View File

@ -0,0 +1 @@
testing a link to [[colon:problem]]

View File

@ -24,6 +24,12 @@ tags/tech, tags/life, and tags/linux. This is a useful way to avoid
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.

View File

@ -63,4 +63,4 @@ the web browser. The `rebuild` fields would be set to 1 for values that
require a wiki rebuild when changed, and to 0 for values that only need the
wrappers to be refreshed.
[[tag wishlist]]
[[!tag wishlist]]