Hi,

some operating systems use PREFIX/man instead of PREFIX/share/man as the base directory for man pages and PREFIX/libexec/ instead of PREFIX/lib/ for files like CGI programs. At the moment the location of the installed man pages and the w3m cgi wrapper is hard-coded in Makefile.PL. The patch below makes it possible to install those files to alternative directories while the default stays as it is now.

  - Introduce two variables, IKI_MANDIR and IKI_W3MCGIDIR, to be set from
    the command line. This enables locations for man pages and the w3m
    cgi wrapper other than the hard-coded defaults in Makefile.PL.

--- Makefile.PL.orig    2007-05-20 03:03:58.000000000 +0200
+++ Makefile.PL
@@ -3,9 +3,32 @@ use warnings;
 use strict;
 use ExtUtils::MakeMaker;

+my %params = ( 'IKI_MANDIR' => '$(PREFIX)/share/man',
+               'IKI_W3MCGIDIR' => '$(PREFIX)/lib/w3m/cgi-bin'
+             );
+
+@ARGV = grep {
+  my ($key, $value) = split(/=/, $_, 2);
+  if ( exists $params{$key} ) {
+    $params{$key} = $value;
+    print "Using $params{$key} for $key.\n";
+    0
+  } else {
+    1
+  }
+} @ARGV;
+
+
 # Add a few more targets.
 sub MY::postamble {
-q{
+  package MY;
+
+  my $scriptvars = <<"EOSCRIPTVARS";
+IKI_MANDIR = $params{'IKI_MANDIR'}
+IKI_W3MCGIDIR = $params{'IKI_W3MCGIDIR'}
+EOSCRIPTVARS
+
+  my $script = q{
 all:: extra_build
 clean:: extra_clean
 install:: extra_install
@@ -56,23 +79,24 @@ extra_install:
                done; \
        done

-       install -d $(DESTDIR)$(PREFIX)/share/man/man1
-       install -m 644 ikiwiki.man $(DESTDIR)$(PREFIX)/share/man/man1/ikiwiki.1
+       install -d $(DESTDIR)$(IKI_MANDIR)/man1
+       install -m 644 ikiwiki.man $(DESTDIR)$(IKI_MANDIR)/man1/ikiwiki.1

-       install -d $(DESTDIR)$(PREFIX)/share/man/man8
-       install -m 644 ikiwiki-mass-rebuild.man $(DESTDIR)$(PREFIX)/share/man/ma
n8/ikiwiki-mass-rebuild.8
+       install -d $(DESTDIR)$(IKI_MANDIR)/man8
+       install -m 644 ikiwiki-mass-rebuild.man $(DESTDIR)$(IKI_MANDIR)/man8/iki
wiki-mass-rebuild.8

        install -d $(DESTDIR)$(PREFIX)/sbin
        install ikiwiki-mass-rebuild $(DESTDIR)$(PREFIX)/sbin

-       install -d $(DESTDIR)$(PREFIX)/lib/w3m/cgi-bin
-       install ikiwiki-w3m.cgi $(DESTDIR)$(PREFIX)/lib/w3m/cgi-bin
+       install -d $(DESTDIR)$(IKI_W3MCGIDIR)
+       install ikiwiki-w3m.cgi $(DESTDIR)$(IKI_W3MCGIDIR)

        install -d $(DESTDIR)$(PREFIX)/bin
        install ikiwiki.out $(DESTDIR)$(PREFIX)/bin/ikiwiki

        $(MAKE) -C po install PREFIX=$(PREFIX)
-}
+};
+  return $scriptvars.$script;
 }

 WriteMakefile(

The default searchform.tmpl looks rather bare and unintuitive with just an input field.

The patch below adds a label for the field to improve usability:

--- templates/searchform.tmpl.orig  Fri Jun 15 15:02:34 2007
+++ templates/searchform.tmpl   Fri Jun 15 15:02:41 2007
@@ -1,5 +1,6 @@
 <form method="get" action="<TMPL_VAR SEARCHACTION>" id="searchform">
 <div>
+<label for="phrase">Search:</label>
 <input type="text" name="phrase" value="" size="16" />
 <input type="hidden" name="enc" value="UTF-8" />
 <input type="hidden" name="do" value="hyperestraier" />

The discussion for the main page is located at /index/discussion . In the header ikiwiki generates "ikiwiki / index / discussion" instead of "ikiwiki / discussion" like it should. /index/ contains no index.html file since it is at /index.html instead. The link should either be removed, or a copy of /index.html should be placed in /index/ . --TaylorKillian

The toc.pm plug-in currently renders empty 'a' tag elements. This seems to confuse at least Firefox, possibly others. The result is that the following text is rendered as an anchor (visible if you style 'a' elements in a different color).

Here is a patch for toc.pm for producing non-empty 'a' elements.

--- IkiWiki/Plugin/toc.pm.orig  Thu Jun  7 11:53:53 2007
+++ IkiWiki/Plugin/toc.pm   Thu Jun  7 13:00:00 2007
@@ -47,7 +47,7 @@ sub format (@) { #{{{
        if ($tagname =~ /^h(\d+)$/i) {
            my $level=$1;
            my $anchor="index".++$anchors{$level}."h$level";
-           $page.="$text<a name=\"$anchor\" />";
+           $page.="$text<a name=\"$anchor\">";

            # Take the first header level seen as the topmost level,
            # even if there are higher levels seen later on.
@@ -90,6 +90,16 @@ sub format (@) { #{{{
                    "</a>\n";
                $p->handler(text => undef);
            }, "dtext");
+       }
+       else {
+           $page.=$text;
+       }
+   }, "tagname, text");
+   $p->handler(end => sub {
+       my $tagname=shift;
+       my $text=shift;
+       if ($tagname =~ /^h(\d+)$/i) {
+           $page.="</a>$text";
        }
        else {
            $page.=$text;

The graphviz.pm plug-in currently attempts to read PNG data in UTF-8 mode, which sometimes fail with a message similar to the following (depending on the input):

utf8 "\x89" does not map to Unicode at /usr/local/lib/perl5/site_perl/5.8.8/IkiWiki/Plugin/graphviz.pm line 53, <IN> chunk 1.
Wide character in subroutine entry at /usr/local/lib/perl5/site_perl/5.8.8/IkiWiki/Plugin/graphviz.pm line 68.

It also generates image URLs relative to the page being rendered, which means the URLs wont work when previewing a graph from the CGI script.

The patch below fixes these two issues.

--- graphviz.pm.orig    Thu Jun  7 15:45:16 2007
+++ graphviz.pm Fri Jun  8 12:03:38 2007
@@ -41,7 +41,6 @@ sub render_graph (\%) { #{{{
        $pid=open2(*IN, *OUT, "$params{prog} -Tpng");

        # open2 doesn't respect "use open ':utf8'"
-       binmode (IN, ':utf8');
        binmode (OUT, ':utf8');

        print OUT $src;
@@ -70,7 +69,12 @@ sub render_graph (\%) { #{{{
        }
    }

-   return "<img src=\"".urlto($dest, $params{page})."\" />\n";
+   if ($params{preview}) {
+       return "<img src=\"".urlto($dest, "")."\" />\n";
+   }
+   else {
+       return "<img src=\"".urlto($dest, $params{page})."\" />\n";
+   }
 } #}}}

 sub graph (@) { #{{{

If sandbox/page.mdwn has been generated and sandbox/sidebar.mdwn is created, the sidebar is only added to sandbox and none of the subpages. --TaylorKillian

Yes, a known bug. As noted in the code: --Joey

# FIXME: This isn't quite right; it won't take into account
# adding a new sidebar page. So adding such a page
# currently requires a wiki rebuild.
add_depends($page, $sidebar_page);

I have tried --numbacklinks 0 on ikiwiki commandline, but I still get backlinks. The man page says:

--numbacklinks n
    Controls how many backlinks should be displayed maximum. 
    Excess backlinks will be hidden in a popup. 
    Default is 10. Set to 0 to disable this feature.

My first reading (and second and third) of this was that backlinks would be disabled entirely if I set numbacklinks=0, but now that I look again, I see the possibility that it is just controlling how many may be displayed before moving excess to a popup. If this is in fact how it is meant, I'll just get rid of the backlinks via the page template. Is this the case, that numbacklinks controls the popup, rather than backlinks in general?

--KarlMW

Yes, it only controls the number of backlinks that are shown at the bottom of the page vs how many are moved to the popup --Joey

I noticed when generating my wiki that all of my RSS feeds were getting regenerated even when I edited only a page that did not affect any feed.

I found that the problem only occurs in the presence of a file that contains [[inline pages="*"]].

How is this unexpected? By inlining every page in the wiki, you're making that page depend on every other page; any change to any page in the wiki will result in the inlining page and its rss feed needing to be updated to include the changed page. --Joey

Here's a short script for replicating the bug. Just cut and paste this to a shell, (it will only muck in a new /tmp/ikiwiki-test directory that it will create):

cd /tmp
mkdir ikiwiki-test; cd ikiwiki-test; mkdir src
echo '[[inline pages="blog/*"]]' > src/myblog.mdwn
mkdir src/blog; echo "A blog entry" > src/blog/entry.mdwn
echo 'use IkiWiki::Setup::Standard {
    srcdir => "src",
    destdir => "output",
    url => "http://example.com",
    templatedir => "/dev/null",
    underlaydir => "/dev/null",
    rss => 1,
    wrappers => [],
    verbose => 1,
    refresh => 1
}' > setup
ikiwiki --setup setup
ls -l --time-style=full-iso output/myblog/index.rss
echo "not a blog entry" > src/not-a-blog.mdwn
ikiwiki --setup setup
ls -l --time-style=full-iso output/myblog/index.rss
echo '[[inline pages="*"]]' > src/archives.mdwn
ikiwiki --setup setup
ls -l --time-style=full-iso output/myblog/index.rss
echo "still not blogging" >> src/not-a-blog.mdwn
ikiwiki --setup setup
ls -l --time-style=full-iso output/myblog/index.rss

Here's the tail of the output that I see for this command:

$ echo "not a blog entry" > src/not-a-blog.mdwn
$ ikiwiki --setup setup
refreshing wiki..
scanning not-a-blog.mdwn
rendering not-a-blog.mdwn
done
$ ls -l --time-style=full-iso output/myblog/index.rss
-rw-r--r-- 1 cworth cworth 459 2007-06-01 06:34:36.000000000 -0700 output/myblog/index.rss
$ echo '[[inline pages="*"]]' > src/archives.mdwn
$ ikiwiki --setup setup
refreshing wiki..
scanning archives.mdwn
rendering archives.mdwn
done
$ ls -l --time-style=full-iso output/myblog/index.rss
-rw-r--r-- 1 cworth cworth 459 2007-06-01 06:34:37.000000000 -0700 output/myblog/index.rss
$ echo "still not blogging" >> src/not-a-blog.mdwn
$ ikiwiki --setup setup
refreshing wiki..
scanning not-a-blog.mdwn
rendering not-a-blog.mdwn
rendering archives.mdwn, which depends on not-a-blog
done
$ ls -l --time-style=full-iso output/myblog/index.rss
-rw-r--r-- 1 cworth cworth 459 2007-06-01 06:34:38.000000000 -0700 output/myblog/index.rss

It looks like the rendering of archives.mdwn is also silently generating myblog/index.rss.

In setting up my wiki I followed the setup instruction which point to an ikiwiki.setup file that contains "verbose => 0".

I hadn't noticed that setting in there, but later when I changed my standard command of:

ikiwiki --setup ikiwiki.setup

to:

ikiwiki --verbose --setup ikiwiki.setup

I was quite surprised that that change didn't have any effect.

So two suggestions to fix this:

1. Make command-line arguments override settings in the setup file

2. Comment out all settings in the example setup file that are simply setting options to their default values. That way, the file will still be self-documenting, but command-line arguments will at least work for these settings while they remain commented out.

The Atom and RSS templates use ESCAPE=HTML in the title elements. However, HTML-escaped characters aren't valid according to http://feedvalidator.org/.

Removing ESCAPE=HTML works fine, but I haven't checked to see if there are any characters it won't work for.

For Atom, at least, I believe adding type="xhtml" to the title element will work. I don't think there's an equivalent for RSS.

Removing the ESCAPE=HTML will not work, feed validator hates that just as much. It wants rss feeds to use a specific style of escaping that happens to work in some large percentage of all rss consumers. (Most of which are broken). http://www.rssboard.org/rss-profile#data-types-characterdata There's also no actual spec about how this should work.

This will be a total beast to fix. The current design is very clean in that all (well, nearly all) xml/html escaping is pushed back to the templates. This allows plugins to substitute fields in the templates without worrying about getting escaping right in the plugins -- and a plugin doesn't even know what kind of template is being filled out when it changes a field's value, so it can't do different types of escaping for different templates.

The only reasonable approach seems to be extending HTML::Template with an ESCAPE=RSS and using that. Unfortunately its design does not allow doing so without hacking its code in several places. I've contacted its author to see if he'd accept such a patch.

(A secondary bug is that using meta title currently results in unnecessry escaping of the title value before it reaches the template. This makes the escaping issues show up much more than they need to, since lots more characters are currently being double-escaped in the rss.)

--Joey

Update: Ok, I've fixed this for titles, as a special case, but the underlying problem remains for other fields in rss feeds (such as author), so I'm leaving this bug report open. --Joey

In markdown syntax, none of the other special characters get processed inside a code block. However, in ikiwiki, wiki links and preprocessor directives still get processed inside a code block, requiring additional escaping. For example, [links don't work](#here), but a <a href="wikilink.html">wikilink</a> becomes HTML. --JoshTriplett

Indented lines provide a good way to escape a block of text containing markdown syntax, but ikiwiki links like this are still interpreted within such a block. I think that intepretation should not be happening. That is I should be able to write:

this

and have it render like:

this

--cworth

RSS output contains relative links. Ie. http://kitenet.net/~joey/blog/index.rss contains a link to http://kitenet.net/~joey/blog/../blog.html

Hello,

I had to fix a location of one page in my repo via svn move and now I have a problem with rebuilding my ikiwiki pages:

ikiwiki --setup ikiwiki.setup
[...]
tworzenie strony ubuntu/linki.mdwn
tworzenie strony knoppix/bootowalny_pendrive_usb.mdwn
tworzenie strony helponformatting.mdwn
Insecure dependency in eval while running with -T switch at /usr/share/perl5/IkiWiki/Plugin/conditional.pm line 30.
BEGIN failed--compilation aborted at (eval 5) line 110.

Temporarily I've disabled conditional plugin to avoid that bug.

PS. I still use ikiwiki 1.50 backported for Debian 'sarge'.

--Pawel

Hello again

I've just builded successfully ikiwiki 2.00 package for Debian 'sarge'. Unfortunately, now I still can't to rebuild my ikiwiki pages:

ikiwiki --setup ikiwiki.setup
[...]
renderowanie ikiwiki/backport.mdwn
renderowanie ikiwiki/instalacja.mdwn
renderowanie ikiwiki/problemy.mdwn
Insecure dependency in eval while running with -T switch at /usr/share/perl5/IkiWiki.pm line 1005.
BEGIN failed--compilation aborted at (eval 5) line 111.

I didn't apply your following old patch against Ikiwiki.pm file:

--- IkiWiki.pm-orig 2007-05-10 11:16:47.000000000 +0200
+++ IkiWiki.pm      2007-05-10 11:16:07.000000000 +0200
@@ -993,7 +993,18 @@
    my $spec=shift;
    my $from=shift;

-   return eval pagespec_translate($spec);
+   my $pagespec = pagespec_translate($spec);
+
+   my $newpagespec;
+
+   local($1);
+   if ($pagespec =~ /(.*)/) {
+           $newpagespec = $1;
+   } else {
+           die "oh";
+   }
+
+   return eval $newpagespec;
 } #}}}

 package IkiWiki::PageSpec;

because patch command fails:

patch -p0 < ../IkiWiki.pm.patch 
patching file IkiWiki.pm
Hunk #1 FAILED at 993.
1 out of 1 hunk FAILED -- saving rejects to file IkiWiki.pm.rej

Could you please fix that patch? I guess how to do it, but I don't want to break the code I distribute in my backport

--Pawel

It's not my patch.. IIRC my suggestion was simply to do this: --[Joey]]

Index: IkiWiki.pm
===================================================================
--- IkiWiki.pm  (revision 3565)
+++ IkiWiki.pm  (working copy)
@@ -1005,7 +1005,7 @@
        unshift @params, "location";
    }

-   my $ret=eval pagespec_translate($spec);
+   my $ret=eval possibly_foolish_untaint(pagespec_translate($spec));
    return IkiWiki::FailReason->new("syntax error") if $@;
    return $ret;
 } #}}}

