22 files changed, 469 insertions, 52 deletions
diff --git a/doc/bugs/cannot_reliably_use_meta_in_template.mdwn b/doc/bugs/cannot_reliably_use_meta_in_template.mdwn
new file mode 100644
index 000000000..046f40a7e
--- /dev/null
+++ b/doc/bugs/cannot_reliably_use_meta_in_template.mdwn
@@ -0,0 +1,14 @@
+meta title cannot reliably be put inside a template used by the
+[[plugins/template]] plugin. Since meta title info is gathered in the scan
+pass, which does not look at the template a page includes, it will not be
+seen then, and so other pages that use the page title probably won't use
+it. (Barring luck with build order.)
+
+There is a simple fix for this, just add `scan => 1` when registering the
+preprocess hook for the template plugin.
+
+However, the overhead of this has to be considered. It means that, on every
+scan pass, every page containing a template will cause the template to be
+loaded and filled out. This can be some serious additional overhead.
+
+--[[Joey]] 
diff --git a/doc/contact.mdwn b/doc/contact.mdwn
index 37fb59071..486a4d186 100644
--- a/doc/contact.mdwn
+++ b/doc/contact.mdwn
@@ -7,4 +7,5 @@ developers monitor [[RecentChanges]] closely, via the webpage, email,
 [CIA](http://cia.navi.cx), and IRC, and respond in a timely fashion.
 
 You could also drop by the IRC channel `#ikiwiki` on
-[OFTC](http://www.oftc.net/) (`irc.oftc.net`).
+[OFTC](http://www.oftc.net/) (`irc.oftc.net`), or use the
+[identi.ca ikiwiki group](http://identi.ca/group/ikiwiki).
diff --git a/doc/forum/chinese_character_problem.mdwn b/doc/forum/chinese_character_problem.mdwn
new file mode 100644
index 000000000..c203ec4ec
--- /dev/null
+++ b/doc/forum/chinese_character_problem.mdwn
@@ -0,0 +1,21 @@
+just finished setting up ikiwiki..
+
+I can type chinese, save and display it correctly in ikiwiki for the first time. However, when i try to edit the page again, the chinese character in the form is unrecognizable. you can see it here <http://ikiwiki.perlchina.org/>
+
+I am using the latest ikiwiki(manually installed as non-root user) and CGI::FormBuilder(3.0501) on Debian 4.0
+
+这个没问题 it is not a problem on ikiwiki website though.
+
+Thanks.
+
+
+> Is your system perhaps not configured with a utf-8 default locale? Or ikiwiki not configured to use it?
+> Make sure that some utf-8 locale is enabled (in /etc/locale.gen on Debian for example) and try setting `locale` in your > ikiwiki setup file. --[[Joey]]
+
+I have installed locales-all and locale -a shows that zh_CN.UTF-8 is installed(there is no /etc/local.gen file though). then I enabled this line "locale => 'zh_CN.UTF-8'" in my wiki setup and -setup again. but that generated lots error messages "Missing constant domain at (eval 30) line 3"
+
+sorry being a n00b on this thing  what else can I do?
+
+> See [[bugs/Missing_constant_domain_at_IkiWiki.pm_line_842]].
+> Looks like you need to upgrade to a newer version of 
+> [[cpan Locale::gettext]] --[[Joey]] 
diff --git a/doc/ikiwiki/directive/meta.mdwn b/doc/ikiwiki/directive/meta.mdwn
index 74db31943..f29a118bf 100644
--- a/doc/ikiwiki/directive/meta.mdwn
+++ b/doc/ikiwiki/directive/meta.mdwn
@@ -139,6 +139,15 @@ Supported fields:
   pages unchanged and avoid_flooding_aggregators
   (see [[!iki tips/howto_avoid_flooding_aggregators]]).
 
+* updated
+
+  Specifies a fake modification time for a page, to be output into RSS and
+  Atom feeds. This is useful to avoid flooding aggregators that sort by
+  modification time, like Planet: for instance, when editing an old blog post
+  to add tags, you could set `updated` to be one second later than the original
+  value. The date/time can be given in any format that
+  [[!cpan TimeDate]] can understand, just like the `date` field.
+
 If the field is not one of the above predefined fields, the metadata will be
 written to the generated html page as a &lt;meta&gt; header. However, this
 won't be allowed if the [[!iki plugins/htmlscrubber desc=htmlscrubber]] plugin is enabled,
diff --git a/doc/ikiwiki/directive/pagestats/discussion.mdwn b/doc/ikiwiki/directive/pagestats/discussion.mdwn
new file mode 100644
index 000000000..3c9dc7104
--- /dev/null
+++ b/doc/ikiwiki/directive/pagestats/discussion.mdwn
@@ -0,0 +1,10 @@
+I am trying to create a tag cloud using:  
+           
+     \[[!pagestats  pages="tags/*"]]
+
+Nothing shows up when I first used this directive. I found that I had to create a page for the tag for it to show up in pagestats.
+I would rather not find and create a page for every tag I have created or will create. Is there an easier way to create a list of tags?
+
+Thanks
+
+----
diff --git a/doc/ikiwiki/directive/testpagespec/discussion.mdwn b/doc/ikiwiki/directive/testpagespec/discussion.mdwn
new file mode 100644
index 000000000..66c9a9ca9
--- /dev/null
+++ b/doc/ikiwiki/directive/testpagespec/discussion.mdwn
@@ -0,0 +1,6 @@
+How does one test a user identity?  I tried "pagename and user(username) for the match, and had a "no user specified" error.
+
+> You can't test them with this directive, because such pagespecs test to
+> see if logged in user, who is performing some action, matches. When the
+> page with the directive is built, the concept of a user being logged in
+> doesn't really apply. --[[Joey]] 
diff --git a/doc/ikiwiki/pagespec/discussion.mdwn b/doc/ikiwiki/pagespec/discussion.mdwn
index 0733c90c8..4eed3722c 100644
--- a/doc/ikiwiki/pagespec/discussion.mdwn
+++ b/doc/ikiwiki/pagespec/discussion.mdwn
@@ -65,3 +65,30 @@ How can I fix this?  --[[sabr]]
 
 > I don't see why that wouldn't work. Can I download the source to your
 > wiki from somewhere to investigate? --[[Joey]]
+
+----
+
+Should negation work with user(), with locked_pages in setup?  I
+experimented with setting locked_pages => 'user(someuser)' and was able to
+edit as a different user.  However, setting locked_pages =>
+'!user(someuser)' doesn't seem to allow edits for only 'someuser' - it
+locks out all users.
+
+> Negation works with anything in any PageSpec. I tested the case you
+> describe, and a negated pagespec worked for me; all users except the
+> listed user (and except wiki admins of course) were locked out.
+> --[[Joey]] 
+
+>> It must be a local problem, then, cause I've tried it with two separate 
+>> machines.  Both are running the most recent release of ikiwiki in 
+>> pkgsrc - 2.66.  Perhaps an update to a newer version would solve the issue.
+
+----
+
+Is there a way to refer to all subpages of the current page, if  the name of the 
+current page is not known (i.e. the pagespec is used in a template)? The ./ syntax
+does not seem suitable for this, as
+
+> \[[!map pages="./*"]]
+
+also lists the current page and all its siblings.
diff --git a/doc/ikiwikiusers.mdwn b/doc/ikiwikiusers.mdwn
index 2a51dfd9d..989a425c6 100644
--- a/doc/ikiwikiusers.mdwn
+++ b/doc/ikiwikiusers.mdwn
@@ -105,6 +105,8 @@ Personal sites and blogs
 * [[xma]] is using ikiwiki (<http://maillard.mobi/~xma/>)
 * [[JanWalzer|jwalzer]]'s [homepage](http://wa.lzer.net/) -- Work in Progress
 * [[Adam_Trickett|ajt]]'s home intranet/sanbox system ([Internet site & blog](http://www.iredale.net/) -- not ikiwiki yet)
+* [[Simon_McVittie|smcv]]'s [website](http://www.pseudorandom.co.uk/) and
+  [blog](http://smcv.pseudorandom.co.uk/)
 
 Schools
 =======
diff --git a/doc/install/discussion.mdwn b/doc/install/discussion.mdwn
index b5757070f..c1129a435 100644
--- a/doc/install/discussion.mdwn
+++ b/doc/install/discussion.mdwn
@@ -178,3 +178,53 @@ I've tried a couple of times and my cpan has never recognised Bundle::IkiWiki. I
 > Can you show how it fails to find the bundle? --[[Joey]]
 
 >> I was not. Next time I build I will have to try that (I'll need to tweak it as I already override PERL5LIB; also I need to specify http proxies). Thanks for your help! -- [[users/Jon]]
+
+---
+
+##Further problems with Bundle::IkiWiki
+I'm also having trouble with finding Bundle::IkiWiki.  I've tried it with the environment settings and without them, and also using the interactive 
+form of the cpan command.  I've also gone to cpan.org and searched -- eg
+
+    http://search.cpan.org/search?query=ikiwiki&mode=all
+
+and no Bundle for IkiWiki comes up at all.
+
+The error I get from the various cpan attempts is basically always the same:
+
+    Warning: Cannot install Bundle::IkiWiki, don't know what it is.
+    Try the command
+
+        i /Bundle::IkiWiki/
+
+    to find objects with matching identifiers.
+
+When I try that command, BTW, it basically seems to find the same stuff I get when searching on the cpan web site.
+
+This happens both on Ubuntu 8.04 and CentOS 5.1
+
+Any help would be greatly appreciated... --kent
+
+> Bundle::IkiWiki is included in ikiwiki itself, so of course cpan.org
+> does not know about it.
+> 
+> If you can show me exactly what command you ran (the tested, working
+> commands on the parent page?) and how it failed, I can try to debug
+> your problem.
+
+Just today I noticed the "Bundle" subdirectory.  What a moron I am! :-)  Also, I misunderstood the PERL5LIB=`pwd` part -- 
+I glibly thought it indicated the sink for the installation of the modules, rather than the source, and I was running 
+the cpan command from another window in a different directory, and just spiraled down into error...
+
+> The real question in my mind is why you'd want to do this at all when
+> using Ubuntu, which incldues packages of ikiwiki and all its
+> dependencies. --[[Joey]]
+
+For ubuntu 8.04: 
+
+    $ ikiwiki --version
+    ikiwiki version 2.32.3ubuntu2.1
+    $
+
+I was just trying to get the latest version.
+
+In any case, thanks for the help, and thanks for the superb software.  I really like it a lot.
diff --git a/doc/news/code_swarm.mdwn b/doc/news/code_swarm.mdwn
index bdc373432..09b68523e 100644
--- a/doc/news/code_swarm.mdwn
+++ b/doc/news/code_swarm.mdwn
@@ -1,7 +1,7 @@
 I've produced a [code_swarm](http://vis.cs.ucdavis.edu/~ogawa/codeswarm/)
 visualization of the first 2+ years of ikiwiki's commit history. 
 
-[[!img screenshot.png size="480x360"]]
+[[!img screenshot.png size="480x360" alt="screenshot"]]
 
 * [15 mb avi](http://kitenet.net/~joey/screencasts/ikiwiki_swarm.avi)
 * [stream on vimeo](http://vimeo.com/1324348)
diff --git a/doc/plugins/blogspam.mdwn b/doc/plugins/blogspam.mdwn
index a090f9c60..1d152faac 100644
--- a/doc/plugins/blogspam.mdwn
+++ b/doc/plugins/blogspam.mdwn
@@ -3,8 +3,9 @@
 
 This plugin adds antispam support to ikiwiki, using the
 [blogspam.net](http://blogspam.net/) API. Both page edits and
-[[comment|comments]] postings can be checked for spam. Currently,
-detected spam is not saved for human review, it is just rejected.
+[[comment|comments]] postings can be checked for spam. Page edits that
+appear to contain spam will be rejected; comments that look spammy will be
+stored in a queue for moderation by an admin.
 
 The plugin requires the [[!cpan RPC::XML]] perl module.
 
diff --git a/doc/plugins/comments.mdwn b/doc/plugins/comments.mdwn
index 72b11af64..c13a6daa6 100644
--- a/doc/plugins/comments.mdwn
+++ b/doc/plugins/comments.mdwn
@@ -41,3 +41,12 @@ There are some global options for the setup file:
   specify a name for themselves, and the \[[!meta author]] and
   \[[!meta authorurl]] directives will not be overridden by the comments
   plugin
+
+## comment moderation
+
+If you enable the [[blogspam]] plugin, comments that appear spammy will be
+held for moderation. Wiki admins can access the comment moderation queue
+via a button on their Preferences page.
+
+The comments are stored in `.ikiwiki/comments_pending/`, and can be
+deleted, or moved into the wiki's srcdir to be posted.
diff --git a/doc/plugins/contrib/po.mdwn b/doc/plugins/contrib/po.mdwn
index edd665185..f2d46c391 100644
--- a/doc/plugins/contrib/po.mdwn
+++ b/doc/plugins/contrib/po.mdwn
@@ -171,3 +171,118 @@ Any thoughts on this?
 
 I've set this plugin development aside for a while. I will be back and
 finish it at some point in the first quarter of 2009. --[[intrigeri]]
+
+> Abstract: Joey, please have a look at my po and meta branches.
+> 
+> Detailed progress report:
+> 
+> * it seems the po branch in your repository has not been tracking my
+>   own po branch for two months. any config issue?
+> * all the plugin's todo items have been completed, robustness tests
+>   done
+> * I've finished the detailed security audit, and the fix for po4a
+>   bugs has entered upstream CVS last week
+> * I've merged your new `checkcontent` hook with the `cansave` hook
+>   I previously introduced in my own branch; blogspam plugin updated
+>   accordingly
+> * the rename hook changes we discussed elsewhere are also part of my
+>   branch
+> * I've introduced two new hooks (`canremove` and `canrename`), not
+>   a big deal; IMHO, they extend quite logically the plugin interface
+> * as highlighted on [[bugs/pagetitle_function_does_not_respect_meta_titles]],
+>   my `meta` branch contains a new feature that is really useful in a
+>   translatable wiki
+> 
+> As a conclusion, I'm feeling that my branches are ready to be
+> merged; only thing missing, I guess, are a bit of discussion and
+> subsequent adjustments.
+> 
+> --[[intrigeri]]
+
+> I've looked it over and updated my branch with some (untested)
+> changes.
+> 
+>> I've merged your changes into my branch. Only one was buggy.
+> 
+> Sorry, I'd forgotten about your cansave hook.. sorry for the duplicate
+> work there.
+> 
+> Reviewing the changes, mostly outside of `po.pm`, I have
+> the following issues.
+>  
+> * renamepage to renamelink change would break the ikiwiki
+>   3.x API, which I've promised not to do, so needs to be avoided
+>   somehow. (Sorry, I guess I dropped the ball on not getting this
+>   API change in before cutting 3.0..)
+>> 
+>> Fixed, see [[todo/need_global_renamepage_hook]].
+>>
+> * I don't understand the parentlinks code change and need to figure it
+>   out. Can you explain what is going on there?
+>> 
+>> I'm calling `bestlink` there so that po's injected `bestlink` is
+>> run. This way, the parent links of a page link to the parent page
+>> version in the proper language, depending on the
+>> `po_link_to=current` and `po_link_to=negotiated` settings.
+>> Moreover, when using my meta branch enhancements plus meta title to
+>> make pages titles translatable, this small patch is needed to get
+>> the translated titles into parentlinks.
+>> 
+> * canrename's mix of positional and named parameters is way too
+>   ugly to get into an ikiwiki API. Use named parameters
+>   entirely. Also probably should just use named parameters
+>   for canremove.
+> * `skeleton.pm.example`'s canrename needs fixing to use either
+>   the current or my suggested parameters.
+>> 
+>> Done.
+>> 
+> * I don't like the exporting of `%backlinks` and `$backlinks_calculated`
+>   (the latter is exported but not used).
+>> 
+>> The commit message for 85f865b5d98e0122934d11e3f3eb6703e4f4c620
+>> contains the rationale for this change. I guess I don't understand
+>> the subtleties of `our` use, and perldoc does not help me a lot.
+>> IIRC, I actually did not use `our` to "export" these variables, but
+>> rather to have them shared between `Render.pm` uses.
+>>
+>>> My wording was unclear, I meant exposing. --[[Joey]]
+>>>  
+> * What is this `IkiWiki::nicepagetitle` and why are you
+>   injecting it into that namespace when only your module uses it?
+>   Actually, I can't even find a caller of it in your module.
+>> 
+>> I guess you should have a look to my `meta` branch and to
+>> [[bugs/pagetitle_function_does_not_respect_meta_titles]] in order
+>> to understand this :)
+>>
+>>> It would probably be good if I could merge this branch without 
+>>> having to worry about also immediatly merging that one. --[[Joey]] 
+>> 
+> * I'm very fearful of the `add_depends` in `postscan`. 
+>   Does this make every page depend on every page that links
+>   to it? Won't this absurdly bloat the dependency pagespecs
+>   and slow everything down? And since nicepagetitle is given
+>   as the reason for doing it, and nicepagetitle isn't used,
+>   why do it?
+>> 
+>> As explained in the 85f865b5d98e0122934d11e3f3eb6703e4f4c620 log:
+>> this feature hits performance a bit. Its cost was quite small in my
+>> real-world use-cases (a few percents bigger refresh time), but
+>> could be bigger in worst cases. When using the po plugin with my
+>> meta branch changes (i.e. the `nicepagetitle` thing), and having
+>> enabled the option to display translation status in links, this
+>> maintains the translation status up-to-date in backlinks. Same when
+>> using meta title to make the pages titles translatable. It does
+>> help having a nice and consistent translated wiki, but as it can
+>> also involve problems, I just turned it into an option.
+>> 
+> * The po4a Suggests should be versioned to the first version
+>   that can be used safely, and that version documented in 
+>   `plugins/po.mdwn`.
+>>
+>> Done.
+>> 
+>> --[[intrigeri]]
+> 
+> --[[Joey]] 
diff --git a/doc/sandbox.mdwn b/doc/sandbox.mdwn
index d39b59715..a39264e18 100644
--- a/doc/sandbox.mdwn
+++ b/doc/sandbox.mdwn
@@ -1,14 +1,8 @@
-This is the [[SandBox]], a page anyone can edit to try out ikiwiki.
-
-hello
-
-testing 1..2..3!!
-
-----
-
-I am testing the edit box provided through ikiwiki.cgi.
+This is the [[SandBox]], a page anyone can edit to try out ikiwiki (version [[!version  ]]).
 
 ----
+test
+[[中文显示]]
 
 Here's a paragraph.
 
@@ -59,10 +53,6 @@ Bulleted list
        * four
         * five
 
-* a new list
- * with sub heads
- * like this
-
 ----
 
 [[!template id=note text="this is generated by the [[plugins/haiku]] plugin"]]
@@ -82,7 +72,6 @@ The haiku will change after every save, mind you.
 * [![ikiwiki logo](http://ikiwiki.info/logo/ikiwiki.png)](http://ikiwiki.info)
 * <a href="http://www.google.com/">plain old html link</a>
 * [[foo]]
-* WikiLink
 
 -----
 
diff --git a/doc/style.css b/doc/style.css
index 81a260afd..a6e6734e3 100644
--- a/doc/style.css
+++ b/doc/style.css
@@ -23,6 +23,8 @@
 	margin: 0;
 	padding: 6px;
 	list-style-type: none;
+}
+.pageheader .actions ul {
 	border-bottom: 1px solid #000;
 }
 
@@ -339,11 +341,6 @@ input#searchbox {
 	border: 2px solid;
 	background-color: #dee;
 	color: black;
-	
-	/* Nonstandard, but very nice. */
-	opacity: 0.95;
-	-moz-opacity: 0.95;
-	filter: alpha(opacity=95);
 }
 
 /* Formbuilder styling */
diff --git a/doc/todo/avatar.mdwn b/doc/todo/avatar.mdwn
new file mode 100644
index 000000000..b8aa2327f
--- /dev/null
+++ b/doc/todo/avatar.mdwn
@@ -0,0 +1,47 @@
+[[!tag wishlist]]
+
+It would be nice if ikiwiki, particularly [[plugins/comments]]
+supported user avatar icons. I was considering adding a directive for this,
+as designed below.
+
+However, there is no *good* service for mapping openids to avatars --
+openavatar has many issues, including not supporting delegated openids, and
+after trying it, I don't trust it to push users toward. 
+Perhaps instead ikiwiki could get the email address from the openid
+provider, though I think the perl openid modules don't support the openid
+2.x feature that allows that.
+
+At the moment, working on this doesn't feel like a good use of my time.
+--[[Joey]]
+
+Hmm.. unless is just always used a single provider (gravatar) and hashed
+the openid. Then wavatars could be used to get a unique avatar per openid
+at least. --[[Joey]] 
+
+----
+
+The directive displays a small avatar image for a user. Pass it the
+email address, openid, or wiki username of the user.
+
+	\[[!avatar user@example.com]]
+	\[[!avatar http://joey.kitenet.net/]]
+	\[[!avatar user]]
+
+The avatars are provided by various sites. For email addresses, it uses a
+[gravatar](http://gravatar.com/). For openid,
+[openavatar](http://www.openvatar.com/) is used. For a wiki username, the
+user's email address is looked up and the gravatar for that user is
+displayed. (Of course, the user has to have filled in their email address
+on their Preferences page for that to work.)
+
+An optional second parameter can be included, containing additional
+options to pass in the 
+[gravatar url](http://en.gravatar.com/site/implement/url).
+For example, this asks for a smaller gravatar, and if a user does
+not have a gravatar, uses a cute auto-generated "wavatar" avatar.
+
+	\[[!gravatar user@example.com "size=40&default=wavatar"]]
+
+The `gravitar_options` setting in the setup file can be used to
+specify additional options to pass. So for example if you want
+to use wavatars everywhere, set it to "default=wavatar".
diff --git a/doc/todo/need_global_renamepage_hook.mdwn b/doc/todo/need_global_renamepage_hook.mdwn
index f4e18baa2..62e91eee4 100644
--- a/doc/todo/need_global_renamepage_hook.mdwn
+++ b/doc/todo/need_global_renamepage_hook.mdwn
@@ -55,3 +55,28 @@ would solve my problem. Hmmm? --[[intrigeri]]
 >> In my `po` branch, I renamed `renamepage` to `renamelink`, and
 >> created a `rename` hook that is passed a reference to `@torename`.
 >> --[[intrigeri]]
+
+>>> As Joey highlights it on [[plugins/contrib/po]], it's too late to
+>>> merge such a change, as the 3.x plugin API is released and should
+>>> not be broken. I will thus keep the existing `renamepage` as it
+>>> is, and call `rename` the global hook I need. --[[intrigeri]]
+
+>>>> Done in my `po` branch. --[[intrigeri]]
+
+I think I see a problem in the rename hook. The hook is called
+before the plugin adds any subpages to the set of pages to rename.
+So, if the user choses to rename subpages, po will not notice
+they are moving, and will not move their po files.
+ 
+Perhaps the hooks should be moved to come after subpages are added.
+This would, though, mean that if the hook somehow decides to add
+entirely other pages to the list, their subpages would not be
+automatically added.
+
+I also have some qualms about the design of the hook. In particular,
+passing the mutable array reference probably makes it impossible
+to use from external plugins. Instead it could return any additional
+rename hashes it wants to add. Or, if the ability to modify existing
+hashes is desired, it could return the full set of hashes.
+
+--[[Joey]] 
diff --git a/doc/todo/overriding_displayed_modification_time.mdwn b/doc/todo/overriding_displayed_modification_time.mdwn
new file mode 100644
index 000000000..160d31519
--- /dev/null
+++ b/doc/todo/overriding_displayed_modification_time.mdwn
@@ -0,0 +1,27 @@
+Some aggregators, like Planet, sort by mtime rather than ctime. This
+means that posts with modified content come to the top (which seems odd
+to me, but is presumably what the aggregator's author or operator
+wants),
+
+> Hah! That's so charitable I hope you can deduct it from your taxes. ;-)
+> --[[Joey]] 
+
+but it also means that posts with insignificant edits (like
+adding tags) come to the top too. Atom defines `<updated>` to be the date
+of the last *significant* change, so it's fine that ikiwiki defaults to
+using the mtime, but it would be good to have a way for the author to
+say "that edit was insignificant, don't use that mtime".
+
+> Yes, this is a real limitiation of ikiwiki's atom support. --[[Joey]] 
+
+See smcv's 'updated' branch for a basic implementation, which only affects
+the Atom `<updated>` field or the RSS equivalent.
+
+Other places the updated metadata item could be used (opinions on whether
+each should use it or not, please):
+
+* sorting by mtime in the inline directive
+* displaying "last edited" on ordinary pages
+
+> Tending toward no for both, but willing to be convinced otherwise..
+> [[merged|done]] --[[Joey]]  
diff --git a/doc/todo/replace_HTML::Template_with_Template_Toolkit.mdwn b/doc/todo/replace_HTML::Template_with_Template_Toolkit.mdwn
index 3b9f6c0fd..c4e78ca0b 100644
--- a/doc/todo/replace_HTML::Template_with_Template_Toolkit.mdwn
+++ b/doc/todo/replace_HTML::Template_with_Template_Toolkit.mdwn
@@ -56,3 +56,5 @@ the templates. I'd prefer not having to touch Perl though...
 Yes, Template::Toolkit is very powerful. But I think it's somehow overkill for a wiki. HTML::Template can keep things simple, though.  --[weakish](http://weakish.int.eu.org/blog/)
 
 I'd have to agree that Template::Toolkit is overkill and personally I'm not a fan, but it is very popular (there is even a book) and the new version (3) is alleged to be much more nimble than current version.  --[[ajt]]
+
+HTML::Template's HTML-like markup prevents me from editing templates in KompoZer or other WYSIWYG HTML editors.  The editor tries to render the template markup rather than display it verbatim, and large parts of the template become invisible.  A markup syntax that doesn't confuse editors (such as Template::Toolkit's "[% FOO %]") may promote template customization.  The ability to replace the template engine would be within the spirit of ikiwiki's extensibility. --Rocco
diff --git a/doc/users/smcv.mdwn b/doc/users/smcv.mdwn
index c52aa8f0f..59d1affba 100644
--- a/doc/users/smcv.mdwn
+++ b/doc/users/smcv.mdwn
@@ -7,4 +7,4 @@ My repository containing ikiwiki branches:
 * gitweb: http://git.pseudorandom.co.uk/smcv/ikiwiki.git
 * anongit: git://git.pseudorandom.co.uk/git/smcv/ikiwiki.git
 
-Currently working on the [[plugins/contrib/comments]] plugin.
+Currently thinking about a [[users/smcv/gallery]] plugin.
diff --git a/doc/users/smcv/gallery.mdwn b/doc/users/smcv/gallery.mdwn
index 40e9f6279..5b4c6fe00 100644
--- a/doc/users/smcv/gallery.mdwn
+++ b/doc/users/smcv/gallery.mdwn
@@ -13,10 +13,10 @@ and Facebook's Photos "application".
 
 The web UI I'm trying to achieve consists of one
 [HTML page of thumbnails](http://www.pseudorandom.co.uk/2008/2008-03-08-panic-cell-gig/)
-as an entry point to the gallery, where each thumbnail
-links to
+as an entry point to the gallery, where each thumbnail links to
 [a "viewer" HTML page](http://www.pseudorandom.co.uk/2008/2008-03-08-panic-cell-gig/img_0068/)
-with a full size image, next/previous thumbnail links, and [[plugins/comments]].
+with a full size image, next/previous thumbnail links, and
+[[plugins/comments]].
 
 (The Summer of Code [[plugins/contrib/gallery]] plugin does the
 next/previous UI in Javascript using Lightbox, which means that
@@ -44,13 +44,14 @@ Other features that would be good to have:
 
 * rendering an `<object>/<embed>` arrangement to display videos, and possibly
   thumbnailing them in the same way as totem-video-thumbnailer
-  (my camera can record short videos, so some of my web photo galleries contain
-  them)
+  (my camera can record short videos, so some of my web photo galleries
+  contain them)
 
 My plan is to have these directives:
 
-* \[[!gallery]] registers the page it's on as a gallery, and displays all photos
-  that are part of this gallery but not part of a \[[!gallerysection]] (below).
+* \[[!gallery]] registers the page it's on as a gallery, and displays all
+  photos that are part of this gallery but not part of a \[[!gallerysection]]
+  (below).
 
   All images (i.e. `*.png *.jpg *.gif`) that are attachments to the gallery page
   or its subpages are considered to be part of the gallery.
@@ -65,7 +66,8 @@ My plan is to have these directives:
 * \[[!gallerysection filter="[[ikiwiki/PageSpec]]"]] displays all photos in the
   gallery that match the filter
 
-So, [the gallery I'm using as an example](http://www.pseudorandom.co.uk/2008/2008-03-08-panic-cell-gig/)
+So,
+[the gallery I'm using as an example](http://www.pseudorandom.co.uk/2008/2008-03-08-panic-cell-gig/)
 could look something like this:
 
     \[[!gallery]]
@@ -85,13 +87,6 @@ could look something like this:
 
 ## Implementation ideas
 
-The photo galleries I have at the moment, like the Panic Cell example above,
-are made by using an external script to parse XML gallery descriptions (lists
-of image filenames, with metadata such as titles), and using this to write IkiWiki
-markup into a directory which is then used as an underlay. This is a hack, but it
-works. The use of XML is left over from a previous attempt at solving the same
-problem using Django.
-
 The next/previous part this plugin overlaps with [[todo/wikitrails]].
 
 A \[[!galleryimg]] directive to assign metadata to images is probably necessary, so
@@ -100,15 +95,21 @@ the gallery page can contain something like:
     \[[!galleryimg p1010001.jpg title="..." caption="..." tags="foo"]]
     \[[!galleryimg p1010002.jpg title="..." caption="..." tags="foo bar"]]
 
-Making the viewer pages could be rather tricky.
+Making the viewer pages could be rather tricky. Here are some options:
+"synthesize source pages for viewers" is the one I'm leaning towards at the
+moment.
+
+### Viewers' source page is the gallery
 
-One possibility is to write out the viewer pages as a side-effect of preprocessing
-the \[[!gallery]] directive. The proof-of-concept implementation below does this.
-However, this does mean the viewer pages can't have tags or metadata of their own
-and can't be matched by [[pagespecs|ikiwiki/pagespec]] or
+One possibility is to write out the viewer pages as a side-effect of
+preprocessing the \[[!gallery]] directive. The proof-of-concept implementation
+below does this.  However, this does mean the viewer pages can't have tags or
+metadata of their own and can't be matched by [[pagespecs|ikiwiki/pagespec]] or
 [[wikilinks|ikiwiki/wikilink]]. It might be possible to implement tagging by
 using \[[!galleryimg]] to assign the metadata to the *images* instead of their
-viewers, 
+viewers.
+
+### Synthesize source pages for viewers
 
 Another is to synthesize source pages for the viewers. This means they can have
 tags and metadata, but trying to arrange for them to be scanned etc. correctly
@@ -117,13 +118,75 @@ without needing another refresh run is somewhat terrifying.
 the refresh hook, but I don't really like the idea of a refresh hook that scans
 all source pages to see if they contain \[[!gallery]]...
 
-Making the image be the source page (and generate HTML itself) would be possible,
-but I wouldn't want to generate a HTML viewer for every `.jpg` on a site, so
-either the images would have to have a special extension (awkward for uploads from
-Windows users) or the plugin would have to be able to change whether HTML was
-generated in some way (not currently possible).
-
-## Proof-of-concept
+The photo galleries I have at the moment, like the Panic Cell example above,
+are made by using an external script to parse XML gallery descriptions (lists
+of image filenames, with metadata such as titles), and using this to write
+IkiWiki markup into a directory which is then used as an underlay. This is a
+hack, but it works. The use of XML is left over from a previous attempt at
+solving the same problem using Django.
+
+Perhaps a better approach would be to have a setupfile option that names a
+particular underlay directory (meeting the objective of not having large
+photos under source code control) and generates a source page for each file
+in that directory during the refresh hook. The source pages could be in the
+underlay until they are edited (e.g. tagged), at which point they would be
+copied into the source-code-controlled version in the usual way.
+
+The synthetic source pages can be very simple, using the same trick as my
+[[plugins/comments]] plugin (a dedicated [[directive|ikiwiki/directives]]
+encapsulating everything the plugin needs). If the plugin automatically
+gathers information like file size, pixel size, date etc. from the images, then
+only the human-edited information and a filename reference need to be present
+in the source page; with some clever lookup rules based on the filename of
+the source page, not even the photo's filename is necessarily needed.
+
+    \[[!meta title="..."]]
+    \[[!meta date="..."]]
+    \[[!meta copyright="..."]]
+    \[[!tag ...]]
+
+    \[[!galleryimageviewer p1010001.jpg]]
+
+However, this would mean that editing tags and other metadata would require
+editing pages individually. Rather than trying to "fix" that, perhaps it would
+be better to have a special CGI interface for bulk tagging/metadata editing.
+This could even be combined with a bulk upload form (a reasonable number of
+file upload controls - maybe 20 - with metadata alongside each).
+
+Uploading multiple images is necessarily awkward due to restrictions placed on
+file upload controls by browsers for security reasons - sites like Facebook
+allow whole directories to be uploaded at the same time, but they achieve this
+by using a signed Java applet with privileged access to the user's filesystem.
+
+I've found that it's often useful to be able to force the creation time of
+photos (my camera's battery isn't very reliable, and it frequently decides that
+the date is 0000-00-00 00:00:00), so treating the \[[!meta date]] of the source
+page and the creation date of the photo as synonymous would be useful.
+
+### Images are the viewer's source - special filename extension
+
+Making the image be the source page (and generate HTML itself) would be
+possible, but I wouldn't want to generate a HTML viewer for every `.jpg` on a
+site, so either the images would have to have a special extension (awkward for
+uploads from Windows users) or the plugin would have to be able to change
+whether HTML was generated in some way (not currently possible).
+
+### Images are the viewer's source - alter `ispage()`
+
+It might be possible to hack up `ispage()` so some, but not all, images are
+considered to "be a page":
+
+* srcdir/not-a-photo.jpg → destdir/not-a-photo.jpg
+* srcdir/gallery/photo.jpg → destdir/gallery/photo/index.html
+
+Perhaps one way to do this would be for the photos to appear in a particular
+underlay directory, which would also fulfil the objective of having photos not
+be version-controlled:
+
+* srcdir/not-a-photo.jpg → destdir/not-a-photo.jpg
+* underlay/gallery/photo.jpg → destdir/gallery/photo/index.html
+
+## Proof-of-concept implementation of "viewers' source page is the gallery"
 
     #!/usr/bin/perl
     package IkiWiki::Plugin::gallery;
diff --git a/doc/wikitemplates.mdwn b/doc/wikitemplates.mdwn
index dc217cd30..fc5893677 100644
--- a/doc/wikitemplates.mdwn
+++ b/doc/wikitemplates.mdwn
@@ -33,6 +33,8 @@ located in /usr/share/ikiwiki/templates by default.
   by the [[plugins/comments]] plugin.
 * `editcomment.tmpl` - This template is the comment post form for the
   [[plugins/comments]] plugin.
+* `commentmoderation.tmpl` - This template is used to produce the comment
+  moderation form.
 
 The [[plugins/pagetemplate]] plugin can allow individual pages to use a
 different template than `page.tmpl`.