Merge branch 'master' into po

20 files changed, 377 insertions, 52 deletions

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..e68c2c726
--- /dev/null
+++ b/doc/forum/chinese_character_problem.mdwn
@@ -0,0 +1,17 @@
+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?
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..af748a8d3 100644
--- a/doc/plugins/contrib/po.mdwn
+++ b/doc/plugins/contrib/po.mdwn
@@ -171,3 +171,30 @@ 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]]
diff --git a/doc/plugins/contrib/underlay.mdwn b/doc/plugins/contrib/underlay.mdwn
new file mode 100644
index 000000000..72893c992
--- /dev/null
+++ b/doc/plugins/contrib/underlay.mdwn
@@ -0,0 +1,58 @@
+[[!template id=plugin name=underlay author="[[Simon_McVittie|smcv]]"]]
+[[!tag type/useful]]
+
+This plugin adds an `add_underlays` option to the `.setup` file.
+Its value is a list of underlay directories whose content is added to the wiki.
+
+Multiple underlays are normally set up automatically by other plugins (for
+instance, the images used by the [[plugins/smiley]] plugin), but they can also be
+used as a way to pull in external files that you don't want in revision control,
+like photos or software releases.
+
+Directories in `add_underlays` should usually be absolute. If relative, they're
+interpreted as relative to the parent directory of the basewiki underlay, which
+is probably not particularly useful in this context.
+
+Please feel free to add this plugin to ikiwiki if it seems like a good
+thing to have. See the 'underlay' branch in my git repository.
+
+    #!/usr/bin/perl
+    package IkiWiki::Plugin::underlay;
+    # Copyright © 2008 Simon McVittie <http://smcv.pseudorandom.co.uk/>
+    # Licensed under the GNU GPL, version 2, or any later version published by the
+    # Free Software Foundation
+
+    use warnings;
+    use strict;
+    use IkiWiki 2.00;
+
+    sub import {
+    	hook(type => "getsetup", id => "underlay",  call => \&getsetup);
+    	hook(type => "checkconfig", id => "underlay", call => \&checkconfig);
+    }
+
+    sub getsetup () {
+    	return
+    		plugin => {
+    			safe => 0,
+    			rebuild => undef,
+    		},
+    		add_underlays => {
+    			type => "string",
+    			default => [],
+    			description => "extra underlay directories to add",
+    			advanced => 1,
+    			safe => 0,
+    			rebuild => 1,
+    		},
+    }
+
+    sub checkconfig () {
+    	return unless exists $config{add_underlays};
+
+    	foreach my $dir (@{$config{add_underlays}}) {
+    		add_underlay($dir);
+    	}
+    }
+
+    1;
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/overriding_displayed_modification_time.mdwn b/doc/todo/overriding_displayed_modification_time.mdwn
new file mode 100644
index 000000000..b015b3730
--- /dev/null
+++ b/doc/todo/overriding_displayed_modification_time.mdwn
@@ -0,0 +1,17 @@
+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), 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".
+
+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
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`.