Thanks a lot, Joey! It works

BTW, I was quite sure that you sent me the old patch via e-mail long time ago. Maybe I found it at old ikiwiki home page? I don't remember it now.

--Pawel

(Note: feel free to say "not a bug" or offer a workaround rather than changing ikiwiki.)

As reported by a Windows user trying ikiwiki: because Windows doesn't support filenames with colons, he couldn't check out the ikiwiki svn repository. More generally, ikiwiki doesn't encode colons in filenames for wiki pages, but to support Windows users perhaps it should.

Windows does not support filenames containing any of these characters: / \ * : ? " < > |

I take it this is a problem when checking out a wiki in windows, not when browsing to urls that have colons in them from windows? --Joey

Correct. You can't directly check out a wiki's repository from Windows if it includes filenames with those characters; you will get errors on those filenames.

After editing a page pagename, ikiwiki redirects to pagename/index.html?updated. Ignoring for the moment that ?updated seems like a bad idea to begin with, this should at least not introduce /index.html into the URL.

A trailing slash on a wikilink breaks the link:

appears as .

Gallery appears as Gallery.

--JoshTriplett

Ikiwiki does not seem to support non-UTF-8 file content, although there's no reason it should assume anything other than ASCII-compatibility from the encoding, at least if the Web interface is not used. It suffices that users use the same encoding as the templates specify. If I try to run it on .mdwn with content in ISO-8859-1 format, in an ISO-8859-1 locale, I get:

