Merge remote branch 'upstream/master' into prv/po

Conflicts:
	IkiWiki/Plugin/po.pm

32 files changed, 781 insertions, 25 deletions

diff --git a/doc/forum/Can_OpenID_users_be_adminusers__63__.mdwn b/doc/forum/Can_OpenID_users_be_adminusers__63__.mdwn
index 7599e71e5..17c60c423 100644
--- a/doc/forum/Can_OpenID_users_be_adminusers__63__.mdwn
+++ b/doc/forum/Can_OpenID_users_be_adminusers__63__.mdwn
@@ -62,7 +62,7 @@ index 0bf100a..77b467a 100644
 
 >>>> So you can see if the two usernames/openids match. If the end is "0",
 >>>> they don't match. If nothing is logged, you have not enabled the websetup plugin.
->>>> If the end if "1" you should see the "Wiki Setup" button, if not the
+>>>> If the end if "1" you should see the "Setup" button, if not the
 >>>> problem is not in determining if you're an admin, but elsewhere..
 >>>> --[[Joey]]
 
diff --git a/doc/forum/Error:_bad_page_name.mdwn b/doc/forum/Error:_bad_page_name.mdwn
new file mode 100644
index 000000000..70277a1e4
--- /dev/null
+++ b/doc/forum/Error:_bad_page_name.mdwn
@@ -0,0 +1,46 @@
+I'm trying to use ikiwiki for the first time. In the start, I had problems
+with installing the package, because I don't have a root account on my
+server.
+
+When I solved this, I finally set up my wiki, but whenever I try to edit a
+page, I get an error: “Error: bad page name”.
+
+What am I doing wrong? The wiki is at
+<http://atrey.karlin.mff.cuni.cz/~onderka/wiki/>, the setupfile I used at
+<http://atrey.karlin.mff.cuni.cz/~onderka/wiki/ikiwiki.setup>.
+
+> This means that one of the checks that ikiwiki uses to prevent
+> editing files with strange or insecure names has fired incorrectly.
+> Your setup file seems fine.
+> We can figure out what is going wrong through a series of tests:
+> 
+> * Test if your perl has a problem with matching alphanumerics:
+>   `perl -le 'print int "index"=~/^([-[:alnum:]+\/.:_]+)$/'`
+> * Check if something is breaking pruning of disallowed files:
+>   `perl -le 'use IkiWiki; %config=IkiWiki::defaultconfig(); print ! IkiWiki::file_pruned("index")'`
+> --[[Joey]] 
+
+>>Both seem to run fine:
+
+    onderka@atrey:~$ perl -le 'print int "index"=~/^([-[:alnum:]+\/.:_]+)$/'
+    1
+    onderka@atrey:~$ perl -le 'use IkiWiki; %config=IkiWiki::defaultconfig(); print ! IkiWiki::file_pruned("index")'
+    1
+
+>>> Try installing this [instrumented
+>>> version](http://kitenet.net/~joey/tmp/editpage.pm) of
+>>> `IkiWiki/Plugin/editpage.pm`, which will add some debugging info
+>>> to the error message. --[[Joey]] 
+
+>>>>When I tried to `make` ikiwiki with this file, I got the error
+
+    ../IkiWiki/Plugin/editpage.pm:101: invalid variable interpolation at "$"
+
+>>>>> Sorry about that, I've corrected the above file. --[[Joey]] 
+
+>>>>>> Hmm, funny. Now that I reinstalled it with your changed file, it started working. I didn't remember how exactly did I install it the last time, so this time, it seems I did it correctly. Thank you very much for your help.
+
+>>>>>>> Well, this makes me suspect you installed an older version of
+>>>>>>> ikiwiki and my file, which is from the latest version, included a
+>>>>>>> fix for whatever bug you were seeing. If I were you, I'd ensure
+>>>>>>> that I have a current version of ikiwiki installed. --[[Joey]] 
diff --git a/doc/forum/How_does_ikiwiki_remember_times__63__.mdwn b/doc/forum/How_does_ikiwiki_remember_times__63__.mdwn
index 6ce576db1..6b7739fd0 100644
--- a/doc/forum/How_does_ikiwiki_remember_times__63__.mdwn
+++ b/doc/forum/How_does_ikiwiki_remember_times__63__.mdwn
@@ -20,15 +20,17 @@ Do I have it right?
 > Some VCS, like git, set the file mtimes to the current time
 > when making a new checkout, so they will be lost if you do that.
 > The creation times can be retrived using the `--getctime` option.
-> I suppose it might be nice if there were a `--getmtime` that pulled
-> true modification times out of the VCS, but I haven't found it a big
-> deal in practice for the last modification times to be updated to the
-> current time when rebuilding a wiki like this. --[[Joey]] 
+> --[[Joey]] 
 >
 > > Thanks for the clarification. I ran some tests of my own to make sure I understand it right, and I'm satisfied
 > > that the order of posts in my blog can be retrieved from the VCS using the `--getctime` option, at least if I
 > > choose to order my posts by creation time rather than modification time. But I now know that I can't rely on
 > > page modification times in ikiwiki as these can be lost permanently.
+> 
+> > > Update: It's now renamed to `--gettime`, and pulls both the creation
+> > > and modification times. Also, per [[todo/auto_getctime_on_fresh_build]],
+> > > this is now done automatically the first time ikiwiki builds a
+> > > srcdir. So, no need to worry about this any more! --[[Joey]] 
 > >
 > > I would suggest that there should at least be a `--getmtime` option like you describe, and perhaps that 
 > > `--getctime` and `--getmtime` be _on by default_. In my opinion the creation times and modification times of 
@@ -91,19 +93,6 @@ Do I have it right?
 > A quick workaround for me to get modification times right is the following
 > little zsh script, which unfortunately only works for git:
 
-    #!/usr/bin/env zsh
-    
-    set +x
-    
-    for FILE in **/*(.); do
-      TIMES="`git log --pretty=format:%ai $FILE`"
-      MTIME="`echo $TIMES | head -n1`"
-    
-      if [ ! -z $MTIME ]; then
-        echo  touch -m -d "$MTIME" $FILE
-        touch -m -d "$MTIME" $FILE
-      fi
-    
-    done
+>> Elided; no longer needed since --gettime does that, and much faster! --[[Joey]] 
 
 > --[[David_Riebenbauer]]
diff --git a/doc/forum/Migrating_old_repository_to_new_ikiwiki_system__63__.mdwn b/doc/forum/Migrating_old_repository_to_new_ikiwiki_system__63__.mdwn
index fe67e6aba..d7a33b526 100644
--- a/doc/forum/Migrating_old_repository_to_new_ikiwiki_system__63__.mdwn
+++ b/doc/forum/Migrating_old_repository_to_new_ikiwiki_system__63__.mdwn
@@ -20,10 +20,6 @@ How do I set up an ikiwiki system using a pre-existing repository (instead of cr
 >    recreate the ikiwiki srcdir
 > 3. `git clone` from the bare git repository a second time,
 >    to create a checkout you can manually edit (optional)
-> 4. run `ikiwiki --getctime --setup your.setup`
->    The getctime will ensure page creation times are accurate
->    by putting the info out of the git history,
->    and only needs to be done once.
 >
 > If you preserved your repository, but not the setup file,
 > the easiest way to make one is probably to run
diff --git a/doc/forum/PERL5LIB__44___wrappers_and_homedir_install.mdwn b/doc/forum/PERL5LIB__44___wrappers_and_homedir_install.mdwn
new file mode 100644
index 000000000..fba941efc
--- /dev/null
+++ b/doc/forum/PERL5LIB__44___wrappers_and_homedir_install.mdwn
@@ -0,0 +1,38 @@
+What is the way to tell wrappers that PERL5LIB should include ~/bin directories?
+
+Having this in the wiki.setup doesn't help anymore:
+
+        # environment variables
+        ENV => {
+          PATH => '/home/user/bin/bin:/usr/local/bin:/usr/bin:/bin:/usr/games:/home/user/ikiwiki/usr/bin/:/home/user/ikiwiki/usr/sbin/:/home/user/bin/bin/:~/bin/bin/',
+          PERL5LIB => '/home/user/bin/share/perl/5.10.0:/home/user/bin/lib/perl/5.10.0'
+        },
+
+Or at least I get CGI errors and running ikiwiki.cgi manually fails too:
+
+        Use of uninitialized value $tainted in pattern match (m//) at /usr/share/perl5/IkiWiki.pm line 233.
+        Argument "" isn't numeric in umask at /usr/share/perl5/IkiWiki.pm line 139.
+        Undefined subroutine &IkiWiki::cgierror called at /home/user/bin/bin/ikiwiki line 199.
+
+Server has an older ikiwiki installed but I'd like to use a newer version from git, and I don't have root access.
+
+> You can't set `PERL5LIB` in `ENV` in a setup file, because ikiwiki is already
+> running before it reads that, and so it has little effect. Your error
+> messages do look like a new bin/ikiwiki is using an old version of
+> `IkiWiki.pm`.
+> 
+> The thing to do is set `INSTALL_BASE` when you're installing ikiwiki from
+> source. Like so:
+
+        cd ikiwiki
+        perl Makefile.PL INSTALL_BASE=$HOME PREFIX=
+        make install
+
+> Then `$HOME/bin/ikiwiki` will have hardcoded into it to look
+> for ikiwiki's perl modules in `$HOME/lib/perl5/`
+> (This is documented in the README file by the way.) --[[Joey]] 
+
+>> Ok, *perl Makefile.PL INSTALL_BASE=$HOME/bin PREFIX=* finally did it for me. I tried too many things with
+>> these paths so I wasn't sure which actually worked. After that I did 
+>> *$ ikiwiki --setup www.setup --wrappers --rebuild*. Somehow in this update mess I seem to have lost the user
+>> accounts, maybe the --rebuild was too much.
diff --git a/doc/forum/Render_more_than_one_dest_page_from_same_source_page.mdwn b/doc/forum/Render_more_than_one_dest_page_from_same_source_page.mdwn
new file mode 100644
index 000000000..e7362c903
--- /dev/null
+++ b/doc/forum/Render_more_than_one_dest_page_from_same_source_page.mdwn
@@ -0,0 +1,51 @@
+Is it possible to render more than one destination page from the same source page?
+That is, same source, slightly different presentation at the other end, needing a different output file.
+
+> It's possible to render more than one output _file_ from a given source
+> page. See, for example, the inline plugin's generation of rss files.
+> This is done by calling `will_render()` and using `writefile()` to
+> generate the additional files. Probably in a format hook if you want
+> to generate html files.
+
+>> Thanks for the tip, I'll take a look at that. -- [[KathrynAndersen]]
+ 
+> It's not possible for one source file to represent multiple wiki pages.
+> There is a 1:1 mapping between source filenames and page names. The
+> difference between wiki pages and output files is that you can use
+> wikilinks to link to wiki pages, etc. --[[Joey]] 
+
+I have two problems that would be solved by being able to do this.
+
+[[!toc startlevel=2]]
+
+##"full" and "print" versions of a page.
+
+One has a page "foo", which is rendered into foo.html.
+One also wants a foo-print.html page, which uses "page-print.tmpl" rather than "page.tmpl" as its template.
+
+I want to do this for every page on the site, automatically, so it isn't feasible to do it by hand.
+
+> Did you know that ikiwiki's `style.css` arranges for pages to display
+> differently when printed out? Things like the Action bar are hidden in
+> printouts (search for `@media print`). So I don't see a reason to need
+> whole files for printing when you can use these style sheet tricks.
+> --[[Joey]] 
+
+>>Fair enough. --[[KathrynAndersen]]
+
+##"en" and "en-us" versions of a page.
+
+My site is in non-US English.  However, I want US-English people to find my site when they search for it when they use US spelling on certain search terms (such as "optimise" versus "optimize").  This requires a (crude) US-English version of the site where the spellings are changed automatically, and the LANG is "en-us" rather than "en".  (No, don't tell me to use keywords; Google ignores keywords and has for a number of years).
+
+So I want the page "foo" to render to "foo.en.html" and "foo.en-us.html" where the content is the same, just some automated word-substitution applied before foo.en-us.html is written.  And do this for every page on the site.
+
+I can't do this with the "po" plugin, as it considers "en-us" not to be a valid language.  And the "po" plugin is probably overkill for what I want anyway.
+
+But I'm not sure how to achieve the result I need.
+
+-- [[KathrynAndersen]]
+
+> Sounds like this could be considered a single page that generates two
+> html files, so could be handled per above. --[[Joey]] 
+
+>>Thanks! --[[KathrynAndersen]]
diff --git a/doc/forum/The_requested_URL___47____126__jean__47__blog__47__ikiwiki.cgi_was_not_found_on_this_server..mdwn b/doc/forum/The_requested_URL___47____126__jean__47__blog__47__ikiwiki.cgi_was_not_found_on_this_server..mdwn
new file mode 100644
index 000000000..4061a7348
--- /dev/null
+++ b/doc/forum/The_requested_URL___47____126__jean__47__blog__47__ikiwiki.cgi_was_not_found_on_this_server..mdwn
@@ -0,0 +1,11 @@
+Hi,
+Installed ikiwiki on my ubuntu (04.10) box; after creating a blog according to your setup instructions I cannot edit files on the web interface, and I get this errer «The requested URL /~jean/blog/ikiwiki.cgi was not found on this server.»
+I have no idea what to do (sorry for my ignorance)
+
+tia,
+
+> Make sure you have a `~/public_html/ikiwiki.cgi`. Your setup
+> file should generate that via the `cgi_wrapper` option.
+> 
+> Maybe you need to follow the [[tips/dot_cgi]] tip to make apache see it.
+> --[[Joey]]
diff --git a/doc/forum/The_requested_URL___47____126__jean__47__blog__47__ikiwiki.cgi_was_not_found_on_this_server./comment_1_d36ce6fab90e0a086ac84369af38d205._comment b/doc/forum/The_requested_URL___47____126__jean__47__blog__47__ikiwiki.cgi_was_not_found_on_this_server./comment_1_d36ce6fab90e0a086ac84369af38d205._comment
new file mode 100644
index 000000000..f95972c4f
--- /dev/null
+++ b/doc/forum/The_requested_URL___47____126__jean__47__blog__47__ikiwiki.cgi_was_not_found_on_this_server./comment_1_d36ce6fab90e0a086ac84369af38d205._comment
@@ -0,0 +1,16 @@
+[[!comment format=mdwn
+ username="jeanm"
+ subject="comment 1"
+ date="2010-06-19T13:35:37Z"
+ content="""
+OK, I followed the dot cgi tip and this error diappears, thanks a lot! So ubuntu doesn't provide a \"working out of the box\" ikiwiki.
+
+But I get a new error message now when trying to edit a page:
+
+Error: \"do\" parameter missing
+
+My plugins now:
+add_plugins => [qw{goodstuff websetup comments blogspam 404 muse}],
+
+
+"""]]
diff --git a/doc/forum/The_requested_URL___47____126__jean__47__blog__47__ikiwiki.cgi_was_not_found_on_this_server./comment_2_5836bba08172d2ddf6a43da87ebb0332._comment b/doc/forum/The_requested_URL___47____126__jean__47__blog__47__ikiwiki.cgi_was_not_found_on_this_server./comment_2_5836bba08172d2ddf6a43da87ebb0332._comment
new file mode 100644
index 000000000..0a544eeb1
--- /dev/null
+++ b/doc/forum/The_requested_URL___47____126__jean__47__blog__47__ikiwiki.cgi_was_not_found_on_this_server./comment_2_5836bba08172d2ddf6a43da87ebb0332._comment
@@ -0,0 +1,7 @@
+[[!comment format=mdwn
+ username="http://joey.kitenet.net/"
+ subject="do parameter missing"
+ date="2010-06-23T17:03:12Z"
+ content="""
+That's an unusual problem. Normally the url or form that calls ikiwiki.cgi includes a \"do\" parameter, like \"do=edit\". I'd have to see the site to debug why it is missing for you.
+"""]]
diff --git a/doc/forum/an_alternative_approach_to_structured_data.mdwn b/doc/forum/an_alternative_approach_to_structured_data.mdwn
index fb007f7e9..6e6af8adb 100644
--- a/doc/forum/an_alternative_approach_to_structured_data.mdwn
+++ b/doc/forum/an_alternative_approach_to_structured_data.mdwn
@@ -1,3 +1,5 @@
+## First Pass
+
 Looking at the discussion about [[todo/structured_page_data]], it looks a bit like folks are bogged down in figuring out what *markup* to use for structured page data, something I doubt that people will really agree on.  And thus, little progress is made.
 
 I propose that, rather than worry about what the data looks like, that we take a similar approach
@@ -15,3 +17,47 @@ I think it could be really powerful and useful, especially if it becomes part of
 --[[KathrynAndersen]]
 
 > It looks like an interesting idea.  I don't have time right now to look at it in depth, but it looks interesting. -- [[Will]]
+
+> I agree such a separation makes some sense. But note that the discussion on [[todo/structured_page_data]]
+> talks about associating data types with fields for a good reason: It's hard to later develop a good UI for
+> querying or modifying a page's data if all the data has an implicit type "string". --[[Joey]]
+
+>> I'm not sure that having an implicit type of "string" is really such a bad thing.  After all, Perl itself manages with just string and number, and easily converts from one to the other.  Strong typing is generally used to (a) restrict what can be done with the data and/or (b) restrict how the data is input.  The latter could be done with some sort of validated form, but that, too, could be decoupled from looking up and returning the value of a field. --[[KathrynAndersen]]
+
+## Second Pass
+
+I have written additional plugins which integrate with the [[plugins/contrib/field]] plugin to both set and get structured page data.
+
+* [[plugins/contrib/getfield]] - query field values inside a page using {{$*fieldname*}} markup
+* [[plugins/contrib/ftemplate]] - like [[plugins/template]] but uses "field" data as well as passed-in data
+* [[plugins/contrib/ymlfront]] - looks for YAML-format data at the front of a page; this is just one possible back-end for the structured data
+
+--[[KathrynAndersen]]
+
+> I'm not an IkiWiki committer ([[Joey]] is the only one I think)
+> but I really like the look of this scheme. In particular,
+> having `getfield` interop with `field` without being *part of*
+> `field` makes me happy, since I'm not very keen on `getfield`'s
+> syntax (i.e. "ugh, yet another mini-markup-language without a
+> proper escaping mechanism"), but this way people can experiment
+> with different syntaxes while keeping `field` for the
+> behind-the-scenes bits.
+>
+>> I've started using `field` on a private site and it's working
+>> well for me; I'll try to do some code review on its
+>> [[plugins/contrib/field/discussion]] page. --s
+>
+> My [[plugins/contrib/album]] plugin could benefit from
+> integration with `field` for photos' captions and so on,
+> probably... I'll try to work on that at some point.
+>
+> [[plugins/contrib/report]] may be doing too much, though:
+> it seems to be an variation on `\[[inline archive="yes"]]`,
+> with an enhanced version of sorting, a mini version of
+> [[todo/wikitrails]], and some other misc. I suspect it could
+> usefully be divided up into discrete features? One good way
+> to do that might be to shuffle bits of its functionality into
+> the IkiWiki distribution and/or separate plugins, until there's
+> nothing left in `report` itself and it can just go away.
+>
+> --[[smcv]]
diff --git a/doc/forum/debian_backports_update_someone_please.mdwn b/doc/forum/debian_backports_update_someone_please.mdwn
new file mode 100644
index 000000000..7102d12a1
--- /dev/null
+++ b/doc/forum/debian_backports_update_someone_please.mdwn
@@ -0,0 +1,18 @@
+I'm just in the process of deploying ikiwiki and I'd love to use it in the html5 mode instead of in XHTML. Any chance that the ikiwiki's .deb in debian backports will be updated any time soon?
+
+> Formerer does a good job keeping the backport up-to-date with whatever is in Debian testing. 
+> Which is the policy of what Backports should contain. So, I just need to stop releasing ikiwiki
+> for 2 weeks. :) --[[Joey]]
+
+>> And are there any chances you doing it... or rather not doing it?
+
+>>> Sure, I'm busily not doing it right now. Should reach testing in 3
+>>> days. I generally schedule things so a new ikiwiki reaches testing
+>>> every 2 weeks to month. Getting important new features and bugfixes out
+>>> can take priority though. --[[Joey]] 
+
+>>>> Great! Thanks.
+
+>>>> Still not available in the backports; did you break the silence on the wire and got back to work [[Joey]]? 
+
+>>>> I was blinded by my stupidity... thanks!
diff --git a/doc/forum/double_forward_slash___39____47____47____39___in_the_address_bar.mdwn b/doc/forum/double_forward_slash___39____47____47____39___in_the_address_bar.mdwn
new file mode 100644
index 000000000..b5fb2aa18
--- /dev/null
+++ b/doc/forum/double_forward_slash___39____47____47____39___in_the_address_bar.mdwn
@@ -0,0 +1,3 @@
+Why do all the pages are preceded with a double forward slash in the address bar... ie. http://example.org//ikiwiki/pagespec/ .. maybe someone knows?
+
+> Sorted, base url in the .setup file had the unnecessary '/' suffix.
diff --git a/doc/forum/formating:_how_to_align_text_to_the_right.mdwn b/doc/forum/formating:_how_to_align_text_to_the_right.mdwn
new file mode 100644
index 000000000..2b56bd70b
--- /dev/null
+++ b/doc/forum/formating:_how_to_align_text_to_the_right.mdwn
@@ -0,0 +1,15 @@
+as in title, how to align text to the right?
+
+> Add to your local.css a class that aligns text to the right:
+
+	.alignright { text-align: right; }
+
+> And then you just just use `<span class="alignright">` around
+> other html.
+> 
+> You can refine that, and allow right-aligning markdowned text
+> by using the [[ikiwiki/directive/template]]
+> directive, with a template that contains the html. The 
+> [[templates/note]] template does something similar. --[[Joey]]
+
+>> Thanks!
diff --git a/doc/forum/google_openid_broken__63__.mdwn b/doc/forum/google_openid_broken__63__.mdwn
index 68b44f2c1..96ba2d791 100644
--- a/doc/forum/google_openid_broken__63__.mdwn
+++ b/doc/forum/google_openid_broken__63__.mdwn
@@ -50,3 +50,30 @@ The openid is
 <https://www.google.com/accounts/o8/id?id=AItOawltlTwUCL_Fr1siQn94GV65-XwQH5XSku4>
 (what a mouthfull!), and I don't know who that is or how to use it since it
 points to a fairly useless xml document, rather than a web page. --[[Joey]]
+
+> That string is what's received via the discovery protocol. The user logging in with a Google account is not supposed to write that when logging in, but rather <https://www.google.com/accounts/o8/id>. The OpenID client library will accept that and redirect the user to a sign in page, which will return that string as the OpenID. It's not really usable as an identifier for edits and whatnots, but an alternative would be to use the attribute exchange extension to get the email address and display that. See <http://code.google.com/apis/accounts/docs/OpenID.html#Parameters>.
+
+> Yahoo's OpenID implementation works alike, but I haven't looked at it as much. It uses <https://me.yahoo.com/> to receive the endpoint.
+
+> I've added buttons that submit the two above URLs for logging in with a Google and Yahoo OpenID, respectively, to my locally changed OpenID login plugin.
+
+> Using the Google profile page as the OpenID is really orthogonal to the above. --[[kaol]]
+
+>> First, I don't accept that the openid google returns from their 
+>> generic signin url *has* to be so freaking ugly. For contrast, 
+>> look at the openid you log in as if you use the yahoo url.
+>> <https://me.yahoo.com/joeyhess#35f22>. Nice and clean, now
+>> munged by ikiwiki to "joeyhess [me.yahoo.com]".
+>> 
+>> Displaying email addresses is not really an option, because ikiwiki
+>> can't leak user email addresses like that. Displaying nicknames or
+>> usernames is, see [[todo/Separate_OpenIDs_and_usernames]].
+>>
+>> It would probably be good if the openid plugin could be configured with
+>> a list of generic openid urls, so it can add quick login buttons using
+>> those urls.
+>>
+>> The ugly google url will still be exposed here and there where
+>> a unique user id is needed. That can be avoided by not using the generic
+>> <https://www.google.com/accounts/o8/id>, but instead your own profile
+>> like <http://www.google.com/profiles/joeyhess>. --[[Joey]] 
diff --git a/doc/forum/how_do_I_revert_edits_in_the_web_mode__63__.mdwn b/doc/forum/how_do_I_revert_edits_in_the_web_mode__63__.mdwn
new file mode 100644
index 000000000..7686a7a08
--- /dev/null
+++ b/doc/forum/how_do_I_revert_edits_in_the_web_mode__63__.mdwn
@@ -0,0 +1,35 @@
+Puzzled a bit :-/
+
+> There is no explicit interface for reverting edits. Most of us use `git revert`. --[[Joey]]
+
+>> That's a blow; I was planning on appointing no techies to keep law and order on our pages :-/ Is there a plugin or at least a plan to add such a 'in demand' feature?
+
+>>> A lot of things complicate adding that feature to the web interface.
+>>>
+>>> First, ikiwiki happily uses whatever the VCS's best of breed web
+>>> history interface is. (ie, viewvcs, gitweb). To allow reverting
+>>> past the bottom of the RecentChanges page, it would need to have its 
+>>> own history browser. Not sure I want to go there.
+>>>
+>>> And the mechanics of handling reverting can quickly get complex. 
+>>> Web reverting should only allow users to revert things they can edit,
+>>> but reverting a whole commit in git might touch multiple files.
+>>> Some files may not be editable over the web at all. (The
+>>> [[tips/untrusted_git_push]] also has to deal with those issues.)
+>>> Finally, a revert can fail with a conflict. The revert could touch 
+>>> multiple files, and multiple ones could conflict. The conflict may
+>>> involve non-page files that can't be diffed. So an interface for
+>>> resolving such a conflict could be hard.
+>>> 
+>>> Probably web-based reverting would need to be limited to reverting 
+>>> single file changes, not whole commits, and not having very good
+>>> conflict handling. And maybe only being accessible for changes
+>>> still visible on RecentChanges. With those limitations, it's certianly
+>>> doable (as a plugin even), but given how excellent `git revert` is in
+>>> comparison, I have not had a real desire to do so. --[[Joey]]
+
+>>>> Web edits are single-file anyway, so I wouldn't expect web reverts
+>>>> to handle the multi-file case. OTOH, I've sometimes wished ikiwiki
+>>>> had its own history browser (somewhere down my todo list). --[[schmonz]]
+
+>>>> Yup, having a possibility to revert a single file would suffice.
diff --git a/doc/forum/how_to_add_post_titles_in_ikiwiki_blog__63__.mdwn b/doc/forum/how_to_add_post_titles_in_ikiwiki_blog__63__.mdwn
new file mode 100644
index 000000000..68eb06c4c
--- /dev/null
+++ b/doc/forum/how_to_add_post_titles_in_ikiwiki_blog__63__.mdwn
@@ -0,0 +1,28 @@
+Look at these two blogs:
+
+1) http://ciffer.net/~svend/blog/
+
+2) http://upsilon.cc/~zack/blog/
+
+Well, i set up successfully my blog (i am using inline function in a wiki page) but i have manually to insert blog pos titles and the result is that of blog #2.
+Instead i would like to have blog post titles automatically inserted like blog #1 (and they are links too! I want them that way).
+I looked in git repo of the two blogs but i couldn't find the answer.
+Any help would be really appreciated.
+
+Thanks!
+
+Raf
+
+> Either name the blog post files with the full title you want them to 
+> have, or use [[ikiwiki/directive/meta]] title to set the title of a blog post.
+> 
+>	\[[!meta title="this is my blog post"]]
+> 
+> Either way, the title will automatically be displayed, clickable, at the top.
+> (zack has hacked his templates not to do that). --[[Joey]] 
+
+>> Thanks for your answer.<br/>
+>> I looked in the [templates](http://git.upsilon.cc/cgi-bin/gitweb.cgi?p=zack-homepage.git;a=tree;f=templates;h=824100e62a06cee41b582ba84fcb9cdd982fe4be;hb=HEAD) folder of zack but couldn't see any hack of that kind.<br/>
+>> Anyway, I didn't hack my template...<br/>
+>> I will follow your suggestion of using \[[ikiwiki/directive/meta]] title to set titles.<br/>
+>> Thanks a lot. --Raf
diff --git a/doc/forum/how_to_load_an_external_page_and_still_have_it_under_ikiwiki_template.mdwn b/doc/forum/how_to_load_an_external_page_and_still_have_it_under_ikiwiki_template.mdwn
new file mode 100644
index 000000000..a747911a5
--- /dev/null
+++ b/doc/forum/how_to_load_an_external_page_and_still_have_it_under_ikiwiki_template.mdwn
@@ -0,0 +1,3 @@
+OK, probably title is bit confusing. Basically I'd like to be able to keep my left hand side menu, which is part of the template, and at the same time load let's say forum on the right hand side, which sits on a separate domain. Is it possible then to construct template that for some special links it runs as lets say in *frameset* mode?
+
+> I think I'll have to use [[ikiwiki/directive/pagetemplate]] and this <http://stackoverflow.com/questions/153152/resizing-an-iframe-based-on-content> solution
diff --git a/doc/forum/how_to_login_as_admin.mdwn b/doc/forum/how_to_login_as_admin.mdwn
new file mode 100644
index 000000000..807f82501
--- /dev/null
+++ b/doc/forum/how_to_login_as_admin.mdwn
@@ -0,0 +1,18 @@
+I even managed to set up ikiwiki so it works fine with git; but how on earth do
+I log in as an administrator? In the .setup file the admin user is set to
+'zimek' but when I go and register 'zimek' on the web it appears as normal user
+not the administrator. What am I missing?
+
+> That's really all there is to it. The [[automatic_setup|setup]] script
+> registers the admin user for you before the wiki goes live. If you didn't
+> use it, registering the right account name will get you the admin account.
+> 
+> The name is case sensative, perhaps you really spelled one of them `Zimek`?
+> 
+> Or maybe you're the admin, and don't know it? Everything looks the same for the admin,
+> except they can edit even locked pages, and can access the websetup interface from their
+> Preferences page, if you have that plugin enabled. --[[Joey]] 
+
+>> Maybe I'm indeed. I know that I've disabled all the plugins while installing ikiwiki. Checking it now ;-)
+
+>> Yup, I'm the God of my ikiwiki. (Thanks)
diff --git a/doc/forum/how_to_setup_ikiwiki_on_a_remote_host.mdwn b/doc/forum/how_to_setup_ikiwiki_on_a_remote_host.mdwn
new file mode 100644
index 000000000..1c0f8f561
--- /dev/null
+++ b/doc/forum/how_to_setup_ikiwiki_on_a_remote_host.mdwn
@@ -0,0 +1,35 @@
+Hi all!
+I really like ikiwiki and i tested it on my local machine but i have one question that i can't answer reading documentation (my fault of course)...
+I have an account and some space on a free hosting service.
+Now, i want to put my ikiwiki on this remote web space so that i can browse it from wherever i want.
+I have my source dir and my git dir on my local machine.
+How can i upload my ikiwiki on the remote host and manage it via git as i can do when i test it locally?
+Where is specified? Where can i find documentation about it?
+
+Thanks in advance!
+
+Pab
+
+> There are several ways to accomplish this, depending on what you really
+> want to do.
+> 
+> If your goal is to continue generating the site locally, but then
+> transfer it to the remote host for serving, you could use the 
+> [[plugins/rsync]] plugin.
+> 
+> If your goal is to install and run the ikiwiki software on the remote host,
+> then you would follow a similar path to the ones described in these tips:
+> [[tips/nearlyfreespeech]] [[tips/DreamHost]]. Or even [[install]] ikiwiki
+> from a regular package if you have that kind of access. Then you could
+> push changes from your local git to git on the remote host to update the
+> wiki. [[tips/Laptop_wiki_with_git]] explains one way to do that.
+> --[[Joey]] 
+
+Thanks a lot for your answer.
+rsync plugin would be perfect but... how would i manage blog post?
+I mean... is it possible to manage ikiwiki blog too with rsync plugin in the way you told me? --Pab
+
+> If you want to allow people to make comments on your blog, no, the rsync plugin will not help, since it will upload a completely static site where nobody can make comments.  Comments require a full IkiWiki setup with CGI enabled, so that people add content (comments) from the web. --[[KathrynAndersen]]
+
+Ok, i understand, thanks.
+Is there any hosting service that permits to have a full installation of iwkiwiki or i am forced to get a vps or to mantain a personal server for that? --Pab
diff --git a/doc/forum/ikiwiki_development_environment_tips.mdwn b/doc/forum/ikiwiki_development_environment_tips.mdwn
new file mode 100644
index 000000000..91ccc6d6e
--- /dev/null
+++ b/doc/forum/ikiwiki_development_environment_tips.mdwn
@@ -0,0 +1,44 @@
+I haven't settled on a comfortable/flexible/quick development environment for hacking on ikiwiki.  The VM I host my web pages on is not fast enough to use for RAD and ikiwiki. For developing plugins, it seems a bit heavy-weight to clone the entire ikiwiki repository. I haven't managed to get into a habit of running a cloned version of ikiwiki from it's own dir, rather than installing it (If that's even possible).  The ikiwiki site source (source ./doc) is quite large and not a great testbed for hacking (e.g. if you are working on a plugin you need a tailored test suite for that plugin).
+
+Does anyone have a comfortable setup or tips they would like to share? -- [[Jon]]
+
+> I've just been setting `libdir` in an existing wiki's setup file. When the plugin's in a decent state, I copy it over to a git checkout and commit. For the plugins I've been working on (auth and VCS), this has been just fine. Are you looking for something more? --[[schmonz]]
+
+>> I think this suffers from two problems. Firstly, unless you are tracking git
+>> master in your existing wiki, there's the possibility that your plugin will
+>> not work with a more modern version of ikiwiki (or that it would benefit
+>> from using a newly added utility subroutine or similar). 
+
+>>> Unlikely. I don't make changes to the plugin interface that break
+>>> existing plugins. (Might change non-exported `IkiWiki::` things
+>>> from time to time.) --[[Joey]] 
+
+>> Second, sometimes I
+>> find that even writing a plugin can involve making minor changes outside of
+>> the plugin code (bug fixes, or moving functionality about). So, I think
+>> having some kind of environment built around a git checkout is best.
+>> 
+>> However, this does not address the issue of the tedium writing/maintaining a
+>> setup file for testing things.
+>>
+>> I think I might personally benefit from a more consistent environment (I
+>> move from machine-to-machine frequently). -- [[Jon]]
+
+> If you set `libdir` to point to a checkout of ikiwiki's git repository,
+> it will override use of the installed version of ikiwiki, so ikiwiki will
+> immediatly use any changed or new `.pm` files (with the exception of
+> IkiWiki.pm), and you can use git to manage it all without an installation
+> step. If I am modifying IkiWiki.pm, I generally symlink it from
+> `/usr/share/perl5/IkiWiki.pm` to my git reporisitory. Granted, not ideal.
+> 
+> I often use my laptop's local version of my personal wiki for testing.
+> It has enough stuff that I can easily test most things, and if I need
+> a test page I just dump test cases on the sandbox. I can make
+> any changes necessary during testing and then `git reset --hard
+> origin/master` to avoid publishing them.
+> 
+> If the thing I'm testing involves templates, or underlays, 
+> I will instead use ikiwiki's `docwiki.setup` for testing, modifying it as
+> needed, since it is preconfigured to use the templates and underlays
+> from ikiwiki's source repository.
+> --[[Joey]]
diff --git a/doc/forum/link_autocompletion_in_vim.mdwn b/doc/forum/link_autocompletion_in_vim.mdwn
new file mode 100644
index 000000000..7d3ed8b02
--- /dev/null
+++ b/doc/forum/link_autocompletion_in_vim.mdwn
@@ -0,0 +1,17 @@
+I extended the functionality of the [ikiwiki-nav plugin](http://www.vim.org/scripts/script.php?script_id=2968)
+(see [[here|tips/follow_wikilinks_from_inside_vim]]) to allow completion of
+wikilinks from inside vim, through the omnicompletion mechanism.
+
+It still has some bugs, but is usable, and will not destroy your data. It can
+only complete links whose definition (text) is on a single line, and still can't
+handle "named links" (`\[\[text|link\]\]`).
+
+I'd love to hear suggestions for improvement for it, and bug reports ;) For
+example, regarding how are sorted and presented the available completions
+(dates, alphabetically, etc).
+
+You can find a tarball for it
+[here](http://devnull.li/~jerojasro/ikiwiki-nav-dev.tar.gz). To install it,
+extract the tarball contents in your `.vim` directory.
+
+--[[jerojasro]]
diff --git a/doc/forum/link_to_an_image_inside_the_wiki_without_inlining_it.mdwn b/doc/forum/link_to_an_image_inside_the_wiki_without_inlining_it.mdwn
new file mode 100644
index 000000000..e92cc1b1c
--- /dev/null
+++ b/doc/forum/link_to_an_image_inside_the_wiki_without_inlining_it.mdwn
@@ -0,0 +1,69 @@
+how can I create a link to an image which is part of the wiki, without having it inserted in my page?
+
+I tought this:
+
+    \[[look at this|img/lolcat.png]] 
+
+would work, but it doesn't.
+
+Any hints? --[[jerojasro]]
+
+> Well, currently the syntax above will display the image
+> inline with the specified link text used as an alt attribute. Although
+> that does not seem to be documented anywhere.
+> 
+> A few places that use that (found with `git grep '\[\[' | egrep 'png|gif|jpeg|jpg' |grep \|`):
+> 
+> * [[logo]] uses it to provide useful alt texts for the logos. (This
+>   could easily be changed to use [[ikiwiki/directive/img]] though.)
+> * The `change.tmpl` template uses it to display 
+>   the [[diff|wikiicons/diff.png]] with a very useful "diff" alt text.
+>   Using [[ikiwiki/directive/img]] here would mean that the
+>   [[plugins/recentchanges]] plugin would depend upon the img
+>   plugin.
+> 
+> I do like your suggestion, it makes more sense than the current behavior.
+> I'm not sure the transition pain to get from here to there is worth it,
+> though.
+> 
+> More broadly, if I were writing ikiwiki now, I might choose to leave out the
+> auto-inlining of images altogether. In practice, it has added a certian level
+> of complexity to ikiwiki, with numerous plugins needing to specify
+> `noimageinline` to avoid accidentially inlining an image. And there has not
+> been a lot of payoff from having the auto-inlining feature implicitly
+> available most places. And the img directive allows much needed control over
+> display, so it would be better for users to not have to worry about its
+> lesser cousin. But the transition from here to *there* would be another order
+> of pain.
+> 
+> Anyway, the cheap and simple answer to your question is to use html
+> or markdown instead of a [[ikiwiki/wikilink]]. Ie, 
+> `[look at this](img/lolcat.jpg)`. --[[Joey]]
+
+> > thanks a lot, that's a quite straightforward solution. I actually wrote a
+> > broken plugin to do that, and now I can ditch it --[[jerojasro]]
+
+>>> The plugin approach is not a bad idea if you want either the ability
+>>> to:
+>>>
+>>> * Have things that are wikilink-aware (like [[plugins/brokenlinks]]
+>>>   treat your link to the image as a wikilink. 
+>>> * Use standard wikilink path stuff (and not have to worry about 
+>>>   a relative html link breaking if the page it's on is inlined, for
+>>>   example).
+>>>
+>>> I can help you bang that plugin into shape if need be. --[[Joey]] 
+
+>>>> both my plugin and your suggestion yield broken html links when inlining the page (although probably that's what is expected from your suggestion (`[]()`))
+>>>>
+>>>> I thought using the `bestlink` function would take care of that, but alas, it doesn't.
+>>>> Get the "plugin" [here](http://devnull.li/~jerojasro/files/linktoimgonly.pm), see the broken 
+>>>> links generated [here](http://devnull.li/~jerojasro/blog/posts/job_offers/) and the source 
+>>>> file for that page [here](http://git.devnull.li/cgi-bin/gitweb.cgi?p=blog-jerojasro.git;a=blob;f=posts/job_offers.mdwn;hb=HEAD) --[[jerojasro]]
+
+>>>>> Use this --[[Joey]] 
+
+	return htmllink($params{page}, $params{destpage}, $params{"img"},
+	    linktext => $params{text},
+	    noimageinline => 1);
+
diff --git a/doc/forum/navigation_of_wiki_pages_on_local_filesystem_with_vim.mdwn b/doc/forum/navigation_of_wiki_pages_on_local_filesystem_with_vim.mdwn
new file mode 100644
index 000000000..7bc032949
--- /dev/null
+++ b/doc/forum/navigation_of_wiki_pages_on_local_filesystem_with_vim.mdwn
@@ -0,0 +1,127 @@
+**UPDATE** I have created a [[page|tips/follow_wikilinks_from_inside_vim]] in
+the tips section about the plugin, how to get it, install it and use it. Check
+that out. --[[jerojasro]]
+
+I wrote a vim function to help me navigate the wiki when I'm editing it. It extends the 'gf' (goto file) functionality. Once installed, you place the cursor on a wiki page name and press 'gf' (without the quotes); if the file exists, it gets loaded.
+
+This function takes into account the ikiwiki linking rules when deciding which file to go to.
+
+> 'gf' gets in the way when there are directories with the same name of a wiki page. The 
+> function below doesn't implement the linking rules properly (test the link (ignoring case),
+> if there is no match ascend the dir. hierarchy and start over, until we reach the root of
+> the wiki). I'm rewriting it to follow these rules properly
+> 
+> I think the page for [[LinkingRules|ikiwiki/subpage/linkingrules]] should say that ikiwiki **ascends**
+> the dir. hierarchy when looking for a wikilink, not that it **descends** it. Am I correct? --[[jerojasro]]
+
+>> Conventionally, the root directory is considered to be lower than other
+>> directories, so I think the current wording is correct. --[[Joey]]
+
+let me know what you think
+
+>         " NOTE: the root of the wiki is considered the first directory that contains a
+>         " .ikiwiki folder, except $HOME/.ikiwiki (the usual ikiwiki libdir)
+> 
+> That's not going to work in all situations; for example, with an ikiwiki which uses git as the backend, the normal setup is that one has
+> 
+> * a bare git repository
+> * a git repository which ikiwiki builds the wiki from (which has a .ikiwiki directory in it)
+> * an *additional* git repository cloned from the bare repository, which is used for making changes from the command-line rather than the web.  It is this repository in which one would be editing files with vim, and *this* repository does not have a .ikiwiki directory in it.  It does have a .git directory in the root, however, so I suppose you could use that as a method of detection of a root directory, but of course that would only work for git repositories.
+> 
+> -- [[KathrynAndersen]]
+> 
+>> You are completely right; all of my wikis are compiled both locally and
+>> remotely, and so the local repo also has a `.ikiwiki` folder. And that's not the
+>> "usual" setup.
+>> 
+>> checking for a `.git` dir would not work when the wiki's source files aren't
+>> located at the root of the repo.
+>> 
+>> So, besides of doing a `touch .ikiwiki` at the root of the wiki in your local
+>> repo, do you see any alternative?
+>> 
+>> -- [[jerojasro]]
+
+well. I've rewritten the whole thing, to take into account:
+  
+  * file matching ignoring case (MyPage matches mypage.mdwn)
+  * checking all the way down (up) to the root of the wiki (if there is a link `\[[foo]]` on `a/b/page`),
+  try `a/b/page/foo`, then `a/b/foo`, and so on, up to `foo`
+  * the alternate name for a page: when looking for the file for `\[[foo]]`, try both `foo.mdwn` and `foo/index.mdwn`
+
+you can find the file [here](http://git.devnull.li/cgi-bin/gitweb.cgi?p=vim-jerojasro.git;a=blob;f=.vim/ftplugin/ikiwiki_nav.vim;hb=HEAD). To use it, place it in `$HOME/.vim/ftplugin`. After that, hitting `<CR>` (Enter) in normal mode over a wikilink will take you to that page, if it exists.
+
+the plugin has, as of now, two problems:
+ 
+  * doesn't work with wikilinks that take more than one line (though this isn't really that bad)
+  * it assumes that the root of the wiki is the first directory down the filesystem hierarchy that 
+  has a `.ikiwiki` folder on it. If your copy of the wiki doesn't have it, you must create it for 
+  the plugin to work
+
+-- [[jerojasro]]
+
+> Interesting. I was at one point looking at "potwiki.vim", which implements a local wiki and follows CamelCase links, creating new files where necessary etc., to see if it could be adapted for ikiwiki (See [[tips/vim syntax highlighting/discussion]]). I didn't get anywhere. -- [[Jon]]
+
+>> when I wrote the plugin I also considered the possibility of creating files (and their dirs, if necessary) 
+>> from new wikilinks; the changes needed to get that working are fairly small -- [[jerojasro]]
+
+> Seems about ready for me to think about pulling it into ikiwiki
+> alongside [[tips/vim_syntax_highlighting/ikiwiki.vim]]. If you'll
+> please slap a license on it. :) --[[Joey]] 
+>
+>> GPL version 2 or later (if that doesn't cause any problems here). I'll add it
+>> to the file --[[jerojasro]]
+>>
+>>> I see you've put the plugin on vim.org. Do you think it makes sense to
+>>> also include a copy in ikiwiki? --[[Joey]] 
+>>> 
+>>>> mmm, no. There would be two copies of it, and the git repo. I'd rather have 
+>>>> a unique place for the "official" version (vim.org), and another for the dev 
+>>>> version (its git repo).
+>>>> 
+>>>> actually, I would also suggest to upload the [[`ikiwiki.vim`|tips/vim_syntax_highlighting]] file to vim.org --[[jerojasro]]
+>>>>>
+>>>>> If you have any interest in maintaining the syntax highlighting
+>>>>> plugin and putting it there, I'd be fine with that. I think it needs
+>>>>> some slight work to catch up with changes to ikiwiki's directives
+>>>>> (!-prefixed now), and wikilinks (able to have spaces now). --[[Joey]]
+>>>>> 
+>>>>>> I don't really know too much about syntax definitions in vim. But I'll give it a stab. I know it fails when there are 2 \[[my text|link]] wikilinks in the same page.
+>>>>>> I'm not promising anything, though ;) --[[jerojasro]]
+>
+> Also, I have a possible other approach for finding ikiwiki's root. One
+> could consider that any subdirectory of an ikiwiki wiki is itself
+> a standalone wiki, though probably one missing a toplevel index page.
+> The relative wikilinks work such that this assumption makes sense;
+> you can build any subdirectory with ikiwiki and probably get something
+> reasonable with links that work, etc.
+> 
+> So, if that's the case, then one could say that the directory that the
+> user considers to be the toplevel of their wiki is really also a subwiki,
+> enclosed in a succession of parents that go all the way down to the root
+> directory (or alternatively, to the user's home directory). I think that
+> logically makes some sense.
+> 
+> And if that's the case, you can resolve an absolute link by looking for
+> the page closest to the root that matches the link.
+>
+>> I like your idea; it doesn't alter the matching of the relative links, and
+>> should work fine with absolute links too. I'll implement it, though I see
+>> some potential (but small) issues with it --[[jerojasro]]
+> 
+> It may even make sense to change ikiwiki's own handling of "absolute"
+> links to work that way. But even without changing ikiwiki, I think it
+> would be a reasonable thing for vim to do. It would only fail in two
+> unusual circumstances:
+> 
+> 1. There is a file further down, outside what the user considers
+>    the wiki, that matches. Say a `$HOME/index.mdwn`
+> 2. An absolute link is broken in that the page linked to does
+>    not exist in the root of the wiki. But it does exist in a subdir, 
+>    and vim would go to that file.
+> 
+> --[[Joey]] 
+>
+>> your approach will add more noise when the plugin grows the page-creation
+>> feature, since there will be no real root to limit the possible locations for
+>> the new page. But it is far better than demanding for a `.ikiwiki` dir --[[jerojasro]]
diff --git a/doc/forum/speeding_up_ikiwiki.mdwn b/doc/forum/speeding_up_ikiwiki.mdwn
index 2c2ac240e..799186cf8 100644
--- a/doc/forum/speeding_up_ikiwiki.mdwn
+++ b/doc/forum/speeding_up_ikiwiki.mdwn
@@ -56,7 +56,7 @@ number is still too large to really visualize: the graphviz PNG and PDF output
 engines segfault for me, the PS one works but I can't get any PS software to
 render it without exploding.
 
-Now, the relations in the links hash are not the same thing as IkiWiki's notion of dependencies. Can anyone point me at  that data structure / where I might be able to add some debugging foo to generate a graph of it?
+Now, the relations in the links hash are not the same thing as Ikiwiki's notion of dependencies. Can anyone point me at  that data structure / where I might be able to add some debugging foo to generate a graph of it?
 
 Once I've figured out that I might be able to optimize some pagespecs. I
 understand pagespecs are essentially translated into sequential perl code. I
diff --git a/doc/forum/suppressing_output_of_pages_included_only_for_their_side_effects.mdwn b/doc/forum/suppressing_output_of_pages_included_only_for_their_side_effects.mdwn
new file mode 100644
index 000000000..99784cdd2
--- /dev/null
+++ b/doc/forum/suppressing_output_of_pages_included_only_for_their_side_effects.mdwn
@@ -0,0 +1,16 @@
+In particular, it's kind of annoying that using the sidebar plugin results in the creation of a free-standing sidebar.html (which in the simplest case of course includes a copy of *its own content* as a sidebar).  It would be nice if there were a way to tell Ikiwiki to treat a file like sidebar.mdwn as "inline only": allow its content to be inlined but not to render it separately nor allow linking to it.
+
+In reading through the code and associated docs, it appears that the ideal method is for the file to be removed from the $changed array by plugin's "needsbuild" hook.  Either the sidebar plugin could define such a hook, or perhaps a more general solution is the creation of a meta variable or config file regexp that would handle it according to the user's wishes.
+
+I'm about ready to code up such a change but want to find out if I'm thinking along the right lines.  --[[blipvert]]
+
+> Internal pages should be able to be used for this, as they are used for
+> comments. So you'd have
+> `sidebar._mdwn`. However, mwdn would need to be changed to register a
+> htmlize hook for the `_mdwn` extension for that to really work.
+> 
+> But, if there's no rendered sidebar page, how can users easily edit the page
+> in the web interface? In the specific case of the sidebar, It seems
+> better to have the page display something different when built standalone
+> than when built as the sidebar.
+> --[[Joey]]
diff --git a/doc/forum/tag_plugin:_rebuilding_autocreated_pages.mdwn b/doc/forum/tag_plugin:_rebuilding_autocreated_pages.mdwn
new file mode 100644
index 000000000..114837031
--- /dev/null
+++ b/doc/forum/tag_plugin:_rebuilding_autocreated_pages.mdwn
@@ -0,0 +1,11 @@
+I have a bunch of tag pages autogenerated by the tag plugin. As part of a redesign for my wiki, I have changed the `autotag.tmpl` template, but IkiWiki refuses to rebuild existing tag pages using the updated template. I understand that existing tag pages are not rebuilt because they have been marked as "created" in `.ikiwiki/indexdb`. Is there a way to purge all tag pages from `indexdb`? --dkobozev
+
+> Well, you can delete the indexdb and rebuild, and that will do it.
+> The tag plugin is careful not to replace existing pages or even recreate
+> tag pages if you delete them, which does cause a problem if you need to
+> update them. --[[Joey]]
+
+>> Thanks. I thought about deleting `indexdb`, but hesitated to do that. According to [[tips/inside dot ikiwiki]], `indexdb` stores "all persistent state about pages". I didn't know if it's harmless to lose all persistent state. --dkobozev
+
+>>> The persistant state is best thought of as a cache,
+>>> so it's safe to delete it. --[[Joey]] 
diff --git a/doc/forum/utf8_warnings_for___34____92__xAB__34__.mdwn b/doc/forum/utf8_warnings_for___34____92__xAB__34__.mdwn
new file mode 100644
index 000000000..72f2d38e0
--- /dev/null
+++ b/doc/forum/utf8_warnings_for___34____92__xAB__34__.mdwn
@@ -0,0 +1,47 @@
+# getting Warnings about UTF8-Chars.
+
+I'm  getting multiple warnings:
+
+      utf8 "\xAB" does not map to Unicode at /usr/share/perl5/IkiWiki.pm line 774, <$in> chunk 1.
+
+
+I'm assuming this is once per File, but even in verbose mode, it doesn't tell me which file is a problem.
+It first reads all the files, and afterwards when parsing/compiling them, it outputs the warning, so I can't
+deduce the offending files.
+
+Is there a way to have ikiwiki output the position, where it encounters the character?
+
+Probably all this has to do with locale-settings, and usage of mixed locales in a distributed setup ...
+I'd rather cleanup some of the file(name)s  of unexpected characters. --[[jwalzer]]
+
+--------
+
+**Update** : So I took the chance to insert debug into ikiwiki.pm:
+
+     root@novalis:/usr/share/perl5# diff -p /tmp/IkiWiki.orig.pm IkiWiki.pm 
+     *** /tmp/IkiWiki.orig.pm        Sun Feb 14 15:16:08 2010
+     --- IkiWiki.pm  Sun Feb 14 15:16:28 2010
+     *************** sub readfile ($;$$) {
+     *** 768,773 ****
+     --- 768,774 ----
+             }
+       
+             local $/=undef;
+     +       debug("opening File: $file:");
+             open (my $in, "<", $file) || error("failed to read $file: $!");
+             binmode($in) if ($binary);
+             return \*$in if $wantfd;
+
+
+But what I see now is not quite helpful, as it seems, STDERR and DEBUG are asyncronous, so they mix up in a way, that I can't really see, whats the problem ...  Maybe I'm better off for troubleshooting, to insert an printf to strerr to have it in the same stream.. --[[jwalzer]]
+
+
+----
+
+**Update:** The "print STDERR $file;"-Trick did it .. I was able to find a mdwn-file, that (was generated by a script of me) had \0xAB in it.
+
+Nevertheless I still wonder if this should be a problem. This character happend to be in an *\[\[meta title='$CHAR'\]\]-tag* and an *\[$CHAR\]http://foo)-Link*
+
+Should this throw an warning? Maybe this warning could be catched an reported inclusively the containing filename? maybe even with an override, if one knows that it is correct that way? --[[jwalzer]]
+
+[[!tag solved]]
diff --git a/doc/forum/what_is_the_easiest_way_to_implement_order:_disallow_all__44___allow_chosen__95__few_page_editing_policy__63__.mdwn b/doc/forum/what_is_the_easiest_way_to_implement_order:_disallow_all__44___allow_chosen__95__few_page_editing_policy__63__.mdwn
new file mode 100644
index 000000000..fbc5c58e2
--- /dev/null
+++ b/doc/forum/what_is_the_easiest_way_to_implement_order:_disallow_all__44___allow_chosen__95__few_page_editing_policy__63__.mdwn
@@ -0,0 +1,3 @@
+As in title, I'd like to allow editing only some pages on my wiki. Rest by default is not editable by users except admin. Thanks
+
+> See [[plugins/lockedit]]. --[[schmonz]]
diff --git a/doc/forum/where_are_the_tags.mdwn b/doc/forum/where_are_the_tags.mdwn
new file mode 100644
index 000000000..ecb49fe43
--- /dev/null
+++ b/doc/forum/where_are_the_tags.mdwn
@@ -0,0 +1,9 @@
+Where is the tag cloud/tag listing of all the tags used in this wiki? I know we
+have tags enabled. --[[jerojasro]]
+
+> This wiki does not use one global toplevel set of tags (`tagbase` is not
+> set).
+> 
+> There are tags used for the [[plugins]], and a tag cloud of those
+> there. [[wishlist]] and [[patch]] are tags too, but I don't see the point
+> of a tag cloud for such tags. --[[Joey]]
diff --git a/doc/forum/wiki_clones_on_dynamic_IPs.mdwn b/doc/forum/wiki_clones_on_dynamic_IPs.mdwn
new file mode 100644
index 000000000..f69f6501e
--- /dev/null
+++ b/doc/forum/wiki_clones_on_dynamic_IPs.mdwn
@@ -0,0 +1,10 @@
+OK, this is not really a ikiwiki problem... but ikiwiki makes wiki clones
+really easy to setup, and this is related to having a website cloned at
+different places and pulling from the servers which are online.
+
+My setup is like this: I have a server at home and another at my dorm
+which will serve as a wiki clone. Each of them has a dynamic IP with DynDNS
+set up. Now the problem lies in linking my domain to these two DynDNS addresses.
+Multiple CNAMEs are not supported, and I don't know if there's any utility
+which can update the A records on the DNS to point directly point to the
+two separate IPs.
diff --git a/doc/forum/wiki_name_in_page_titles.mdwn b/doc/forum/wiki_name_in_page_titles.mdwn
index 01ff8d817..4e9e51835 100644
--- a/doc/forum/wiki_name_in_page_titles.mdwn
+++ b/doc/forum/wiki_name_in_page_titles.mdwn
@@ -23,4 +23,10 @@ that provides a `IS_HOMEPAGE` template variable? --[[JasonBlevins]]
 >> few other small plugins brewing so I'll try to put up some contrib
 >> pages for them soon. --[[JasonBlevins]]
 
-[path]: http://code.jblevins.org/ikiwiki/plugins.git/plain/path.pm
+[path]: http://jblevins.org/git/ikiwiki/plugins.git/plain/path.pm
+
+> I used the following trick in some page.tmpl:
+>
+>     <title><TMPL_VAR WIKINAME><TMPL_IF NAME="PARENTLINKS">: <TMPL_VAR TITLE></TMPL_IF></title>
+>
+> --[[JeanPrivat]]
diff --git a/doc/forum/wishlist-discussion:_Editformular_showing_existing_tags.mdwn b/doc/forum/wishlist-discussion:_Editformular_showing_existing_tags.mdwn
new file mode 100644
index 000000000..49c55e20e
--- /dev/null
+++ b/doc/forum/wishlist-discussion:_Editformular_showing_existing_tags.mdwn
@@ -0,0 +1,15 @@
+# How about:
+
+having a list of all existing tags in the Edit-Formular as a selectionbox?
+
+Assume I have tagbase=/tags/ and for every tag I have given to articles an existing page there.
+
+Would it be possible to list all these tags together with the Formular, as selectionbox.
+Maybe even with parsing of the content and preselecting the tags, that are given in the article and vice-versa when selecting the fields then also generating the \[\[\!tag\]\]-sourcecode ?
+
+this would need a bit JS-work and somehow on compiletime we need to put the list of tags somewhere, where the cgi could read them from.
+This way, even a pagespec would suffice to determine the usable list of tags and not only the tagbase-variable.
+
+> I think this would be very hard to achieve with the current tag plugin, due to the nature of its implementation.
+> 
+> I've had a "tag2" plugin on the go for a while which supports this. It's in a very rough stage but I'll try to find it and upload it somewhere. -- [[Jon]]