Malformed UTF-8 character (unexpected non-continuation byte 0x74, immediately after start byte 0xe4) in substitution iterator at /usr/local/share/perl/5.8.8/IkiWiki.pm line 640.

I hope Ikiwiki is not part of the UTF-8 monoculturist movement...

Web browsers don't word-wrap lines in submitted text, which makes editing a page that someone wrote in a web browser annoying (gqip is vim user's friend here). Is there any way to improve this?

See "using the web interface with a real text editor" on the tips page. --JoshTriplett

Would it be useful to allow a "max width" plugin, which would force on commit the split of long lines ?

Please, no. That would wreak havoc on code blocks and arguments to preprocessor directives, and it would make bulleted lists and quoted blocks look bogus (because the subsequent lines would not match), among other problems. On the other hand, if you want to propose a piece of client-side JavaScript that looks at the active selection in a text area and word-wraps it, and have a plugin that adds a "Word-Wrap Selection" button to the editor, that seems fine. --JoshTriplett

My backported ikiwiki 1.48 converts smileys in the block code incorrectly. I can see the HTML code of smileys image, instead of smileys image.

For example, I'd like to save interesting for me thread of courier-users mailing list. Please looks below to see what ikiwiki does with that smileys:

From: Bernd Wurst <bernd@bw...>
Subject: Re: [courier-users] Uploaded my SRS implementation for courier to
    the web
To: courier-users@li...
Date: Sat, 17 Mar 2007 19:02:10 +0100

Hi.

Am Samstag, 17. Mrz 2007 schrieb Matthias Wimmer:
> See the graphic on http://www.openspf.org/SRS at the bottom on the left
> side. You will find an example there how rewriting an already rewritten
> address works.

Ah, ok, didn't know that. <img src="smileys/smile.png" alt=":)" />
Thanks for the pointer!

cu, Bernd

BTW, maybe converting smileys in the block code should be disabled at all?

--Pawel

Looks similar to wiki links still processed inside code blocks; in both cases, substitution happens in a code block, which it shouldn't. --JoshTriplett

The header of subpages always links to its "superpage", even if it doesn't exist. I'm not sure if this is a feature or a bug, but I would certainly prefer that superpages weren't mandatory.

For example, if you are in 'example/page.html', the header will be something like 'wiki / example / page'. Now, if 'example.html' doesn't exist, you'll have a dead link for every subpage.

This is a bug, but fixing it is very tricky. Consider what would happen if example.mdwn were created: example/page.html and the rest of example/* would need to be updated to change the parentlink from a bare work to a link to the new page. Now if example.mdwn were removed again, they'd need to be updated again. So example/* depends on example. But it's even more tricky, because if example.mdwn is modified, we don't want to rebuild example/*!

ikiwiki doesn't have a way to represent this dependency and can't get one without a lot of new complex code being added.

For now the best thing to do is to make sure that you always create example if you create example/foo. Which is probably a good idea anyway..

Note that this bug does not exist if the wiki is built with the "usedirs" option, since in that case, the parent link will link to a subdirectory, that will just be missing the index.html file, but still nicely usable.

ikiwiki 1.45 doesn't work properly for perl installs not in the system path.

ie:

~/tools/perl-5.8.8/perl Makefile.PL make

fails, as the 'make' command attempts to use the perl install in PATH, rather than the one ikiwiki is being installed for.

The installed bin/ikiwiki file also refers to /usr/bin/perl rather than the perl it is being installed for.

I will acdept sufficiently nonintrusive patches to make ikiwiki work better on strange systems like yours, but do not plan to work on it myself, since I do not use systems where /usr/bin/perl is not a sane default. --Joey

• Has bugs updating things if the bestlink of a page changes due to adding/removing a page. For example, if Foo/Bar links to "Baz", which is Foo/Baz, and Foo/Bar/Baz gets added, it will update the links in Foo/Bar to point to it, but will forget to update the linkbacks in Foo/Baz.

• And if Foo/Bar/Baz is then removed, it forgets to update Foo/Bar to link back to Foo/Baz.

As of 1.33, this is still true. The buggy code is the %linkchanged calculation in refresh(), which doesn't detect that the link has changed in this case.

Still true in 1.43 although the code is much different now..

The diff links in RecentChanges go to a viewvc backtrace if the rev in question is when the page was added. Is this a viewvc bug, or a behavior ikiwiki needs to work around? - As a special case, there should certianly be no history link for pages generated from the underlaydir as it can never work for them.

It seems that I can't use Polish characters in post title. When I try to do it, then I can see error message: "Błąd: bad page name".

I hope it's a bug, not a feature and you fix it soon --Pawel

ikiwiki only allows a very limited set of characters raw in page names, this is done as a deny-by-default security thing. All other characters need to be encoded in code format, where "code" is the character number. This is normally done for you, but if you're adding a page manually, you need to handle it yourself. --Joey

Assume I have my own blog and I want to send a new post with Polish characters in a title. I think it's totally normal and common thing in our times. Do you want to tell me I shouldn't use my native characters in the title? It can't be true

In my opinion encoding of title is a job for the wiki engine, not for me. Joey, please try to look at a problem from my point of view. I'm only user and I don't have to understand what the character number is. I only want to blog

BTW, why don't you use the modified-UTF7 coding for page names as used in IMAP folder names with non-Latin letters? --Pawel

Joey, do you intend to fix that bug or it's a feature for you? --Pawel

Of course you can put Polish characters in the title. but the page title and filename are not identical. Ikiwiki has to place some limits on what filenames are legal to prevent abuse. Since the safest thing to do in a security context is to deny by default and only allow a few well-defined safe things, that's what it does, so filenames are limited to basic alphanumeric characters.

It's not especially hard to transform your title into get a legal ikiwiki filename:

joey@kodama:~>perl -MIkiWiki -le 'print IkiWiki::titlepage(shift).".mdwn"' "Błąd"
B__197____130____196____133__d.mdwn

Thanks for the hint! It's good for me, but rather not for common users

Interesting... I have another result:

   perl -MIkiWiki -le 'print IkiWiki::titlepage(shift).".mdwn"' "Błąd"
   B__179____177__d.mdwn

What's your locale? I have both pl_PL (ISO-8859-2) and pl_PL.UTF-8, but I use pl_PL. Is it wrong? --Pawel

Now, as to UTF7, in retrospect, using a standard encoding might be a better idea than coming up with my own encoding for filenames. Can you provide a pointer to a description to modified-UTF7? --Joey

The modified form of UTF7 is defined in RFC 2060 for IMAP4 protocol (please see section 5.1.3 for details).

There is a Perl Unicode::IMAPUtf7 module at the CPAN, but probably it hasn't been debianized yet --Pawel

If a file in the srcdir is removed, exposing a file in the underlaydir, ikiwiki will not notice the change and rebuild it until the file in the underlaydir gets a mtime newer than the mtime the removed file had.

Relatedly, if there are two files with different extensions that build a page with the same name, in a directory, ikiwiki will update the page whenever either changes, using the changed one as the source. But if that most recently changed one is removed, it won't rebuild the page using the older one as the source.

I'm using the tags plugin with tagbase="tags".

Already existing tags, corresponding to pages like tags/foo.html work just fine.

If I add to a page a tag which is not existing (e.g. with ) the just modified page will have a link which point to tags/newtag. This is in theory correct, but in practice leads to creating a tags/newtag subpage of the page I'm editing, while my tagbase is supposed to be relative to the wiki root.

When used in a wiki which already have some tags this leads to mixing up tags located in tags/ and tags located in whatever/tags/.

When a new page is being edited, ikiwiki lets you chose where the page will be created, so you'll get a dropdown list of possible locations for the tag page. You should be able to choose between either tags/foo or page/tags/foo.

The way that ikiwiki decides which location to default to in this box is fairly involved; but in general it will default to creating the page at the same level as the tagged page. So if the tag is on any toplevel page in the wiki, it will default to creating tags/foo; if the tag is on a page in a subdirectory, it will default to creating subdir/tags/foo.

I personally like this behavior; it allows me to create a subdirectory for a particular thing and use tags that are specific to that thing, which are kept confined to that subdirectory by default. For example, this is used for ikiwiki's own plugins tags, which are all located under plugins/type/* and which apply to pages under plugins/*.

It's clearly not the right default for every situation though. Explcitly setting a tagbase probably lessons the likelyhood that it's the right default for things under that tag base. I'd not be opposed to adding a special case to change the default in this case, or adding a configuration option to change the default globally. On the other hand, it is pretty simple to just check the location and select the right one from the list when creating a new page..

--Joey

ikiwiki will generate html formatted error messages to the command line if --cgi is set, even if it's not yet running as a cgi