Recent changes to this wiki:

diff --git a/doc/forum/Problems_with_img_directive_on_nearly_free_speech.mdwn b/doc/forum/Problems_with_img_directive_on_nearly_free_speech.mdwn
index f364ead..2552054 100644
--- a/doc/forum/Problems_with_img_directive_on_nearly_free_speech.mdwn
+++ b/doc/forum/Problems_with_img_directive_on_nearly_free_speech.mdwn
@@ -1,3 +1,3 @@
-Hey everyone, I have a problem with the img plugin/directive. I get an error stating "[[!img Error: Image::Magick is not installed]]". So the directive "tag" thingie is shown with an error where I had written the path to the image in the markdown file (of this blog post, in that case…). Any ideas why this might happen? Maybe a problem with my hoster, which is nearlyfreespeech (I couldn't install ```Image::Magick``` with either ```PERL5LIB=`pwd`/ikiwiki:`pwd`/ikiwiki/cpan:`pwd`/lib/perl5 PERL_MM_USE_DEFAULT=1 perl -MCPAN -e 'CPAN::Shell->install("Image::Magick")'``` nor with ```PERL5LIB=`pwd`/ikiwiki:`pwd`/ikiwiki/cpan:`pwd`/lib/perl5 PERL_MM_USE_DEFAULT=1 perl -MCPAN -e 'CPAN::Shell->force(install => "Image::Magick")'``` which I both adapted from [this tip](https://ikiwiki.info/tips/nearlyfreespeech/). But in two admittedly very old (members only) forum posts (from 2003 and 2004, respectively) they said, they do indeed have support for PerlMagick.)?
+Hey everyone, I have a problem with the img plugin/directive. I get an error stating "```\[[!img Error: Image::Magick is not installed]]```". So the directive "tag" thingie is shown with an error where I had written the path to the image in the markdown file (of this blog post, in that case…). Any ideas why this might happen? Maybe a problem with my hoster, which is nearlyfreespeech (I couldn't install ```Image::Magick``` with either ```PERL5LIB=`pwd`/ikiwiki:`pwd`/ikiwiki/cpan:`pwd`/lib/perl5 PERL_MM_USE_DEFAULT=1 perl -MCPAN -e 'CPAN::Shell->install("Image::Magick")'``` nor with ```PERL5LIB=`pwd`/ikiwiki:`pwd`/ikiwiki/cpan:`pwd`/lib/perl5 PERL_MM_USE_DEFAULT=1 perl -MCPAN -e 'CPAN::Shell->force(install => "Image::Magick")'``` which I both adapted from [this tip](https://ikiwiki.info/tips/nearlyfreespeech/). But in two admittedly very old (members only) forum posts (from 2003 and 2004, respectively) they said, they do indeed have support for PerlMagick.)?
 
 Thanks in advance as allways for any help you can offer!

diff --git a/doc/forum/Problems_with_img_directive_on_nearly_free_speech.mdwn b/doc/forum/Problems_with_img_directive_on_nearly_free_speech.mdwn
new file mode 100644
index 0000000..f364ead
--- /dev/null
+++ b/doc/forum/Problems_with_img_directive_on_nearly_free_speech.mdwn
@@ -0,0 +1,3 @@
+Hey everyone, I have a problem with the img plugin/directive. I get an error stating "[[!img Error: Image::Magick is not installed]]". So the directive "tag" thingie is shown with an error where I had written the path to the image in the markdown file (of this blog post, in that case…). Any ideas why this might happen? Maybe a problem with my hoster, which is nearlyfreespeech (I couldn't install ```Image::Magick``` with either ```PERL5LIB=`pwd`/ikiwiki:`pwd`/ikiwiki/cpan:`pwd`/lib/perl5 PERL_MM_USE_DEFAULT=1 perl -MCPAN -e 'CPAN::Shell->install("Image::Magick")'``` nor with ```PERL5LIB=`pwd`/ikiwiki:`pwd`/ikiwiki/cpan:`pwd`/lib/perl5 PERL_MM_USE_DEFAULT=1 perl -MCPAN -e 'CPAN::Shell->force(install => "Image::Magick")'``` which I both adapted from [this tip](https://ikiwiki.info/tips/nearlyfreespeech/). But in two admittedly very old (members only) forum posts (from 2003 and 2004, respectively) they said, they do indeed have support for PerlMagick.)?
+
+Thanks in advance as allways for any help you can offer!

Hadn't listed any drawbacks for the FastCGI Authorizer idea.
diff --git a/doc/todo/Zoned_ikiwiki.mdwn b/doc/todo/Zoned_ikiwiki.mdwn
index 24fe221..6b56221 100644
--- a/doc/todo/Zoned_ikiwiki.mdwn
+++ b/doc/todo/Zoned_ikiwiki.mdwn
@@ -107,6 +107,12 @@ that header might not be needed in the request, and care may be needed to config
 the server to emit other necessary response headers to discourage caching of
 content from a private zone.
 
+*Drawbacks:* Not yet implemented, someone would have to do it.
+It's not clear [[what code changes fastcgi|todo/fastcgi or modperl installation instructions]]
+would require in ikiwiki. An Authorizer seems like a good place to start because of its
+limited, simple functionality--but as it could make use of any ikiwiki-supported auth method,
+evaluate `PageSpec`s, and the like, it could still run a non-trivial amount of the code.
+
 ## Obstacles
 
 A number of ikiwiki features aren't (yet) designed with zoning in mind,

Review request for: Let plugins influence what environment variables a wrapper will preserve
diff --git a/doc/todo/Let_plugins_influence_what_environment_variables_a_wrapper_will_preserve.mdwn b/doc/todo/Let_plugins_influence_what_environment_variables_a_wrapper_will_preserve.mdwn
new file mode 100644
index 0000000..1626367
--- /dev/null
+++ b/doc/todo/Let_plugins_influence_what_environment_variables_a_wrapper_will_preserve.mdwn
@@ -0,0 +1,12 @@
+I created this patch in advance of writing the [[plugins/contrib/signinview]] plugin. This patch does nothing `signinview`-specific, but simply refactors wrapper generation a bit so that plugins have some influence over what environment variables a wrapper will preserve.
+
+For example, Wrapper.pm previously hardcoded not only (some of) the RFC 3875 variables needed for a CGI wrapper (and hardcoded its own test for _whether it was generating_ a CGI wrapper), but also the Apache ErrorDocument-specific variables needed by the [[plugins/404]] plugin. Given that `signinview`, as a `403` handler, would have similar requirements to `404`, and it seemed possible other wrappers for other purposes could rely on other environment variables too, it seemed to make sense to move the preserved-variable list out of Wrapper.pm hardcoding, and closer to the plugins or other code relying on the variables.
+
+More comments and the code changes for review are [here](https://github.com/joeyh/ikiwiki/pull/14).
+
+----
+I was asked by [[Joey]] to create a page here for purposes of review. I'm still trying to figure out the preferred workflow for this project ... I'm assuming the link above is ok for looking over the comments and code changes, since they're already pushed to my git fork and (to me, anyway) reviewing changes in a decent repository browser is so much nicer than a `diff -u` pasted into a page between `<pre>` tags.
+
+That seemed to be ok for reviewing [[bugs/CGI wrapper doesn't store PERL5LIB environment variable]], so I hope it's ok for this one too.
+
+-- [[jcflack]]

Fix dangling link to branch I deleted after merge. Link instead to merged commits in ikiwiki repo.
diff --git a/doc/bugs/CGI_wrapper_doesn__39__t_store_PERL5LIB_environment_variable.mdwn b/doc/bugs/CGI_wrapper_doesn__39__t_store_PERL5LIB_environment_variable.mdwn
index 140b487..c7d3d6f 100644
--- a/doc/bugs/CGI_wrapper_doesn__39__t_store_PERL5LIB_environment_variable.mdwn
+++ b/doc/bugs/CGI_wrapper_doesn__39__t_store_PERL5LIB_environment_variable.mdwn
@@ -28,7 +28,7 @@ As I am not sure that remembering `PERL5LIB` is a good idea, I think that a pret
 -- Bruno
 
 **Update:** I had not seen this bug earlier, but I ran into the same issue and made a more general solution. You can already add stuff to `%config{ENV}` in the setup file, but it was being processed too late for `PERL5LIB` to do any good.
-[This change](https://github.com/jcflack/ikiwiki/compare/early-env) moves the `%config{ENV}` handling earlier in the wrapper, so anything specified there is placed back in the actual environment before Perl gets control. Problem solved!
+[This change](http://source.ikiwiki.branchable.com/?p=source.git;a=log;h=29e80b4eedadc2afd3f9f36d215076c82982971b;hp=6057107d71e9944bd6fd7093060e4297e617733e) moves the `%config{ENV}` handling earlier in the wrapper, so anything specified there is placed back in the actual environment before Perl gets control. Problem solved!
 
 -- Chap
 

add ikiwiki-comment program
diff --git a/.gitignore b/.gitignore
index 8528fe9..77c0b3d 100644
--- a/.gitignore
+++ b/.gitignore
@@ -8,6 +8,7 @@ html/*
 ikiwiki.out
 ikiwiki-transition.out
 ikiwiki-calendar.out
+ikiwiki-comment.out
 pm_to_blib
 /MYMETA.json
 /MYMETA.yml
diff --git a/IkiWiki/Plugin/comments.pm b/IkiWiki/Plugin/comments.pm
index c517783..d7666c8 100644
--- a/IkiWiki/Plugin/comments.pm
+++ b/IkiWiki/Plugin/comments.pm
@@ -507,8 +507,7 @@ sub editcomment ($$) {
 		$subject = "comment ".(num_comments($page, $config{srcdir}) + 1);
 	}
 	$content .= " subject=\"$subject\"\n";
-
-	$content .= " date=\"" . strftime_utf8('%Y-%m-%dT%H:%M:%SZ', gmtime) . "\"\n";
+	$content .= " " . commentdate() . "\n";
 
 	my $editcontent = $form->field('editcontent');
 	$editcontent="" if ! defined $editcontent;
@@ -636,6 +635,10 @@ sub editcomment ($$) {
 	exit;
 }
 
+sub commentdate () {
+	"date=\"" . strftime_utf8('%Y-%m-%dT%H:%M:%SZ', gmtime) . "\"";
+}
+
 sub getavatar ($) {
 	my $user=shift;
 	return undef unless defined $user;
@@ -1012,7 +1015,7 @@ sub num_comments ($$) {
 	return int @comments;
 }
 
-sub unique_comment_location ($$$$) {
+sub unique_comment_location ($$$;$) {
 	my $page=shift;
 	eval q{use Digest::MD5 'md5_hex'};
 	error($@) if $@;
diff --git a/Makefile.PL b/Makefile.PL
index 312a148..5feb304 100755
--- a/Makefile.PL
+++ b/Makefile.PL
@@ -24,7 +24,7 @@ MANDIR?=$(PREFIX)/share/man
 
 tflag=$(shell if [ -n "$$NOTAINT" ] && [ "$$NOTAINT" != 1 ]; then printf -- "-T"; fi)
 extramodules=$(shell if [ "$$PROFILE" = 1 ]; then printf -- "-d:NYTProf"; fi)
-outprogs=ikiwiki.out ikiwiki-transition.out ikiwiki-calendar.out
+outprogs=ikiwiki.out ikiwiki-transition.out ikiwiki-calendar.out ikiwiki-comment.out
 scripts=ikiwiki-update-wikilist ikiwiki-makerepo
 sysconfdir_scripts=ikiwiki-mass-rebuild ikiwiki-update-wikilist
 shebang_scripts=$(shell $(FIND) . -type f \( -name '*.in' -o -name '*.cgi' -o -name '*.pm' -o -name '*.pm.example' -o -name '*.t' -o -name '*.setup' -o -name 'ikiwiki-mass-rebuild' -o -name 'ikiwiki-update-wikilist' -o -name 'gitremotes' -o -name 'mdwn2man' -o -name 'pm_filter' -o -name 'po2wiki' -o -name 'externaldemo' \))
@@ -53,6 +53,7 @@ extra_build: perl_shebangs $(outprogs) ikiwiki.setup docwiki sysconfdir
 	./mdwn2man ikiwiki-transition 1 doc/ikiwiki-transition.mdwn > ikiwiki-transition.man
 	./mdwn2man ikiwiki-update-wikilist 1 doc/ikiwiki-update-wikilist.mdwn > ikiwiki-update-wikilist.man
 	./mdwn2man ikiwiki-calendar 1 doc/ikiwiki-calendar.mdwn > ikiwiki-calendar.man
+	./mdwn2man ikiwiki-comment 1 doc/ikiwiki-comment.mdwn > ikiwiki-comment.man
 	$(MAKE) -C po
 	$(PERL) -pi.bkp -e "s/Version:.*/Version: $(VER)/" ikiwiki.spec
 	rm -f ikiwiki.spec.bkp
@@ -156,6 +157,7 @@ extra_install: underlay_install
 	install -m 644 ikiwiki-transition.man $(DESTDIR)$(MANDIR)/man1/ikiwiki-transition.1
 	install -m 644 ikiwiki-update-wikilist.man $(DESTDIR)$(MANDIR)/man1/ikiwiki-update-wikilist.1
 	install -m 644 ikiwiki-calendar.man $(DESTDIR)$(MANDIR)/man1/ikiwiki-calendar.1
+	install -m 644 ikiwiki-comment.man $(DESTDIR)$(MANDIR)/man1/ikiwiki-comment.1
 	
 	install -d $(DESTDIR)$(MANDIR)/man8
 	install -m 644 ikiwiki-mass-rebuild.man $(DESTDIR)$(MANDIR)/man8/ikiwiki-mass-rebuild.8
diff --git a/debian/changelog b/debian/changelog
index 7dc5763..5b0b2f3 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,9 @@
+ikiwiki (3.20141017) UNRELEASED; urgency=medium
+
+  * Added ikiwiki-comment program.
+
+ -- Joey Hess <joeyh@debian.org>  Mon, 20 Oct 2014 12:04:49 -0400
+
 ikiwiki (3.20141016) unstable; urgency=medium
 
   [ Joey Hess ]
diff --git a/doc/ikiwiki-comment.mdwn b/doc/ikiwiki-comment.mdwn
new file mode 100644
index 0000000..22dbd60
--- /dev/null
+++ b/doc/ikiwiki-comment.mdwn
@@ -0,0 +1,31 @@
+# NAME
+
+ikiwiki-comment - posts a comment
+
+# SYNOPSIS
+
+ikiwiki-comment page.mdwn
+
+# DESCRIPTION
+
+`ikiwiki-comment` creates a comment for the specified wiki page file,
+and opens your editor to edit it.
+
+Once you're done, it's up to you to add the comment to whatever version
+control system is being used by the wiki, and do any necessary pushing to
+publish it.
+
+Note that since ikiwiki-comment is not passed the configuration of
+the wiki it's acting on, it doesn't know what types of markup are
+available. Instead, it always removes one level of extensions from the
+file, so when run on a page.mdwn file, it puts the comment in page/
+
+The username field is set to the unix account name you're using.
+You may want to edit it to match the username you use elsewhere
+on the wiki.
+
+# AUTHOR
+
+Joey Hess <joey@ikiwiki.info>
+
+Warning: this page is automatically made into ikiwiki-comments's man page, edit with care
diff --git a/ikiwiki-comment.in b/ikiwiki-comment.in
new file mode 100755
index 0000000..ef2751e
--- /dev/null
+++ b/ikiwiki-comment.in
@@ -0,0 +1,50 @@
+#!/usr/bin/perl
+use warnings;
+use strict;
+use lib '.'; # For use in nonstandard directory, munged by Makefile.
+use IkiWiki;
+use IkiWiki::Plugin::comments;
+
+sub usage () {
+	die gettext("usage: ikiwiki-comment pagefile"), "\n";
+}
+
+my $pagefile=shift || usage ();
+
+my $dir=IkiWiki::dirname($pagefile);
+$dir="." unless length $dir;
+my $page=IkiWiki::basename($pagefile);
+$page=~s/\.[^.]+$//;
+
+IkiWiki::Plugin::comments::checkconfig();
+my $comment_num=1 + IkiWiki::Plugin::comments::num_comments($page, $dir);
+
+my $username = getpwuid($<);
+if (! defined $username) { $username="" }
+
+my $comment="[[!comment format=mdwn\n";
+$comment.=" username=\"$username\"\n";
+$comment.=" subject=\"\"\"comment $comment_num\"\"\"\n";
+$comment.=" " . IkiWiki::Plugin::comments::commentdate() . "\n";
+$comment.=" content=\"\"\"\n\n\"\"\"]]\n";
+
+# This will yield a hash of the comment before it's edited,
+# but that's ok; the date provides sufficient entropy to avoid collisions,
+# and the hash of a comment does not need to match its actual content.
+# Doing it this way avoids needing to move the file to a final
+# location after it's edited.
+my $location=IkiWiki::Plugin::comments::unique_comment_location($page, $comment, $dir)."._comment";
+
+IkiWiki::writefile($location, $dir, $comment);
+
+my @editor="vi";
+if (-x "/usr/bin/editor") {
+	@editor="/usr/bin/editor";
+}
+if (exists $ENV{EDITOR}) {
+	@editor=split(' ', $ENV{EDITOR});
+}
+if (exists $ENV{VISUAL}) {
+@editor=split(' ', $ENV{VISUAL});
+}
+exec(@editor, "$dir/$location");

bit on how inlinability isn't only bad
diff --git a/doc/todo/Zoned_ikiwiki.mdwn b/doc/todo/Zoned_ikiwiki.mdwn
index ee0cdfe..24fe221 100644
--- a/doc/todo/Zoned_ikiwiki.mdwn
+++ b/doc/todo/Zoned_ikiwiki.mdwn
@@ -248,3 +248,10 @@ review of the code and plugins (including third-party plugins) to complete.
 * Not to forget `contrib` plugins
     * [[plugins/contrib/report]] ?
     * _others_?
+
+Note that, _with_ the right controls on who can edit the pages and insert
+the directives, the fact that a public page can inline stuff from private
+pages can be very useful. Public pages can be created that are populated
+by selected content that's maintained on the private side. The [[ikiwiki/directive/if]]
+directive can be used in the private content to control what parts can be
+inlined into public pages. All of this is in ikiwiki today.

Add link to the proposed wrapper generation patch
diff --git a/doc/plugins/contrib/signinview.mdwn b/doc/plugins/contrib/signinview.mdwn
index 6fc9cd9..0bfdd9f 100644
--- a/doc/plugins/contrib/signinview.mdwn
+++ b/doc/plugins/contrib/signinview.mdwn
@@ -137,7 +137,8 @@ faster than typing the file on the fly.
 ## Obtaining and installing
 
 The `signinview` plugin is [not in github yet](https://github.com/jcflack/ikiwiki/tree/plug-signinview)
-(horroars! vaporware!). What _is_ in github at the moment is a preliminary patch I have proposed,
+(horroars! vaporware!). What _is_ in github at the moment is a preliminary patch I have
+[proposed](https://github.com/joeyh/ikiwiki/pull/14),
 giving plugins some control over the environment variables that a generated wrapper will preserve.
 
 Depending on the ultimate fate of that patch, I will adjust/rebase and then push the `signinview`

initial description of signinview plugin
diff --git a/doc/plugins/contrib/signinview.mdwn b/doc/plugins/contrib/signinview.mdwn
new file mode 100644
index 0000000..6fc9cd9
--- /dev/null
+++ b/doc/plugins/contrib/signinview.mdwn
@@ -0,0 +1,144 @@
+[[!template id=plugin name=signinview core=0 author="[[jcflack]]"]]
+[[!tag type/special-purpose]]
+
+This plugin is one implementation approach to a [[todo/zoned ikiwiki]]. It is named
+like [[plugins/signinedit]], which requires users to sign in before editing pages.
+Similarly, this plugin requires users to sign in before _viewing_ certain pages.
+Unlike [[plugins/signinedit]], which _only_ checks that any user is signed in,
+this plugin is also similar to [[plugins/lockedit]] in that it checks the user's
+identity and a [[ikiwiki/PageSpec]] to determine _which_ pages may be viewed.
+It works with any auth methods ikiwiki supports, not only those the `http` server
+also understands.
+
+## How to configure
+
+This plugin adds a new function, `do=view`, to ikiwiki's CGI wrapper. It is intended
+to be called by the `http` server as an `ErrorDocument` for the `403` (forbidden) error response.
+
+In order to be usable even in shared-hosting situations without full access to
+the `http` server configuration files, this plugin requires nothing more than
+`.htaccess` files, as long as the server is configured to honor `ErrorDocument` and
+`Deny` or `Require` directives in them.
+
+To divide the wiki into a public zone and one or more private zone(s), simply place
+`Require all denied` (Apache 2.4), `Deny from All` (Apache 2.2), or the equivalent
+directive for the server and version in use, on the topmost directory of any private
+zone, either in an `.htaccess` file, or in the server configuration file if possible.
+Any location outside of these will continue to be served as normal public static
+ikiwiki content.
+
+Then, if the `{$cgiurl}` is, for example, `/cgi-bin/ikiwiki.cgi`, add the directive
+
+    ErrorDocument 403 /cgi-bin/ikiwiki.cgi?do=view
+
+at the private locations or any ancestor up to the documentroot itself, again either
+in a `.htaccess` file or in the server configuration file.
+
+That's it for the server configuration. The server will now punt every request for
+private content to the ikiwiki wrapper. Everything else about the authorization
+decision--what auth method to use, whether there is just one private zone or different
+zones for different users--is handled by ikiwiki using a [[ikiwiki/PageSpec]].
+
+### viewable_pages config option
+
+This option in `ikiwiki.setup` is a [[ikiwiki/PageSpec]] defining which pages can be viewed.
+Because one predicate that can be used in a [[ikiwiki/PageSpec]] is `user`, this is enough
+to define interesting access rules. For example:
+
+    viewable_pages: >
+      ((user(astolfo) or user(basilio)) and team1/*)
+      or
+      ((user(clotaldo) or user(estrella)) and team2/*)
+
+Note that this defines the conditions to _allow_ viewing, which is opposite the
+sense of the [[plugins/lockedit]] plugin, where you define the conditions
+to _deny_ editing.
+
+If there are more than a few users in a group, or the specification for accessible
+pages is more complex, the [[plugins/contrib/pagespec_alias]] plugin
+can be useful to factor things out. Note it currently must [[be patched|plugins/contrib/pagespec_alias/discussion]]
+for this to work:
+
+    pagespec_aliases:
+      team1: >
+        user(astolfo)
+        or user(basilio)
+      team2: >
+        user(clotaldo)
+        or user(estrella)
+      team1stuff: team1/* or common/*
+      team2stuff: team2/* or common/*
+    viewable_pages: >
+      (team1() and team1stuff())
+      or (team2() and team2stuff())
+
+### mime_types config option
+
+Normally, when serving the static pages of an ordinary public site,
+the `http` server itself is responsible for identifying the `Content-Type`
+of each file. However, for any page that is served by this plugin instead
+of directly, the CGI specification makes it [plugin's job](http://tools.ietf.org/html/rfc3875#section-6.3.1),
+not the server's, to identify the `Content-Type`.
+
+In the current version, this plugin does that in a dead-simple way. For any page that ikiwiki htmlized
+(that is, for which the `pagetype` [[plugin API function|plugins/write]] returns a value),
+the type `text/html` is assigned. For anything else, a simple collection of content types and `PageSpec`s
+must be configured in the `ikiwiki.setup` file:
+
+    mime_types:
+      image/png: '*.png'
+      application/pdf: '*.pdf'
+      text/css: '*.css'
+
+Anything without a matching rule gets served as `application/octet-stream`, which is
+probably not what you want, but a clear sign of what rule needs to be added.
+
+## Other considerations
+
+### Leakage of non-content files
+
+Any CGI code that does what this plugin does, and can serve requested files under the
+document root, needs to be careful not to allow viewing of certain sensitive files
+that may also be found there, such as `.htaccess`, `.htpasswd`, etc. Instead of trying
+to think of all the possible files that should not be served, this plugin takes an
+absolutely strict approach: every requested file is looked up in the `%destsources` hash,
+containing all the files ikiwiki has generated or placed in the web root.
+Any file that _ikiwiki didn't put there_, this plugin _won't touch_. Otherwise, its page
+name is now known, and must satisfy the `viewable_pages` `PageSpec`.
+
+This policy is also what allows this plugin to work back through `%pagesources` to
+the original source name, needed for the content-type rules described above.
+
+### Cache control
+
+The purpose of a non-public zone can be defeated if there are caching proxies or
+other non-private caches that might retain the content this plugin returns.
+
+Caching of the response is automatically forbidden by the HTTP specification
+[if there was an `Authorization` header in the request](http://tools.ietf.org/html/rfc7234#section-3.2).
+However, this plugin works with any auth method ikiwiki supports, not all of which require
+that header, so this plugin always emits response headers to explicitly forbid caching.
+
+Note that nothing precludes an evil caching agent that ignores the rules.
+
+### Other ways to handle `Content-Type`
+
+While it is simple enough to supply a `mime_types` map in `ikiwiki.setup`, it also
+duplicates logic that has already been done to death in other places. Another approach
+would be to use `File::MimeInfo::Magic`, which is already present if the `filecheck`
+plugin is in use.
+
+In a wiki _compiler_, it would be natural to do that content-type determination
+at compile time and save it in page state, so this plugin would simply output
+the stored type. On the other hand, saving the type for every (non-htmlized?) page
+would enlarge the state `Storable` that has to be loaded, and so might not be
+faster than typing the file on the fly.
+
+## Obtaining and installing
+
+The `signinview` plugin is [not in github yet](https://github.com/jcflack/ikiwiki/tree/plug-signinview)
+(horroars! vaporware!). What _is_ in github at the moment is a preliminary patch I have proposed,
+giving plugins some control over the environment variables that a generated wrapper will preserve.
+
+Depending on the ultimate fate of that patch, I will adjust/rebase and then push the `signinview`
+branch itself.

more on caching behavior
diff --git a/doc/todo/Zoned_ikiwiki.mdwn b/doc/todo/Zoned_ikiwiki.mdwn
index d618aec..ee0cdfe 100644
--- a/doc/todo/Zoned_ikiwiki.mdwn
+++ b/doc/todo/Zoned_ikiwiki.mdwn
@@ -67,6 +67,12 @@ a private zone needs only a `.htaccess` file with `Deny from All` or
 `Require all denied` (or other equivalent directive for the `http` server
 in use), and a `403` error handler of `{$cgiurl}?do=view`.
 
+The plugin emits response headers intended to discourage non-private caches
+from retaining the retrieved content. (They are already supposed to avoid
+caching any response to a request with an `Authorization` header, but this
+plugin can be used with any ikiwiki-supported auth method, not all of which
+require that header.)
+
 A plugin like [[plugins/contrib/pagespec_alias]] can be very useful for
 defining a group of authorized users:
 
@@ -91,7 +97,15 @@ A plugin implementing a [FastCGI](http://www.fastcgi.com/)
 [Authorizer](http://www.fastcgi.com/drupal/node/6?q=node/22#S6.3) could provide
 the same benefits as [[plugins/contrib/signinview]] (any ikiwiki-supported auth
 method, simple zone definition with [[ikiwiki/PageSpec]]s) with less overhead
-per access.
+per access. It would also be simpler than [[plugins/contrib/signinview]] by
+leaving it as the `http` server's responsibility to generate the proper headers
+and serve the content.
+
+Caching proxies are already supposed to avoid caching any response to a request
+that included an `Authorization` header. For some ikiwiki-supported auth methods,
+that header might not be needed in the request, and care may be needed to configure
+the server to emit other necessary response headers to discourage caching of
+content from a private zone.
 
 ## Obstacles
 

make formatting more consistent
diff --git a/doc/todo/Zoned_ikiwiki.mdwn b/doc/todo/Zoned_ikiwiki.mdwn
index f7f99b2..d618aec 100644
--- a/doc/todo/Zoned_ikiwiki.mdwn
+++ b/doc/todo/Zoned_ikiwiki.mdwn
@@ -46,10 +46,11 @@ using any authentication method `ikiwiki` supports.
 
 ### View control in the `http` server
 
-* We already can more or less do this for example with [[httpauth|/plugins/httpauth/]], *.htaccess* files and a proper *httpauth_pagespec*
-yet at the cost of maintaining two different user/pass logbase (native ikiwiki signin)
-* Clunky if ikiwiki is using an authentication method not natively supported
-    in the `http` server (e.g., OpenID).
+We already can more or less do this for example with [[httpauth|/plugins/httpauth/]], `.htaccess` files and a proper `httpauth_pagespec`.
+
+_Drawbacks:_ might be fiddly to configure and require maintaining two different user/pass logbases (native ikiwiki
+signin), or impractical if ikiwiki is using an authentication method not natively supported
+in the `http` server (e.g., OpenID).
 
 ### View control in ikiwiki CGI
 

discuss zoned-ikiwiki implementation approaches, including signinview plugin
diff --git a/doc/todo/Zoned_ikiwiki.mdwn b/doc/todo/Zoned_ikiwiki.mdwn
index bd71e80..f7f99b2 100644
--- a/doc/todo/Zoned_ikiwiki.mdwn
+++ b/doc/todo/Zoned_ikiwiki.mdwn
@@ -38,11 +38,59 @@ without solutions to most or all of the **obstacles** identified here.
 
 ## Implementation techniques
 
-What is ready /can be done:
+### Edit control by user and pagespec: lockedit
+
+This works today, using the [[plugins/lockedit]] plugin. Because the `user` predicate
+can be part of a [[ikiwiki/PageSpec]], this is all we need to flexibly control edit access
+using any authentication method `ikiwiki` supports.
+
+### View control in the `http` server
 
 * We already can more or less do this for example with [[httpauth|/plugins/httpauth/]], *.htaccess* files and a proper *httpauth_pagespec*
 yet at the cost of maintaining two different user/pass logbase (native ikiwiki signin)
-* Furthermore we can [[lockedit|plugins/lockedit/]] some pagespecs, ie in the public zone.
+* Clunky if ikiwiki is using an authentication method not natively supported
+    in the `http` server (e.g., OpenID).
+
+### View control in ikiwiki CGI
+
+By requiring access to private zones to go through an ikiwiki CGI wrapper,
+any ikiwiki-supported authentication method can be used, and the accessible
+pages can be specified using the `user` predicate with [[ikiwiki/PageSpec]]s,
+just as with the [[plugins/lockedit]] plugin.
+
+The [[plugins/contrib/signinview]] plugin implements this idea, using very
+simple configuration that is possible even in shared-hosting environments
+without complete access to the `http` server configuration, as long as
+`.htaccess` files or their equivalent can be created. The top directory of
+a private zone needs only a `.htaccess` file with `Deny from All` or
+`Require all denied` (or other equivalent directive for the `http` server
+in use), and a `403` error handler of `{$cgiurl}?do=view`.
+
+A plugin like [[plugins/contrib/pagespec_alias]] can be very useful for
+defining a group of authorized users:
+
+    us: user(alice) or user(bob) or user(clotaldo)
+
+so that zone access can be a simple [[ikiwiki/PageSpec]]:
+
+    us() and ours/*
+
+*Drawbacks:* The private zones no longer reap all the benefits of a static
+wiki generator, as a (fairly heavy) ikiwiki CGI wrapper must be started for
+each access. (On the other hand, all it needs to do after confirming authorization
+is basically `cat` the statically-generated page with appropriate response headers,
+keeping the code simple and easy to audit.)
+
+This can be adequate for a case where the static, public zone could receive a lot
+of traffic, with the private zone(s) accessed only by a known small group of people.
+
+### View control with a FastCGI Authorizer
+
+A plugin implementing a [FastCGI](http://www.fastcgi.com/)
+[Authorizer](http://www.fastcgi.com/drupal/node/6?q=node/22#S6.3) could provide
+the same benefits as [[plugins/contrib/signinview]] (any ikiwiki-supported auth
+method, simple zone definition with [[ikiwiki/PageSpec]]s) with less overhead
+per access.
 
 ## Obstacles
 

it helps to distinguish some use cases
diff --git a/doc/todo/Zoned_ikiwiki.mdwn b/doc/todo/Zoned_ikiwiki.mdwn
index b2edef7..bd71e80 100644
--- a/doc/todo/Zoned_ikiwiki.mdwn
+++ b/doc/todo/Zoned_ikiwiki.mdwn
@@ -5,7 +5,38 @@
 ## The idea
 
 The idea behind this would be to have one ikiwiki behave as a dynamic private wiki in a specified area
-and a more static publiczone wiki. Actually private wiki page can be addressed via a *pagespec*. 
+and a more static publiczone wiki.
+
+## Use cases
+
+This can be more or less difficult depending on the use case.
+
+### Purely static public zone with a single, controlled-access inward zone
+
+For this case, only a known set of people are authorized to see the inward zone
+or edit anything. Everybody else sees only the public zone. This use case is mostly
+easy to handle now, as long as access to things like the `recentchanges` page and
+repository browser are not granted for the public zone. In particular, the features
+that allow information exposure via edit access are not of concern in this case.
+
+### Static public zone, more than one controlled inward zone
+
+In this case, the known, controlled set of people with special access are divided
+into groups with access to different (or overlapping) zones. The public still sees only a static zone.
+
+Here, some of the harder issues, like information disclosure via edit access, do apply,
+but only to members of the known, controlled groups. How much of a problem that is
+depends on _how sensitive_ the information is that each group might reveal from another
+zone. The rcs logs will show when a page has been edited to contain an [[ikiwiki/directive/inline]]
+directive or other trick to reveal information, so if it is enough to treat the trusted users' conduct
+as a management issue ("don't do that, please") then the risks can be acceptable in this case.
+
+### Public zone allows contribution/editing by external users
+
+This case is the most difficult to cover at present, and probably shouldn't be attempted
+without solutions to most or all of the **obstacles** identified here. 
+
+## Implementation techniques
 
 What is ready /can be done:
 

also search
diff --git a/doc/todo/Zoned_ikiwiki.mdwn b/doc/todo/Zoned_ikiwiki.mdwn
index f8c8083..b2edef7 100644
--- a/doc/todo/Zoned_ikiwiki.mdwn
+++ b/doc/todo/Zoned_ikiwiki.mdwn
@@ -129,6 +129,11 @@ The wrapper could probably import it and use its already-supplied routines to pa
 the request into the affected file names, and probably complete the whole request
 without a second `exec`. Other rcs backends might or might not be as easy.
 
+### Search
+
+If [[plugins/search]] is enabled, private content is indexed and
+searchable to the public.
+
 ### Information leaks allowed by edit access
 
 > Have you considered all the ways that anyone with edit access to the

start fleshing out "things that make zoned ikiwiki hard"
diff --git a/doc/todo/Zoned_ikiwiki.mdwn b/doc/todo/Zoned_ikiwiki.mdwn
index 26260b2..f8c8083 100644
--- a/doc/todo/Zoned_ikiwiki.mdwn
+++ b/doc/todo/Zoned_ikiwiki.mdwn
@@ -1,3 +1,9 @@
+[[!toc levels=3]]
+
+# Zoned ikiwiki
+
+## The idea
+
 The idea behind this would be to have one ikiwiki behave as a dynamic private wiki in a specified area
 and a more static publiczone wiki. Actually private wiki page can be addressed via a *pagespec*. 
 
@@ -7,18 +13,31 @@ What is ready /can be done:
 yet at the cost of maintaining two different user/pass logbase (native ikiwiki signin)
 * Furthermore we can [[lockedit|plugins/lockedit/]] some pagespecs, ie in the public zone.
 
+## Obstacles
+
+A number of ikiwiki features aren't (yet) designed with zoning in mind,
+and it will take some effort both to identify them all, and to think out how they
+could be addressed. This section invites brainstorming of both kinds.
+This might eventually merit a separate page [[Zoned ikiwiki obstacles]]
+but I'll begin it here.
+
+Note that not all of these issues will be problems for all **zoned ikiwiki use cases**.
+
+### Backlinks
+
 What is problematic is when you link a public page in a private page : 
 a backlink will be generated from the public page to the private page.
 
-As I noticed in [[per_page_ACLs]] in the end users through backlink 
+As noted in [[per_page_ACLs]] in the end users through backlink 
 navigation will frequently hit HTTP/401 deterring browsing as well as for the admin at false-positive logwatching.
 
 One can radically [[disable backlinks feature|todo/allow_disabling_backlinks]] but then no more neat backlink navigation that
 is really good to have in both area.
 
-I think of just preventing this backlink leak in that case would be sufficient via i.e a *privatebacklinks* config and
-a below patch.
+Another way of just preventing this backlink leak in that case would be sufficient via i.e a *privatebacklinks* config and
+a patch like this one [[!toggle id="backlinkpatch" text="(show)"]].
 
+[[!toggleable id="backlinkpatch" text="""
 Comments are welcome.
 
 [[mathdesc]]
@@ -58,7 +77,75 @@ diff --git a/IkiWiki/Render.pm b/IkiWiki/Render.pm
  }
 
 </pre>
+"""]]
+
+In use cases where the main concern about backlinks is only the bad user experience when links are
+shown that lead to access denial when clicked, a workable
+solution could be to make the backlinks `div` invisible in `local.css`.
+
+### recentchanges page
+
+An accessible `recentchanges` page can include links to changes to pages
+that should not be accessible. Even if the links cannot be followed, the
+existence of the pages and their edit history are leaked. If rcs integration
+is configured, those links on the `recentchanges` page can leak complete contents
+through the **rcs browser**.
+
+It can be helpful to generate separate `recentchanges` pages for different zones.
+The [[plugins/recentchanges]] plugin already allows this--a `recentchanges` page
+can be created anywhere, just by using the `recentchanges` directive
+with the right [[ikiwiki/PageSpec]] for the zone it should cover--except that it cannot yet
+be configured to generate a different `recentchanges` link destination into pages
+in different zones. So, it would be helpful if its configuration could allow multiple
+`recentchangespage` values, paired with `PageSpec`s for the pages on which they
+should be used.
+
+### rcs browser
+
+If the repository browser is accessible, potentially all content can be exposed.
+Even if links to the repository browser are not generated into public wiki pages,
+if a user can obtain or guess the repository browser URL and construct arbitrary
+requests, information can be revealed.
+
+Solutions could involve authnz features of the revision control systems themselves
+and their associated repository browsers; for example, `svn` supposedly has such
+features, and recent versions of `viewvc` supposedly honor them. But such features
+may not be available for every rcs, and where they are available, they'll have to
+be configured separately and differently from ikiwiki itself. They might not support
+the same auth methods (e.g. OpenID) being used by the wiki itself.
+
+Another approach would be for ikiwiki's own rcs plugin to generate a CGI wrapper
+that invokes the repository browser CGI (which itself would _not_ be made
+executable via `http` request). The `historyurl` and `diffurl` would then refer
+to this wrapper. (In fact, they would not have to be specified in the config file,
+as the plugin would know where it generated them. Instead, what would need to be
+specified would be the filesystem path for the rcs browser being wrapped). The
+wrapper could dissect the request parameters, identify the pages being accessed,
+and subject them to the same accessibility tests used for the wiki. The rcs browser
+itself needs to be configured to use the wrapper URL in all its generated links,
+
+This might not be very hard to do with `gitweb` as it is already implemented in Perl.
+The wrapper could probably import it and use its already-supplied routines to parse
+the request into the affected file names, and probably complete the whole request
+without a second `exec`. Other rcs backends might or might not be as easy.
+
+### Information leaks allowed by edit access
 
 > Have you considered all the ways that anyone with edit access to the
 > public wiki could expose information from the public wiki? For example,
-> you could inline all the private pages into a public page. --[[Joey]] 
+> you could inline all the private pages into a public page. --[[Joey]]
+
+Many ikiwiki features could give information exposure opportunities to someone
+with edit access. The list here is surely incomplete, and would take a purposeful
+review of the code and plugins (including third-party plugins) to complete.
+
+* Directives that can inline information from other pages
+    * [[ikiwiki/directive/inline]] *the most obvious one*
+    * [[ikiwiki/directive/map]]
+    * [[ikiwiki/directive/brokenlinks]] ?
+    * [[ikiwiki/directive/orphans]] ?
+    * [[ikiwiki/directive/linkmap]] ?
+    * _others_?
+* Not to forget `contrib` plugins
+    * [[plugins/contrib/report]] ?
+    * _others_?

sign previous
diff --git a/doc/bugs/double_shebang_replacement___47__usr__47__bin__47__perl5.185.18.mdwn b/doc/bugs/double_shebang_replacement___47__usr__47__bin__47__perl5.185.18.mdwn
index 9f08f26..63dcae8 100644
--- a/doc/bugs/double_shebang_replacement___47__usr__47__bin__47__perl5.185.18.mdwn
+++ b/doc/bugs/double_shebang_replacement___47__usr__47__bin__47__perl5.185.18.mdwn
@@ -39,4 +39,4 @@ index 61fe336..2d54658 100755
 
 [[Done]], but this word-boundary construct didn't work on at least
 one of my systems, so now we're using `$(PERL)` to do the job
-portably.
+portably. --[[schmonz]]

Match word boundary (think "/usr/bin/perl5.18").
diff --git a/Makefile.PL b/Makefile.PL
index 61fe336..312a148 100755
--- a/Makefile.PL
+++ b/Makefile.PL
@@ -63,7 +63,7 @@ docwiki:
 perl_shebangs:
 ifneq "$(PERL)" "/usr/bin/perl"
 	for file in $(shebang_scripts); do \
-		$(SED) -e "1s|^#!/usr/bin/perl|#!$(PERL)|" < $$file > "$$file.new"; \
+		$(PERL) -pe "s|^#!/usr/bin/perl\b|#!$(PERL)| if 1" < $$file > "$$file.new"; \
 		[ -x $$file ] && chmod +x "$$file.new"; \
 		mv -f "$$file.new" $$file; \
 	done
@@ -72,7 +72,7 @@ endif
 perl_shebangs_clean:
 ifneq "$(PERL)" "/usr/bin/perl"
 	for file in $(shebang_scripts); do \
-		$(SED) -e "1s|^#!$(PERL)|#!/usr/bin/perl|" < $$file > "$$file.new"; \
+		$(PERL) -pe "s|^#!$(PERL)\b|#!/usr/bin/perl| if 1" < $$file > "$$file.new"; \
 		[ -x $$file ] && chmod +x "$$file.new"; \
 		mv -f "$$file.new" $$file; \
 	done
diff --git a/doc/bugs/double_shebang_replacement___47__usr__47__bin__47__perl5.185.18.mdwn b/doc/bugs/double_shebang_replacement___47__usr__47__bin__47__perl5.185.18.mdwn
index 9bccdf0..9f08f26 100644
--- a/doc/bugs/double_shebang_replacement___47__usr__47__bin__47__perl5.185.18.mdwn
+++ b/doc/bugs/double_shebang_replacement___47__usr__47__bin__47__perl5.185.18.mdwn
@@ -1,4 +1,4 @@
-Please consider this [patch] for merging in.
+Please consider this [[patch]] for merging in.
 [[!format  diff """
 From e697ba4ef7952ce549d449c4e4daea2e3f0a1aa7 Mon Sep 17 00:00:00 2001
 From: Nikolay Orlyuk <virkony@gmail.com>
@@ -36,3 +36,7 @@ index 61fe336..2d54658 100755
 -- 
 2.1.2
 """]]
+
+[[Done]], but this word-boundary construct didn't work on at least
+one of my systems, so now we're using `$(PERL)` to do the job
+portably.

diff --git a/doc/bugs/double_shebang_replacement___47__usr__47__bin__47__perl5.185.18.mdwn b/doc/bugs/double_shebang_replacement___47__usr__47__bin__47__perl5.185.18.mdwn
index 6c7039d..9bccdf0 100644
--- a/doc/bugs/double_shebang_replacement___47__usr__47__bin__47__perl5.185.18.mdwn
+++ b/doc/bugs/double_shebang_replacement___47__usr__47__bin__47__perl5.185.18.mdwn
@@ -36,4 +36,3 @@ index 61fe336..2d54658 100755
 -- 
 2.1.2
 """]]
-

[patch], patch
diff --git a/doc/bugs/double_shebang_replacement___47__usr__47__bin__47__perl5.185.18.mdwn b/doc/bugs/double_shebang_replacement___47__usr__47__bin__47__perl5.185.18.mdwn
new file mode 100644
index 0000000..6c7039d
--- /dev/null
+++ b/doc/bugs/double_shebang_replacement___47__usr__47__bin__47__perl5.185.18.mdwn
@@ -0,0 +1,39 @@
+Please consider this [patch] for merging in.
+[[!format  diff """
+From e697ba4ef7952ce549d449c4e4daea2e3f0a1aa7 Mon Sep 17 00:00:00 2001
+From: Nikolay Orlyuk <virkony@gmail.com>
+Date: Sun, 19 Oct 2014 18:46:34 +0300
+Subject: [PATCH] fix shebang paths manipulations
+
+Small enhancements for 67e778f4 to avoid erroneous she-bangs
+"/usr/bin/perl5.185.18" (version suffix added twice).
+---
+ Makefile.PL | 4 ++--
+ 1 file changed, 2 insertions(+), 2 deletions(-)
+
+diff --git a/Makefile.PL b/Makefile.PL
+index 61fe336..2d54658 100755
+--- a/Makefile.PL
++++ b/Makefile.PL
+@@ -63,7 +63,7 @@ docwiki:
+ perl_shebangs:
+ ifneq "$(PERL)" "/usr/bin/perl"
+ 	for file in $(shebang_scripts); do \
+-		$(SED) -e "1s|^#!/usr/bin/perl|#!$(PERL)|" < $$file > "$$file.new"; \
++		$(SED) -e "1s|^#!/usr/bin/perl\>|#!$(PERL)|" < $$file > "$$file.new"; \
+ 		[ -x $$file ] && chmod +x "$$file.new"; \
+ 		mv -f "$$file.new" $$file; \
+ 	done
+@@ -72,7 +72,7 @@ endif
+ perl_shebangs_clean:
+ ifneq "$(PERL)" "/usr/bin/perl"
+ 	for file in $(shebang_scripts); do \
+-		$(SED) -e "1s|^#!$(PERL)|#!/usr/bin/perl|" < $$file > "$$file.new"; \
++		$(SED) -e "1s|^#!$(PERL)\>|#!/usr/bin/perl|" < $$file > "$$file.new"; \
+ 		[ -x $$file ] && chmod +x "$$file.new"; \
+ 		mv -f "$$file.new" $$file; \
+ 	done
+-- 
+2.1.2
+"""]]
+

Added a comment
diff --git a/doc/forum/Encoding_problems_when_editing_through_browser/comment_2_3c0117b78a9e053ed893816222fd908a._comment b/doc/forum/Encoding_problems_when_editing_through_browser/comment_2_3c0117b78a9e053ed893816222fd908a._comment
new file mode 100644
index 0000000..62f6f5e
--- /dev/null
+++ b/doc/forum/Encoding_problems_when_editing_through_browser/comment_2_3c0117b78a9e053ed893816222fd908a._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="openmedi"
+ ip="91.65.196.164"
+ subject="comment 2"
+ date="2014-10-17T17:23:12Z"
+ content="""
+I just tested replacing my ikiwiki install with a new one (tar from today) and still get the same error. I read up on the links you provided, but it seems to me that I can't really do anything with that info (other than updating my ikiwiki that is…). Any other ideas?
+"""]]

reformat
diff --git a/doc/news/version_3.20141016.mdwn b/doc/news/version_3.20141016.mdwn
index 3a93102..dd7f810 100644
--- a/doc/news/version_3.20141016.mdwn
+++ b/doc/news/version_3.20141016.mdwn
@@ -1,10 +1,12 @@
 ikiwiki 3.20141016 released with [[!toggle text="these changes"]]
 [[!toggleable text="""
-  [ Joey Hess ]
+[ Joey Hess ]
+
   * Fix crash that can occur when only_committed_changes is set and a
     file is deleted from the underlay.
 
-  [ Simon McVittie ]
+[ Simon McVittie ]
+
   * core: avoid dangerous use of CGI->param in list context, which led
     to a security flaw in Bugzilla; as far as we can tell, ikiwiki
     is not vulnerable to a similar attack, but it's best to be safe

news
diff --git a/doc/news/version_3.20140227.mdwn b/doc/news/version_3.20140227.mdwn
deleted file mode 100644
index e5f0154..0000000
--- a/doc/news/version_3.20140227.mdwn
+++ /dev/null
@@ -1,27 +0,0 @@
-ikiwiki 3.20140227 released with [[!toggle text="these changes"]]
-[[!toggleable text="""
-   * Added useragent config setting. Closes: #[737121](http://bugs.debian.org/737121)
-     Thanks, Tuomas Jormola
-   * po: Add html\_lang\_code and html\_lang\_dir template variables
-     for the language code and direction of text.
-     Thanks, Mesar Hameed
-   * Allow up to 8 levels of nested directives, rather than previous 3
-     in directive infinite loop guard.
-   * git diffurl: Do not escape / in paths to changed files, in order to
-     interoperate with cgit (gitweb works either way)
-     Thanks, intrigeri.
-   * git: Explicity push master branch, as will be needed by git 2.0's
-     change to push.default=matching by default.
-     Thanks, smcv
-   * Deal with nasty issue with gettext clobbering $@ while printing
-     error message containing it.
-     Thanks, smcv
-   * Cleanup of the openid login widget, including replacing of hotlinked
-     images from openid providers with embedded, freely licensed artwork.
-     Thanks, smcv
-   * Improve templates testing.
-     Thanks, smcv
-   * python proxy: Avoid utf-8 related crash.
-     Thanks, Antoine Beaupré
-   * Special thanks to Simon McVittie for being the patchmeister for this
-     release."""]]
\ No newline at end of file
diff --git a/doc/news/version_3.20141016.mdwn b/doc/news/version_3.20141016.mdwn
new file mode 100644
index 0000000..3a93102
--- /dev/null
+++ b/doc/news/version_3.20141016.mdwn
@@ -0,0 +1,36 @@
+ikiwiki 3.20141016 released with [[!toggle text="these changes"]]
+[[!toggleable text="""
+  [ Joey Hess ]
+  * Fix crash that can occur when only_committed_changes is set and a
+    file is deleted from the underlay.
+
+  [ Simon McVittie ]
+  * core: avoid dangerous use of CGI->param in list context, which led
+    to a security flaw in Bugzilla; as far as we can tell, ikiwiki
+    is not vulnerable to a similar attack, but it's best to be safe
+  * core: new reverse_proxy option prevents ikiwiki from trying to detect
+    how to make self-referential URLs by using the CGI environment variables,
+    for instance when it's deployed behind a HTTP reverse proxy
+    (Closes: [[!debbug 745759]])
+  * core: the default User-Agent is now "ikiwiki/$version" to work around
+    ModSecurity rules assuming that only malware uses libwww-perl
+  * core: use protocol-relative URLs (e.g. //www.example.com/wiki) so that
+    https stays on https and http stays on http, particularly if the
+    html5 option is enabled
+  * core: avoid mixed content when a https cgiurl links to http static pages
+    on the same server (the static pages are assumed to be accessible via
+    https too)
+  * core: force the correct top URL in w3mmode
+  * google plugin: Use search form
+  * docwiki: replace Paypal and Flattr buttons with text links
+  * comments: don't record the IP address in the wiki if the user is
+    logged in via passwordauth or httpauth
+  * templates: add ARIA roles to some page elements, if html5 is enabled.
+    Thanks, Patrick
+  * debian: build-depend on libmagickcore-6.q16-2-extra | libmagickcore-extra
+    so we can thumbnail SVGs in the docwiki
+  * debian: explicitly depend and build-depend on libcgi-pm-perl
+  * debian: drop unused python-support dependency
+  * debian: rename debian/link to debian/links so the intended symlinks appear
+  * debian: fix some wrong paths in the copyright file
+"""]]

Added a comment: It was an Apache problem...
diff --git a/doc/forum/HTTPS_edit_required_no_authentication/comment_4_d60d5184412d6ecd8aae44cd33653e89._comment b/doc/forum/HTTPS_edit_required_no_authentication/comment_4_d60d5184412d6ecd8aae44cd33653e89._comment
new file mode 100644
index 0000000..6c0a770
--- /dev/null
+++ b/doc/forum/HTTPS_edit_required_no_authentication/comment_4_d60d5184412d6ecd8aae44cd33653e89._comment
@@ -0,0 +1,23 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawk8U772S3jDrZJCO0WA5WaDLjJv5mMl6Yw"
+ nickname="Nadine"
+ subject="It was an Apache problem..."
+ date="2014-10-16T14:57:26Z"
+ content="""
+Hello,
+
+thank you for your comments. The problem comes from the Apache configuration. I use a git-http-backend on this server and I affect the content of the REMOTE_USER environment variable like this:
+
+    SetEnv REMOTE_USER=$REDIRECT_REMOVE_USER
+
+Ikiwiki CGI seems to use this variable to determine which is the current user. Even if the variable content is NULL, ikiwiki.cgi use it.
+
+I just changed this to:
+
+    SetEnvIf Request_URI \"^/git/\" REMOTE_USER=$REDIRECT_REMOVE_USER
+
+and everything runs Ok now...
+
+Sorry for bothering Ikiwikiboard with an HTTP server problem.
+
+"""]]

branch
diff --git a/doc/todo/generate_HTML5_by_default.mdwn b/doc/todo/generate_HTML5_by_default.mdwn
index 59726bf..f8d598c 100644
--- a/doc/todo/generate_HTML5_by_default.mdwn
+++ b/doc/todo/generate_HTML5_by_default.mdwn
@@ -2,10 +2,11 @@ The `html5` option was added in 2010 and marked as "not experimental" in 2011
 but is not the default.
 
 According to <http://caniuse.com/#feat=html5semantic>, current versions of
-all recent versions of all major browsers - even IE - support the HTML5
+all recent versions of all major browsers - even IE (9+) - support the HTML5
 semantic elements (`<section>` etc.), except for `<main>` which IkiWiki
-doesn't use anyway. With that being the case, I'm not sure whether we gain
-anything from not generating HTML5 (or "HTML" as it's now labelled) all the time.
+doesn't use anyway. However, IE 8 is not a current version, but has ~ 4%
+market share and doesn't support `<section>` and friends; so there's still
+a compatibility concern there.
 
 In particular, non-HTML5 mode uses `<!DOCTYPE html PUBLIC
 "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">`
@@ -22,21 +23,39 @@ In practice, real browsers have never actually implemented a strict XHTML mode:
 they've always parsed `text/html` as "tag soup", because they need a tag-soup
 parser anyway, and nobody wants to maintain two parsers.
 
+Kai also wants a HTML5 doctype for [[bugs/more mobile friendly default themes]].
+
 Options include:
 
-* set html5 to 1 by default but retain the dual-mode templates
+* set html5 to 1 by default but retain the dual-mode templates,
+  breaking IE 8 by default
+
 * remove the option and always behave as if it had been 1, simplifying
-  the templates
+  the templates and breaking IE 8 unconditionally
 
-Thoughts?
+* either of the above and include
+  [html5shiv](https://code.google.com/p/html5shiv/) to de-break IE 8
 
---[[smcv]]
+* change the doctype to `<!DOCTYPE html>`
+  unconditionally, stop trying to limit ourselves to XHTML 1.0 Strict
+  (use HTML5 features that degrade gracefully, like
+  [[ARIA roles|todo/add aria landmarks to make ikiwiki websites more accessible]]),
+  but avoid using the new elements like `<section>` that require specific
+  browser support unless `html5` is set to 1. That would get rid of the
+  backwards-compatibility concerns while keeping the ability to use
+  post-2000 markup; we can use `html5` to mean "be more enthusiastic about
+  HTML5 features even if they might fail on older browsers".
+
+Using the HTML5 doctype does mean we lose the ability to validate the output
+against a DTD (as `wdg-html-validator` does), but DTDs have very little to
+do with practical browser compatibility in any case.
 
-> Another possibility would be to change the doctype to `<!DOCTYPE html>`
-> unconditionally, stop trying to limit ourselves to XHTML 1.0 Strict
-> (use HTML5 features that degrade gracefully, like
-> [[ARIA roles|todo/add aria landmarks to make ikiwiki websites more accessible]]),
-> but avoid using the new elements like `<section>` that require specific
-> browser support unless `html5` is set to 1. That would get rid of the
-> backwards-compatibility concerns while keeping the ability to use
-> post-2000 markup. --[[smcv]]
+[[!template id=gitbranch branch=smcv/ready/html5
+author="[[Simon McVittie|smcv]]"
+browse=http://git.pseudorandom.co.uk/smcv/ikiwiki.git/shortlog/refs/heads/ready/html5]]
+[[!tag patch users/smcv/ready]]
+
+At the moment my preferred option is the last, for which see my `ready/html5`
+branch. I'll apply this at some point if there are no objections.
+
+--[[smcv]]

comment
diff --git a/doc/bugs/More_mobile_friendly_default_themes.mdwn b/doc/bugs/More_mobile_friendly_default_themes.mdwn
index c33d6ac..fa25814 100644
--- a/doc/bugs/More_mobile_friendly_default_themes.mdwn
+++ b/doc/bugs/More_mobile_friendly_default_themes.mdwn
@@ -4,12 +4,31 @@ indicates the viewport on mobile needs to be configured, e.g. `<meta name=viewpo
 
 http://source.ikiwiki.branchable.com/?p=source.git;a=blob;f=templates/page.tmpl;
 
+> This seems a lot like
+> [an "unbreak my application" option](http://ometer.com/free-software-ui.html)
+> but OK... presumably the motivation for this being opt-in is that "most"
+> websites have some sort of hard-coded fixed-width layout suitable for
+> a proportion of desktop browsers, rather than being responsive to window
+> size like they should have been all along. --[[smcv]]
 
 Further more:
 
-
 * fonts need to be tweaked
+
+  > Suggestions?
+  >
+  > (Note that Joey has generally rejected stylistic changes to the default
+  > anti-theme; enhancing the other themes would be OK though.)
+  > --[[smcv]]
+
 * XHTML should be dropped !
 
+  > Already in the to-do list: [[todo/generate HTML5 by default]]. --[[smcv]]
 
 I'm practicing this on http://dabase.com/ with <http://source.dabase.branchable.com/?p=source.git;a=blob;f=templates/page.tmpl;>
+
+> [[!format diff """
+-<TMPL_IF FORCEBASEURL><base href="<TMPL_VAR FORCEBASEURL>" /><TMPL_ELSE>
+-<TMPL_IF BASEURL><base href="<TMPL_VAR BASEURL>" /></TMPL_IF>
+"""]]
+> You probably don't want to delete those. It breaks the CGI. --[[smcv]]

mention pagespec_alias patches
diff --git a/doc/plugins/contrib/pagespec_alias/discussion.mdwn b/doc/plugins/contrib/pagespec_alias/discussion.mdwn
new file mode 100644
index 0000000..fe0e1e1
--- /dev/null
+++ b/doc/plugins/contrib/pagespec_alias/discussion.mdwn
@@ -0,0 +1,14 @@
+I've submitted a couple of patches in [this pull request](https://github.com/jmtd/ikiwiki/pull/1).
+The first passes along whatever parameters are being supplied to the pagespec evaluation
+(without which, specs like `user(alice)` don't work).
+
+The second changes the "example" returned by `getsetup` to be an actual map, since I saw
+that `--dumpsetup` can make use of that to produce a syntactically correct map example
+in the YAML config file. An earlier commit comment suggested that once was a problem,
+but it doesn't seem to be one now.
+
+Only later did I notice this [[earlier discussion|todo/pagespec_aliases]] suggesting
+that the problem with a map might have been in websetup - which I'm not using, so I don't
+know if it would still be a problem there.
+
+[[jcflack]]

Added a comment
diff --git a/doc/forum/HTTPS_edit_required_no_authentication/comment_3_7e202a8c9a741a19e391b0594d028986._comment b/doc/forum/HTTPS_edit_required_no_authentication/comment_3_7e202a8c9a741a19e391b0594d028986._comment
new file mode 100644
index 0000000..dfe3f56
--- /dev/null
+++ b/doc/forum/HTTPS_edit_required_no_authentication/comment_3_7e202a8c9a741a19e391b0594d028986._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="smcv"
+ ip="81.100.115.242"
+ subject="comment 3"
+ date="2014-10-15T23:30:21Z"
+ content="""
+It might also be interesting to visit your wiki's preferences page
+(`ikiwiki.cgi?do=prefs`) which should tell you who you are logged-in as.
+If you \"view source\" it will also show you your session ID, which should match
+what's in the `ikiwiki_session_something` cookie.
+"""]]

Added a comment
diff --git a/doc/forum/HTTPS_edit_required_no_authentication/comment_2_386b0d5bd2bc8478bad19ce1da2bd8bc._comment b/doc/forum/HTTPS_edit_required_no_authentication/comment_2_386b0d5bd2bc8478bad19ce1da2bd8bc._comment
new file mode 100644
index 0000000..8e8f2e5
--- /dev/null
+++ b/doc/forum/HTTPS_edit_required_no_authentication/comment_2_386b0d5bd2bc8478bad19ce1da2bd8bc._comment
@@ -0,0 +1,15 @@
+[[!comment format=mdwn
+ username="smcv"
+ ip="81.100.115.242"
+ subject="comment 2"
+ date="2014-10-15T23:26:52Z"
+ content="""
+I can't reproduce this either.
+
+Do you perhaps still have an ikiwiki login session cookie stored in your browser
+from when you previously used passwordauth or openid?
+(In Firefox: Edit->Preferences, Privacy tab, Show Cookies.)
+
+The login sessions that are considered to be valid are stored in `.ikiwiki/sessions.db`
+in your wiki's `srcdir`.
+"""]]

Replace PayPal and Flattr buttons with text links
In particular, this avoids loading third-party resources from the
offline documentation (see
<https://lintian.debian.org/tags/privacy-breach-donation.html>).
diff --git a/debian/upstream/metadata b/debian/upstream/metadata
new file mode 100644
index 0000000..1041dfa
--- /dev/null
+++ b/debian/upstream/metadata
@@ -0,0 +1,5 @@
+Name: ikiwiki
+Bug-Database: http://ikiwiki.info/bugs/
+Bug-Submit: http://ikiwiki.info/bugs/
+Changelog: http://ikiwiki.info/news/
+Donation: http://ikiwiki.info/tipjar/
diff --git a/doc/templates/links.mdwn b/doc/templates/links.mdwn
index 4bd1a85..27f81e6 100644
--- a/doc/templates/links.mdwn
+++ b/doc/templates/links.mdwn
@@ -9,8 +9,6 @@
 <li>[[SiteMap]]</li>
 <li>[[Contact]]</li>
 <li>[[TipJar]]</li>
+<li><a href="http://flattr.com/thing/39811/ikiwiki">Flattr ikiwiki</a></li>
 </ul>
-<a href="http://flattr.com/thing/39811/ikiwiki">
-<img src="https://api.flattr.com/button/flattr-badge-large.png"
-alt="Flattr this" title="Flattr this" /></a>
 </div>
diff --git a/doc/tipjar.mdwn b/doc/tipjar.mdwn
index 6d65a0a..80d8f5c 100644
--- a/doc/tipjar.mdwn
+++ b/doc/tipjar.mdwn
@@ -3,10 +3,8 @@ to [[Joey]] or help offset hosting costs with a donation in any amount you
 choose. If you'd like to fund development of a specific feature, see the
 [[consultants]] page.
 
-<a href="https://www.paypal.com/cgi-bin/webscr?cmd=_xclick&business=joey%40kitenet%2enet&item_name=ikiwiki&no_shipping=1&cn=Comments%3f&tax=0&currency_code=USD&lc=US&bn=PP%2dDonationsBF&charset=UTF%2d8"><img src="https://www.paypal.com/en_US/i/btn/x-click-but04.gif" alt="donate with PayPal" /></a>
-
-<script type="text/javascript">var flattr_url = 'http://ikiwiki.info';</script>
-<script src="http://api.flattr.com/button/load.js" type="text/javascript"></script>
+* [Donate with PayPal](https://www.paypal.com/cgi-bin/webscr?cmd=_xclick&business=joey%40kitenet%2enet&item_name=ikiwiki&no_shipping=1&cn=Comments%3f&tax=0&currency_code=USD&lc=US&bn=PP%2dDonationsBF&charset=UTF%2d8)
+* [Donate with Flattr](http://flattr.com/thing/39811/ikiwiki)
 
 Thanks to the following people for their kind contributions:
 
@@ -21,5 +19,5 @@ Thanks to the following people for their kind contributions:
 * Amitai Schlair
 * Luca Capello
 
-(Note that this page is locked to prevent anyone from tampering with the PayPal button.
+(Note that this page is locked to prevent anyone from tampering with the PayPal link.
 If you prefer your donation *not* be listed here, let [[Joey]] know.)

Added a comment
diff --git a/doc/forum/Can_someone_add_Ikiwiki_in_Homebrew__63__/comment_4_cfb3244a5f957065b0a932221ebecac4._comment b/doc/forum/Can_someone_add_Ikiwiki_in_Homebrew__63__/comment_4_cfb3244a5f957065b0a932221ebecac4._comment
new file mode 100644
index 0000000..71b2d0c
--- /dev/null
+++ b/doc/forum/Can_someone_add_Ikiwiki_in_Homebrew__63__/comment_4_cfb3244a5f957065b0a932221ebecac4._comment
@@ -0,0 +1,14 @@
+[[!comment format=mdwn
+ username="openmedi"
+ ip="91.65.196.164"
+ subject="comment 4"
+ date="2014-10-15T18:49:16Z"
+ content="""
+I asked the homebrew people on freenode. Here's what I got: 
+
+My Question: (Hopefully) quick question: There has been an interest in having a brew formula for the static wiki generator ikiwiki (see http://ikiwiki.info/forum/Can_someone_add_Ikiwiki_in_Homebrew__63__/) in 2011 a pull request for that (https://github.com/Homebrew/homebrew/pull/5358) was closed due to too many perl dependencies. It was suggestet, that one uses homebrew-alt instead. Since homebrew-alt doesn’t seem to exist (anymore), I was curious what one can do to move this request forward.
+
+Answer: You can always host a formula yourself without having it accepted into homebrew core, using the tap mechanism. We have some formulas for packages written in Python where we explicitly fetch and install the dependencies into the parent formula's prefix; check out ansible.rb for an example. If you can do something like that for ikiwiki's dependencies, that would probably go through.
+
+I'll look into it, but have to admit, that I have very little time right now (and am also not sure, if I am able to produce a working brew formula…). But maybe somebody else now has enough info to get startet.
+"""]]

Added a comment
diff --git a/doc/forum/Can_someone_add_Ikiwiki_in_Homebrew__63__/comment_3_e05c4318cc70419feb5c83be16332109._comment b/doc/forum/Can_someone_add_Ikiwiki_in_Homebrew__63__/comment_3_e05c4318cc70419feb5c83be16332109._comment
new file mode 100644
index 0000000..8afb2b0
--- /dev/null
+++ b/doc/forum/Can_someone_add_Ikiwiki_in_Homebrew__63__/comment_3_e05c4318cc70419feb5c83be16332109._comment
@@ -0,0 +1,15 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawlcaGfdn9Kye1Gc8aGb67PDVQW4mKbQD7E"
+ nickname="Amitai"
+ subject="comment 3"
+ date="2014-10-15T13:43:24Z"
+ content="""
+Maybe someone reading this is able to act on your request. In case that's not true, I'd suggest investigating a few questions on the Homebrew side of things:
+
+7. From Homebrew's 2011 point of view, why did flangy consider [\"large number of perl dependencies\"](https://github.com/Homebrew/homebrew/pull/5358) to be a basis for rejection?
+7. From Homebrew's 2014 point of view, is that rationale still considered valid?
+7. If so, then does Homebrew make it easy for users to install formulae from repositories other than the official one?
+7. If so, then is there an existing non-official repository that either contains an ikiwiki formula or would be willing to accept one?
+
+Since I already use pkgsrc for all my packages (not only ikiwiki) on all my systems (not only OS X), I'm unmotivated to pursue this line of inquiry for possibly zero benefit. If you're already invested in Homebrew, and happy about it, then perhaps it's worth it to you to get this figured out.
+"""]]

Added a comment
diff --git a/doc/forum/Can_someone_add_Ikiwiki_in_Homebrew__63__/comment_2_23c2da35be13aeda49c8e3e61bc4cc91._comment b/doc/forum/Can_someone_add_Ikiwiki_in_Homebrew__63__/comment_2_23c2da35be13aeda49c8e3e61bc4cc91._comment
new file mode 100644
index 0000000..4295461
--- /dev/null
+++ b/doc/forum/Can_someone_add_Ikiwiki_in_Homebrew__63__/comment_2_23c2da35be13aeda49c8e3e61bc4cc91._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="openmedi"
+ ip="91.65.196.164"
+ subject="comment 2"
+ date="2014-10-15T12:33:28Z"
+ content="""
+I second that request. Although it is possible to install ikiwiki like amitai suggests, it would be a great convenience to be able to just \"brew install ikiwiki\".
+"""]]

diff --git a/doc/bugs/More_mobile_friendly_default_themes.mdwn b/doc/bugs/More_mobile_friendly_default_themes.mdwn
new file mode 100644
index 0000000..c33d6ac
--- /dev/null
+++ b/doc/bugs/More_mobile_friendly_default_themes.mdwn
@@ -0,0 +1,15 @@
+<http://developers.google.com/speed/pagespeed/insights/>
+
+indicates the viewport on mobile needs to be configured, e.g. `<meta name=viewport content="width=device-width, initial-scale=1">` in the header of
+
+http://source.ikiwiki.branchable.com/?p=source.git;a=blob;f=templates/page.tmpl;
+
+
+Further more:
+
+
+* fonts need to be tweaked
+* XHTML should be dropped !
+
+
+I'm practicing this on http://dabase.com/ with <http://source.dabase.branchable.com/?p=source.git;a=blob;f=templates/page.tmpl;>

as usual, macports hasn't moved
diff --git a/doc/tips/ikiwiki_on_mac_os_x.mdwn b/doc/tips/ikiwiki_on_mac_os_x.mdwn
index b36bb6a..86b2ac0 100644
--- a/doc/tips/ikiwiki_on_mac_os_x.mdwn
+++ b/doc/tips/ikiwiki_on_mac_os_x.mdwn
@@ -14,7 +14,7 @@ The easiest way of installing an up-to-date ikiwiki on any version of Mac OS X i
 
 7. [install binary packages (OSX)](http://www.pkgsrc.org/#index1h1)
 
-{OK} As of 2014/08/24, the [version of ikiwiki in pkgsrc](http://pkgsrc.se/www/ikiwiki) is 3.20140815.
+{OK} As of 2014/10/14, the [version of ikiwiki in pkgsrc](http://pkgsrc.se/www/ikiwiki) is 3.20140916.
 
 -----
 
@@ -39,7 +39,7 @@ enjoy
 
 Enrique Castilla
 
-[!] As of 2014/08/24, the [version of ikiwiki in MacPorts](http://www.macports.org/ports.php?by=name&substr=Ikiwiki) is 3.20110608.
+[!] As of 2014/10/14, the [version of ikiwiki in MacPorts](http://www.macports.org/ports.php?by=name&substr=Ikiwiki) is 3.20110608.
 
 -----
 

Added a comment
diff --git a/doc/forum/Can_someone_add_Ikiwiki_in_Homebrew__63__/comment_1_46f10540899505a36a734ab6eef6ea54._comment b/doc/forum/Can_someone_add_Ikiwiki_in_Homebrew__63__/comment_1_46f10540899505a36a734ab6eef6ea54._comment
new file mode 100644
index 0000000..3c41307
--- /dev/null
+++ b/doc/forum/Can_someone_add_Ikiwiki_in_Homebrew__63__/comment_1_46f10540899505a36a734ab6eef6ea54._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawlcaGfdn9Kye1Gc8aGb67PDVQW4mKbQD7E"
+ nickname="Amitai"
+ subject="comment 1"
+ date="2014-10-14T22:41:59Z"
+ content="""
+I don't use Homebrew and can't speak for it, but have you tried the suggestion in [[tips/ikiwiki on mac os x]]?
+"""]]

diff --git a/doc/forum/Can_someone_add_Ikiwiki_in_Homebrew__63__.mdwn b/doc/forum/Can_someone_add_Ikiwiki_in_Homebrew__63__.mdwn
new file mode 100644
index 0000000..8812d65
--- /dev/null
+++ b/doc/forum/Can_someone_add_Ikiwiki_in_Homebrew__63__.mdwn
@@ -0,0 +1,10 @@
+From the latest homebrew, it prompts the following seearch result:
+
+    $ brew search ikiwiki
+    No formula found for "ikiwiki".
+    Searching pull requests...
+    Closed pull requests:
+    Add ikiwiki (https://github.com/Homebrew/homebrew/pull/5355)
+    Add ikiwiki formula (https://github.com/Homebrew/homebrew/pull/5358)
+
+Reading the messages on those two GitHub links, it seems the request of adding Ikiwiki into Homebrew is rejected for too much Perl dependencies but an "HomeBrew-Alt" is possible.  Does anyone know if Ikiwiki is added to this "HomeBrew-Alt"?  How to install Ikiwiki on Mac OS X using "Homebrew-Alt"?  I'm desperate in getting Ikiwiki to work on my Mac computers.

Added a comment
diff --git a/doc/forum/HTTPS_edit_required_no_authentication/comment_1_64784d15ac9b0a400044171f2400e924._comment b/doc/forum/HTTPS_edit_required_no_authentication/comment_1_64784d15ac9b0a400044171f2400e924._comment
new file mode 100644
index 0000000..ca44bcd
--- /dev/null
+++ b/doc/forum/HTTPS_edit_required_no_authentication/comment_1_64784d15ac9b0a400044171f2400e924._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawlcaGfdn9Kye1Gc8aGb67PDVQW4mKbQD7E"
+ nickname="Amitai"
+ subject="comment 1"
+ date="2014-10-14T22:25:13Z"
+ content="""
+I have a site like this and can't reproduce the bug. What version of ikiwiki are you running? Can you post your ikiwiki.setup, and perhaps also your web server configuration?
+"""]]

one report suffices; not yet clear there's a bug
diff --git a/doc/bugs/HTTPS_edit_required_no_authentication.mdwn b/doc/bugs/HTTPS_edit_required_no_authentication.mdwn
deleted file mode 100644
index e7793dc..0000000
--- a/doc/bugs/HTTPS_edit_required_no_authentication.mdwn
+++ /dev/null
@@ -1,9 +0,0 @@
-Hello,
-
-I've setup authentication on my ikiwiki website using httpauth plugin. I've also disabled anonok, openid and passwordauth so that httpauth is the unique authentication method.
-I've configured the `cgiauthurl` to https://example.com/auth/ikiwiki.cgi in order to make the authentication more secured (password is never sent in clear). My `url` points to http://example.com/ and my `cgiurl` points to http://example.com/ikiwiki.cgi .
-
-When I try to edit a page accessed by http, everything works fine: there is a redirection to https://example.com/auth/ikiwiki.cgi (defined in `cgiauthurl`) and my browser launches an HTTP Basic Authentication login form.
-But when I try to edit a page accessed by https there is no redirection to the `cgiauthurl` url. Instead, I can edit (and save) the page without authentication. I've tried this with a fresh new browser session where I have never been asked for authentication before. It seems that editing pages directly from https://example.com/ikiwiki.cgi?page=page&do=edit works without authentication...
-
-I think that the Ikiwiki CGI do not redirect to `cgiauthurl` when it is accessed by HTTPS.
diff --git a/doc/forum/HTTPS_edit_required_no_authentication.mdwn b/doc/forum/HTTPS_edit_required_no_authentication.mdwn
index 033033f..4afc134 100644
--- a/doc/forum/HTTPS_edit_required_no_authentication.mdwn
+++ b/doc/forum/HTTPS_edit_required_no_authentication.mdwn
@@ -1,7 +1,5 @@
 Hello,
 
-I've already [[sent a bug|/bugs/HTTPS_edit_required_no_authentication/]] but I think that discussion can also help...
-
 I've setup authentication on my ikiwiki website using httpauth plugin. I've also disabled anonok, openid and passwordauth so that httpauth is the unique authentication method. I've configured the `cgiauthurl` to https://example.com/auth/ikiwiki.cgi in order to make the authentication more secured (password is never sent in clear). My `url` points to http://example.com/ and my `cgiurl` points to http://example.com/ikiwiki.cgi .
 
 When I try to edit a page accessed by http, everything works fine: there is a redirection to https://example.com/auth/ikiwiki.cgi (defined in `cgiauthurl`) and my browser launches an HTTP Basic Authentication login form. But when I try to edit a page accessed by https there is no redirection to the `cgiauthurl` url. Instead, I can edit (and save) the page without authentication. I've tried this with a fresh new browser session where I have never been asked for authentication before. It seems that editing pages directly from https://example.com/ikiwiki.cgi?page=page&do=edit works without authentication...

diff --git a/doc/forum/HTTPS_edit_required_no_authentication.mdwn b/doc/forum/HTTPS_edit_required_no_authentication.mdwn
new file mode 100644
index 0000000..033033f
--- /dev/null
+++ b/doc/forum/HTTPS_edit_required_no_authentication.mdwn
@@ -0,0 +1,9 @@
+Hello,
+
+I've already [[sent a bug|/bugs/HTTPS_edit_required_no_authentication/]] but I think that discussion can also help...
+
+I've setup authentication on my ikiwiki website using httpauth plugin. I've also disabled anonok, openid and passwordauth so that httpauth is the unique authentication method. I've configured the `cgiauthurl` to https://example.com/auth/ikiwiki.cgi in order to make the authentication more secured (password is never sent in clear). My `url` points to http://example.com/ and my `cgiurl` points to http://example.com/ikiwiki.cgi .
+
+When I try to edit a page accessed by http, everything works fine: there is a redirection to https://example.com/auth/ikiwiki.cgi (defined in `cgiauthurl`) and my browser launches an HTTP Basic Authentication login form. But when I try to edit a page accessed by https there is no redirection to the `cgiauthurl` url. Instead, I can edit (and save) the page without authentication. I've tried this with a fresh new browser session where I have never been asked for authentication before. It seems that editing pages directly from https://example.com/ikiwiki.cgi?page=page&do=edit works without authentication...
+
+I think that the Ikiwiki CGI do not redirect to `cgiauthurl` when it is accessed by HTTPS.

diff --git a/doc/bugs/HTTPS_edit_required_no_authentication.mdwn b/doc/bugs/HTTPS_edit_required_no_authentication.mdwn
new file mode 100644
index 0000000..e7793dc
--- /dev/null
+++ b/doc/bugs/HTTPS_edit_required_no_authentication.mdwn
@@ -0,0 +1,9 @@
+Hello,
+
+I've setup authentication on my ikiwiki website using httpauth plugin. I've also disabled anonok, openid and passwordauth so that httpauth is the unique authentication method.
+I've configured the `cgiauthurl` to https://example.com/auth/ikiwiki.cgi in order to make the authentication more secured (password is never sent in clear). My `url` points to http://example.com/ and my `cgiurl` points to http://example.com/ikiwiki.cgi .
+
+When I try to edit a page accessed by http, everything works fine: there is a redirection to https://example.com/auth/ikiwiki.cgi (defined in `cgiauthurl`) and my browser launches an HTTP Basic Authentication login form.
+But when I try to edit a page accessed by https there is no redirection to the `cgiauthurl` url. Instead, I can edit (and save) the page without authentication. I've tried this with a fresh new browser session where I have never been asked for authentication before. It seems that editing pages directly from https://example.com/ikiwiki.cgi?page=page&do=edit works without authentication...
+
+I think that the Ikiwiki CGI do not redirect to `cgiauthurl` when it is accessed by HTTPS.

clarify
diff --git a/doc/bugs/autosetup_python_warnings.mdwn b/doc/bugs/autosetup_python_warnings.mdwn
index 5c081da..d7920b9 100644
--- a/doc/bugs/autosetup_python_warnings.mdwn
+++ b/doc/bugs/autosetup_python_warnings.mdwn
@@ -53,7 +53,8 @@ the XML-RPC libs) until the methods using them are called. --[[schmonz]]
 
 -----
 
-It's more complicated than I thought. Findings and questions:
+It's more complicated than I thought. Findings and questions so
+far:
 
 ### Failing to load an external plugin should be an error
 
@@ -64,7 +65,7 @@ written in any language, ikiwiki assumes loading succeeded.
 Let's take [[!iki plugins/rst]] as an example. It's written in
 Python and uses `proxy.py` to handle XML-RPC communication with
 ikiwiki. Let's say that `proxy.py` compiles, but `rst` itself
-doesn't. We'd like ikiwiki to know the module isn't loaded, and
+doesn't. We'd like ikiwiki to know the plugin isn't loaded, and
 we'd like an error message about it (not just the Python errors).
 
 Now let's say `rst` would be fine by itself, but `proxy.py` doesn't

findings and questions
diff --git a/doc/bugs/autosetup_python_warnings.mdwn b/doc/bugs/autosetup_python_warnings.mdwn
index f17c865..5c081da 100644
--- a/doc/bugs/autosetup_python_warnings.mdwn
+++ b/doc/bugs/autosetup_python_warnings.mdwn
@@ -50,3 +50,51 @@ I got a basic site with some Python error messages.
 Looks like `proxy.py` needs the trick from [[!debbug 637604]] so
 that it can defer a few imports (at least `xml.parsers.expat` and
 the XML-RPC libs) until the methods using them are called. --[[schmonz]]
+
+-----
+
+It's more complicated than I thought. Findings and questions:
+
+### Failing to load an external plugin should be an error
+
+When a typical Perl plugin fails to load (say, by failing to compile),
+`IkiWiki::loadplugin()` throws an exception. For XML-RPC plugins
+written in any language, ikiwiki assumes loading succeeded.
+
+Let's take [[!iki plugins/rst]] as an example. It's written in
+Python and uses `proxy.py` to handle XML-RPC communication with
+ikiwiki. Let's say that `proxy.py` compiles, but `rst` itself
+doesn't. We'd like ikiwiki to know the module isn't loaded, and
+we'd like an error message about it (not just the Python errors).
+
+Now let's say `rst` would be fine by itself, but `proxy.py` doesn't
+compile because some of the Python modules it needs are missing
+from the system. (This can't currently happen on Debian, where
+`libpython2.7` includes `pyexpat.so`, but pkgsrc's `python27`
+doesn't; it's in a separate `py-expat` package.) As before, we'd
+like ikiwiki to know `rst` didn't load, but that's trickier when
+the problem lies with the communication mechanism itself.
+
+For the tricky case, what to do? Some ideas:
+
+- Figure out where in `auto.setup` we're enabling `rst` by default,
+  and stop doing that
+- In pkgsrc's `ikiwiki` package, add a dependency on Python and
+  `py-expat` just in case someone wants to enable `rst` or other
+  Python plugins
+
+For the simple case, I've tried the following:
+
+[[!template id=gitbranch branch=schmonz/external-plugin-loading author="[[schmonz]]"]]
+
+- In `IkiWiki::Plugin::external::import()`, capture stderr
+- Before falling off the end of `IkiWiki::Plugin::external::rpc_call()`,
+  if the command had been 'import' and stderr is non-empty, throw
+  an exception
+- In `IkiWiki::loadplugin()`, try/catch/throw just like we do with
+  regular non-external plugins
+
+With these changes, we have a test that fails when an external
+plugin can't be loaded (and passes, less trivially, when it can).
+Huzzah! (I haven't tested yet whether I've otherwise completely
+broken the interface for external plugins. Not-huzzah!) --[[schmonz]]

google search plugin: use https for the search
diff --git a/doc/bugs/Google_search_plugin_not_passing_query_over_HTTPS_when_HTTPS_enabled.mdwn b/doc/bugs/Google_search_plugin_not_passing_query_over_HTTPS_when_HTTPS_enabled.mdwn
index 3f8fbcc..f3c4373 100644
--- a/doc/bugs/Google_search_plugin_not_passing_query_over_HTTPS_when_HTTPS_enabled.mdwn
+++ b/doc/bugs/Google_search_plugin_not_passing_query_over_HTTPS_when_HTTPS_enabled.mdwn
@@ -5,3 +5,7 @@ http://source.ikiwiki.branchable.com/?p=source.git;a=blob;f=templates/googleform
 to
 
     <form method="get" action="//www.google.com/search" id="searchform">
+
+> I changed it to use https unconditionally - there seems little point
+> in doing Google searches in clear-text when Google supports https,
+> even on unencrypted wikis. [[done]] --[[smcv]]
diff --git a/templates/googleform.tmpl b/templates/googleform.tmpl
index 9468e06..b1c3078 100644
--- a/templates/googleform.tmpl
+++ b/templates/googleform.tmpl
@@ -1,5 +1,5 @@
 
-<form method="get" action="http://www.google.com/search" id="searchform">
+<form method="get" action="https://www.google.com/search" id="searchform">
  <div>
   <input name="sitesearch" value="<TMPL_VAR URL>" type="hidden" />
   <input name="q" value="" id="searchbox" size="16" maxlength="255" type="text"

default User-Agent changed
diff --git a/doc/plugins/openid/troubleshooting.mdwn b/doc/plugins/openid/troubleshooting.mdwn
index 377fd10..12cd9be 100644
--- a/doc/plugins/openid/troubleshooting.mdwn
+++ b/doc/plugins/openid/troubleshooting.mdwn
@@ -112,6 +112,12 @@ over which you and your customer have no knowledge or control."
 
 Sigh. -- Chap
 
+> Thanks for the pointer. It seems the open-source ruleset blacklists libwww-perl by default
+> too... this seems very misguided but whatever. I've changed our default User-Agent to
+> `ikiwiki/3.20141012` (or whatever the version is). If we get further UA-blacklisting
+> problems I'm very tempted to go for `Mozilla/5.0 (but not really)` as the
+> next try. --[[smcv]]
+
 ## Error: OpenID failure: naive_verify_failed_network: Could not contact ID provider to verify response.
 
 Again, this could have various causes. It was helpful to bump the debug level

removed
diff --git a/doc/forum/Encoding_problems_when_editing_through_browser/comment_2_dbb8785a356ed3c34dbc46f97955ab38._comment b/doc/forum/Encoding_problems_when_editing_through_browser/comment_2_dbb8785a356ed3c34dbc46f97955ab38._comment
deleted file mode 100644
index e8a12b7..0000000
--- a/doc/forum/Encoding_problems_when_editing_through_browser/comment_2_dbb8785a356ed3c34dbc46f97955ab38._comment
+++ /dev/null
@@ -1,10 +0,0 @@
-[[!comment format=mdwn
- username="smcv"
- ip="86.27.84.36"
- subject="comment 2"
- date="2014-10-12T16:42:53Z"
- content="""
-This looks like
-[[a bug that was fixed in version 3.20140916|bugs/garbled_non-ascii_characters_in_body_in_web_interface],
-caused by a behaviour change in Encode.pm 2.53 as shipped with Perl 5.20.
-"""]]

Added a comment
diff --git a/doc/forum/Encoding_problems_when_editing_through_browser/comment_2_dbb8785a356ed3c34dbc46f97955ab38._comment b/doc/forum/Encoding_problems_when_editing_through_browser/comment_2_dbb8785a356ed3c34dbc46f97955ab38._comment
new file mode 100644
index 0000000..e8a12b7
--- /dev/null
+++ b/doc/forum/Encoding_problems_when_editing_through_browser/comment_2_dbb8785a356ed3c34dbc46f97955ab38._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="smcv"
+ ip="86.27.84.36"
+ subject="comment 2"
+ date="2014-10-12T16:42:53Z"
+ content="""
+This looks like
+[[a bug that was fixed in version 3.20140916|bugs/garbled_non-ascii_characters_in_body_in_web_interface],
+caused by a behaviour change in Encode.pm 2.53 as shipped with Perl 5.20.
+"""]]

help Markdown make a list
diff --git a/doc/forum/Encoding_problems_when_editing_through_browser/comment_1_f0602795e11c68b3d4202fba58ad53b5._comment b/doc/forum/Encoding_problems_when_editing_through_browser/comment_1_f0602795e11c68b3d4202fba58ad53b5._comment
index f3f83af..636417a 100644
--- a/doc/forum/Encoding_problems_when_editing_through_browser/comment_1_f0602795e11c68b3d4202fba58ad53b5._comment
+++ b/doc/forum/Encoding_problems_when_editing_through_browser/comment_1_f0602795e11c68b3d4202fba58ad53b5._comment
@@ -7,6 +7,7 @@
 What version of ikiwiki are you running? I believe this was fixed in [[news/version 3.20140916]], with the patch from [[bugs/garbled non-ascii characters in body in web interface]].
 
 Related reading:
+
 - [[forum/\"Error: cannot decode string with wide characters\" on Mageia Linux x86-64 Cauldron]]
 - [[forum/build error: Cannot decode string with wide characters]]
 - [[todo/should use a standard encoding for utf chars in filenames]]

Added a comment: fixed in a recent release, I think
diff --git a/doc/forum/Encoding_problems_when_editing_through_browser/comment_1_f0602795e11c68b3d4202fba58ad53b5._comment b/doc/forum/Encoding_problems_when_editing_through_browser/comment_1_f0602795e11c68b3d4202fba58ad53b5._comment
new file mode 100644
index 0000000..f3f83af
--- /dev/null
+++ b/doc/forum/Encoding_problems_when_editing_through_browser/comment_1_f0602795e11c68b3d4202fba58ad53b5._comment
@@ -0,0 +1,13 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawlcaGfdn9Kye1Gc8aGb67PDVQW4mKbQD7E"
+ nickname="Amitai"
+ subject="fixed in a recent release, I think"
+ date="2014-10-12T16:40:17Z"
+ content="""
+What version of ikiwiki are you running? I believe this was fixed in [[news/version 3.20140916]], with the patch from [[bugs/garbled non-ascii characters in body in web interface]].
+
+Related reading:
+- [[forum/\"Error: cannot decode string with wide characters\" on Mageia Linux x86-64 Cauldron]]
+- [[forum/build error: Cannot decode string with wide characters]]
+- [[todo/should use a standard encoding for utf chars in filenames]]
+"""]]

diff --git a/doc/forum/Encoding_problems_when_editing_through_browser.mdwn b/doc/forum/Encoding_problems_when_editing_through_browser.mdwn
new file mode 100644
index 0000000..9ad1cdb
--- /dev/null
+++ b/doc/forum/Encoding_problems_when_editing_through_browser.mdwn
@@ -0,0 +1,14 @@
+Hey everyone, I have the following problem: I am writing a German Wiki and therefore use umlauts (ä,ö,ü…) quite often in my writing. When I am not using the browser for editing the wiki (or writing comments) everything is fine. Since I want other poeple to be able to post comments or use the discussion pages I need to get the encoding to work. Here is what is happening when I'm trying to edit a discussion page:
+
+* Writing the comment: ![](http://f.cl.ly/items/2F3u36261z2N141T343E/Screen%20Shot%202014-10-12%20at%2017.54.06.png)
+* Checking the comment via the "preview": ![](http://f.cl.ly/items/3O1c2G011u2x0E2s0o3q/Screen%20Shot%202014-10-12%20at%2017.54.17.png)
+* Pressing "cancel" since umlauts don't work: ![](http://f.cl.ly/items/141P2M1v323g1J2H3220/Screen%20Shot%202014-10-12%20at%2017.54.30.png)
+
+As I said, when I'm not posting from the browser everything works fine. Here's what I've checked/done to prevent the encoding error:
+
+* I put "export LANG=de_DE.UTF-8" and "export LANGUAGE=de_DE.UTF-8" in my .bashrc
+* I set "locale:" to "de_DE.UTF-8" in my ikiwiki .setup-File
+
+What else could there be wrong? What else could I try to solve the problem?
+
+Any ideas are appreciated! Thanks in advance!

diff --git a/doc/bugs/Google_search_plugin_not_passing_query_over_HTTPS_when_HTTPS_enabled.mdwn b/doc/bugs/Google_search_plugin_not_passing_query_over_HTTPS_when_HTTPS_enabled.mdwn
new file mode 100644
index 0000000..3f8fbcc
--- /dev/null
+++ b/doc/bugs/Google_search_plugin_not_passing_query_over_HTTPS_when_HTTPS_enabled.mdwn
@@ -0,0 +1,7 @@
+This fix is probably just changing
+
+http://source.ikiwiki.branchable.com/?p=source.git;a=blob;f=templates/googleform.tmpl;h=9468e062ab19a381f6dadb339480796efae827f5;hb=HEAD#l2
+
+to
+
+    <form method="get" action="//www.google.com/search" id="searchform">

clarify further
diff --git a/doc/ikiwiki/directive/comment.mdwn b/doc/ikiwiki/directive/comment.mdwn
index fdb2c7f..590ad5c 100644
--- a/doc/ikiwiki/directive/comment.mdwn
+++ b/doc/ikiwiki/directive/comment.mdwn
@@ -1,7 +1,15 @@
 The `comment` directive is supplied by the
-[[!iki plugins/comments desc=comments]] plugin, and should be the only
-thing in a comment page. It is usually filled out by
-the comment plugin when a user posts a comment.
+[[!iki plugins/comments desc=comments]] plugin. There should
+be one comment directive in each source file with extension
+`._comment` or `._comment_pending`, and the directive should not
+appear anywhere else. Comments are normally created via the web,
+in which case ikiwiki automatically creates a suitable
+`._comment` file.
+
+Wiki administrators can also commit comment files to the version
+control system directly: they should be named starting with
+the *comments\_pagename* config option (usually `comment_`)
+and ending with `._comment`, for instance `comment_42._comment`.
 
 Example:
 

clarify
diff --git a/doc/ikiwiki/directive/comment.mdwn b/doc/ikiwiki/directive/comment.mdwn
index 398130e..fdb2c7f 100644
--- a/doc/ikiwiki/directive/comment.mdwn
+++ b/doc/ikiwiki/directive/comment.mdwn
@@ -1,7 +1,7 @@
 The `comment` directive is supplied by the
-[[!iki plugins/comments desc=comments]] plugin, and is used to add a comment
-to a page. Typically, the directive is the only thing on a comment page,
-and is filled out by the comment plugin when a user posts a comment.
+[[!iki plugins/comments desc=comments]] plugin, and should be the only
+thing in a comment page. It is usually filled out by
+the comment plugin when a user posts a comment.
 
 Example:
 
@@ -17,7 +17,8 @@ Example:
 ## usage
 
 The only required parameter is `content`, the others just add or override
-metadata of the comment.
+metadata for the comment. Many parameters are shortcuts for [[meta]]
+directives.
 
 * `content` - Text to display for the comment.
   Note that [[directives|ikiwiki/directive]]

That's not how that directive is used, and if you want to try stuff out please edit the sandbox instead
This reverts commit 856819a733d90a2ca259a5a3b03cc5d84f72e931
diff --git a/doc/ikiwiki/formatting.mdwn b/doc/ikiwiki/formatting.mdwn
index 0b9b86c..befbce9 100644
--- a/doc/ikiwiki/formatting.mdwn
+++ b/doc/ikiwiki/formatting.mdwn
@@ -104,11 +104,3 @@ you use the following additional features:
   Full list of [[directives|directive]] enabled for this wiki:
   [[!listdirectives ]]
 """]]
-[[!comment  format=mdwn
-username="foo"
-subject="Bar"
-date="2009-06-02T19:05:01Z"
-content="""
-Blah blah.
-"""
-]]

diff --git a/doc/ikiwiki/formatting.mdwn b/doc/ikiwiki/formatting.mdwn
index befbce9..0b9b86c 100644
--- a/doc/ikiwiki/formatting.mdwn
+++ b/doc/ikiwiki/formatting.mdwn
@@ -104,3 +104,11 @@ you use the following additional features:
   Full list of [[directives|directive]] enabled for this wiki:
   [[!listdirectives ]]
 """]]
+[[!comment  format=mdwn
+username="foo"
+subject="Bar"
+date="2009-06-02T19:05:01Z"
+content="""
+Blah blah.
+"""
+]]

diff --git a/doc/sandbox.mdwn b/doc/sandbox.mdwn
index 451d77e..748fdbe 100644
--- a/doc/sandbox.mdwn
+++ b/doc/sandbox.mdwn
@@ -119,5 +119,5 @@ Räksmörgås.
 
 `pre?`
 
-Testing. Test. 
+Testing. Test. 試験として書き込みします。
 

alternative plan
diff --git a/doc/todo/generate_HTML5_by_default.mdwn b/doc/todo/generate_HTML5_by_default.mdwn
index 3adce8c..59726bf 100644
--- a/doc/todo/generate_HTML5_by_default.mdwn
+++ b/doc/todo/generate_HTML5_by_default.mdwn
@@ -31,3 +31,12 @@ Options include:
 Thoughts?
 
 --[[smcv]]
+
+> Another possibility would be to change the doctype to `<!DOCTYPE html>`
+> unconditionally, stop trying to limit ourselves to XHTML 1.0 Strict
+> (use HTML5 features that degrade gracefully, like
+> [[ARIA roles|todo/add aria landmarks to make ikiwiki websites more accessible]]),
+> but avoid using the new elements like `<section>` that require specific
+> browser support unless `html5` is set to 1. That would get rid of the
+> backwards-compatibility concerns while keeping the ability to use
+> post-2000 markup. --[[smcv]]

exclude openid/troubleshooting
diff --git a/doc/users/schmonz.mdwn b/doc/users/schmonz.mdwn
index 92a8927..dcbb8df 100644
--- a/doc/users/schmonz.mdwn
+++ b/doc/users/schmonz.mdwn
@@ -1,7 +1,7 @@
 [Amitai Schlair](http://www.schmonz.com/) has contributed code to ikiwiki...
 
 [[!map
-pages="!*/Discussion and ((link(users/schmonz) and plugins/*) or rcs/cvs or todo/fancypodcast)"
+pages="!*/Discussion and ((link(users/schmonz) and plugins/* and !plugins/openid/*) or rcs/cvs or todo/fancypodcast)"
 ]]
 
 ...and uses ikiwiki for all sorts of things:

diff --git a/doc/todo/design_for_cross-linking_between_content_and_CGI.mdwn b/doc/todo/design_for_cross-linking_between_content_and_CGI.mdwn
index 7064bba..d8040bf 100644
--- a/doc/todo/design_for_cross-linking_between_content_and_CGI.mdwn
+++ b/doc/todo/design_for_cross-linking_between_content_and_CGI.mdwn
@@ -130,3 +130,5 @@ variable is set once this is all working, since it's a bit slow.
   CGI via staging.example.net. Self-referential links to the
   CGI point to cgi.example.com, but maybe they should point to
   staging.example.net?
+
+* *(possibly incomplete, look for TODO and ??? in relativity.t)*

Added a comment
diff --git a/doc/forum/CGI_script_and_HTTPS/comment_2_12dc028e4e3d1723605a154802087d29._comment b/doc/forum/CGI_script_and_HTTPS/comment_2_12dc028e4e3d1723605a154802087d29._comment
new file mode 100644
index 0000000..619b130
--- /dev/null
+++ b/doc/forum/CGI_script_and_HTTPS/comment_2_12dc028e4e3d1723605a154802087d29._comment
@@ -0,0 +1,17 @@
+[[!comment format=mdwn
+ username="smcv"
+ ip="81.100.115.242"
+ subject="comment 2"
+ date="2014-10-05T22:56:56Z"
+ content="""
+In git master, if `$config{html5} = 1` then the `<base>` URL
+will usually be host-relative or protocol-relative (`/wiki/` or
+`//example.com/wiki/`) which reduces the need for that option.
+
+This is not yet available in a release, and is still subject to
+change.
+
+I still don't know what your wiki's configuration is, because you
+never told us the settings I asked for (`cgiurl` and `url`), so
+I don't know whether this will help you.
+"""]]

Added a comment
diff --git a/doc/forum/Dot_CGI_pointing_to_localhost._What_happened__63__/comment_2_42f35c6be8b990ff22614dc6b28e9344._comment b/doc/forum/Dot_CGI_pointing_to_localhost._What_happened__63__/comment_2_42f35c6be8b990ff22614dc6b28e9344._comment
new file mode 100644
index 0000000..dfe9512
--- /dev/null
+++ b/doc/forum/Dot_CGI_pointing_to_localhost._What_happened__63__/comment_2_42f35c6be8b990ff22614dc6b28e9344._comment
@@ -0,0 +1,16 @@
+[[!comment format=mdwn
+ username="smcv"
+ ip="81.100.115.242"
+ subject="comment 2"
+ date="2014-10-05T22:55:01Z"
+ content="""
+I have added a new `$config{reverse_proxy}` option in git master
+which applies the necessary hard-coding.
+
+Also in git master, if `$config{html5} = 1` then the `<base>` URL
+will usually be host-relative or protocol-relative (`/wiki/` or
+`//example.com/wiki/`) which reduces the need for that option.
+
+These are not yet available in a release, and are still subject to
+change.
+"""]]

Added a comment
diff --git a/doc/forum/Using_reverse_proxy__59___base_URL_is_http_instead_of_https/comment_6_e61899aa5ad8798b864dc295102e44f7._comment b/doc/forum/Using_reverse_proxy__59___base_URL_is_http_instead_of_https/comment_6_e61899aa5ad8798b864dc295102e44f7._comment
new file mode 100644
index 0000000..ba1896d
--- /dev/null
+++ b/doc/forum/Using_reverse_proxy__59___base_URL_is_http_instead_of_https/comment_6_e61899aa5ad8798b864dc295102e44f7._comment
@@ -0,0 +1,17 @@
+[[!comment format=mdwn
+ username="smcv"
+ ip="81.100.115.242"
+ subject="comment 6"
+ date="2014-10-05T22:54:06Z"
+ content="""
+> One way to solve this would be a new `$config{hard_code_urls}` option
+
+I have added basically this in git master. It isn't in a release yet,
+and I renamed it to `$config{reverse_proxy}`.
+
+Also in git master, if `$config{html5} = 1` then the `<base>` URL
+will usually be host-relative or protocol-relative (`/wiki/` or
+`//example.com/wiki/`) which reduces the need for that option.
+
+These are still subject to change, for now.
+"""]]

more fixes
diff --git a/doc/todo/design_for_cross-linking_between_content_and_CGI.mdwn b/doc/todo/design_for_cross-linking_between_content_and_CGI.mdwn
index c66126f..7064bba 100644
--- a/doc/todo/design_for_cross-linking_between_content_and_CGI.mdwn
+++ b/doc/todo/design_for_cross-linking_between_content_and_CGI.mdwn
@@ -119,18 +119,6 @@ variable is set once this is all working, since it's a bit slow.
 
 # Remaining bugs
 
-## Definitely a bug
-
-* Configure url: "http://example.com/wiki/",
-  cgiurl: "https://example.com/cgi-bin/ikiwiki.cgi" and access the
-  CGI via https://example.com (the "NetBSD wiki" use-case).
-  The static content should be loaded from https://example.com
-  to avoid mixed-content, but it is loaded from http://example.com.
-
-* Put IkiWiki behind a reverse-proxy so the web server tells the CGI
-  that it is being accessed via http://localhost or http://127.0.0.1
-  or something. Links should not point to http://localhost.
-
 ## Arguable
 
 * Configure the url and cgiurl to both be https, then access the

Document another fix
diff --git a/doc/todo/Protocol_relative_urls_for_stylesheet_linking.mdwn b/doc/todo/Protocol_relative_urls_for_stylesheet_linking.mdwn
index 0ab4814..307c528 100644
--- a/doc/todo/Protocol_relative_urls_for_stylesheet_linking.mdwn
+++ b/doc/todo/Protocol_relative_urls_for_stylesheet_linking.mdwn
@@ -20,6 +20,13 @@ but this breaks all sorts of things, like the 404 plugin and wiki rebuilds will
 > CGI-generated pages should generate those links. This was the implementation of
 > [[todo/want_to_avoid_ikiwiki_using_http_or_https_in_urls_to_allow_serving_both]].
 >
+>> This wasn't actually the case if the schemes are different; but now
+>> IkiWiki will generate protocol-relative URLs if the CGI is https,
+>> the url is http and the hostname is the same (i.e. it assumes that the https
+>> equivalent of the url will also work). This is to prevent mixed-content
+>> issues, and partially addresses this todo item.
+>> --[[smcv]]
+>
 > If your`$config{url}` and `$config{cgiurl}` have different hostnames (e.g.
 > `url => "http://wiki.example.com", cgiurl => "http://cgi.example.com/ikiwiki.cgi"`)
 > then you might still have this problem. In principle, IkiWiki could generate

In html5 mode, generate a host- or protocol-relative <base> for the CGI
This increases the number of situations in which we do the right thing.
diff --git a/IkiWiki/CGI.pm b/IkiWiki/CGI.pm
index 70e3b71..0224c2a 100644
--- a/IkiWiki/CGI.pm
+++ b/IkiWiki/CGI.pm
@@ -66,7 +66,10 @@ sub cgitemplate ($$$;@) {
 	my $page="";
 	if (exists $params{page}) {
 		$page=delete $params{page};
-		$params{forcebaseurl}=urlabs(urlto($page), $topurl);
+		$params{forcebaseurl}=urlto($page);
+		if (! $config{html5}) {
+			$params{forcebaseurl}=urlabs($params{forcebaseurl}, $topurl);
+		}
 	}
 	run_hooks(pagetemplate => sub {
 		shift->(
@@ -77,12 +80,17 @@ sub cgitemplate ($$$;@) {
 	});
 	templateactions($template, "");
 
+	my $baseurl = baseurl();
+	if (! $config{html5}) {
+		$baseurl = urlabs($baseurl, $topurl),
+	}
+
 	$template->param(
 		dynamic => 1,
 		title => $title,
 		wikiname => $config{wikiname},
 		content => $content,
-		baseurl => urlabs(baseurl(), $topurl),
+		baseurl => $baseurl,
 		html5 => $config{html5},
 		%params,
 	);
diff --git a/doc/bugs/trouble_with_base_in_search.mdwn b/doc/bugs/trouble_with_base_in_search.mdwn
index ca6a6c5..7c3d133 100644
--- a/doc/bugs/trouble_with_base_in_search.mdwn
+++ b/doc/bugs/trouble_with_base_in_search.mdwn
@@ -58,3 +58,14 @@ And I'm sure someone else could come up with something better and more general.
 
 >> I suppose what I would like would be to not need to use a `<base href>` in searching at all.
 >> --[[KathrynAndersen]]
+
+>>> `<base href>` is *not* required to be absolute in HTML5, so when
+>>> `html5: 1` is used, I've changed it to be host-relative in most cases.
+>>> I think that at least partially addresses this bug report,
+>>> particularly if we [[todo/generate HTML5 by default]] like I've suggested.
+>>>
+>>> The `<base>` is there so we can avoid having to compute how to
+>>> get to (the virtual directory containing) the root of the wiki from
+>>> `ikiwiki.cgi`, which might well be somewhere odd like `/cgi-bin/`.
+>>> I think there are probably other things that it fixes or simplifies.
+>>> --[[smcv]]
diff --git a/t/relativity.t b/t/relativity.t
index 86b807b..300c6e6 100755
--- a/t/relativity.t
+++ b/t/relativity.t
@@ -77,6 +77,7 @@ url: "http://example.com/wiki/"
 cgiurl: "http://example.com/cgi-bin/ikiwiki.cgi"
 cgi_wrapper: t/tmp/ikiwiki.cgi
 cgi_wrappermode: 0754
+html5: 0
 # make it easier to test previewing
 add_plugins:
 - anonok
@@ -162,6 +163,106 @@ like($bits{stylehref}, qr{^(?:(?:http:)?//example.com)?/wiki/style.css$});
 like($bits{tophref}, qr{^(?:/wiki|\.\./\.\./\.\.)/$});
 like($bits{cgihref}, qr{^(?:(?:http:)?//example.com)?/cgi-bin/ikiwiki.cgi$});
 
+# in html5, the <base> is allowed to be relative, and we take full
+# advantage of that
+writefile("test.setup", "t/tmp", <<EOF
+# IkiWiki::Setup::Yaml - YAML formatted setup file
+wikiname: this is the name of my wiki
+srcdir: t/tmp/in
+destdir: t/tmp/out
+templatedir: templates
+url: "http://example.com/wiki/"
+cgiurl: "http://example.com/cgi-bin/ikiwiki.cgi"
+cgi_wrapper: t/tmp/ikiwiki.cgi
+cgi_wrappermode: 0754
+html5: 1
+# make it easier to test previewing
+add_plugins:
+- anonok
+anonok_pagespec: "*"
+ENV: { 'PERL5LIB': '$PERL5LIB' }
+EOF
+);
+
+ok(unlink("t/tmp/ikiwiki.cgi") || $!{ENOENT});
+ok(! system("./ikiwiki.out --setup t/tmp/test.setup --rebuild --wrappers"));
+
+# CGI wrapper should be exactly the requested mode
+(undef, undef, $mode, undef, undef,
+	undef, undef, undef, undef, undef,
+	undef, undef, undef) = stat("t/tmp/ikiwiki.cgi");
+is($mode & 07777, 0754);
+
+ok(-e "t/tmp/out/a/b/c/index.html");
+$content = readfile("t/tmp/out/a/b/c/index.html");
+# no <base> on static HTML
+unlike($content, qr{<base\W});
+# url and cgiurl are on the same host so the cgiurl is host-relative
+like($content, qr{<a[^>]+href="/cgi-bin/ikiwiki.cgi\?do=prefs"});
+# cross-links between static pages are relative
+like($content, qr{<li>A: <a href="../../">a</a></li>});
+like($content, qr{<li>B: <a href="../">b</a></li>});
+like($content, qr{<li>E: <a href="../../d/e/">e</a></li>});
+
+run(["./t/tmp/ikiwiki.cgi"], \undef, \$content, init => sub {
+	$ENV{REQUEST_METHOD} = 'GET';
+	$ENV{SERVER_PORT} = '80';
+	$ENV{SCRIPT_NAME} = '/cgi-bin/ikiwiki.cgi';
+	$ENV{QUERY_STRING} = 'do=prefs';
+	$ENV{HTTP_HOST} = 'example.com';
+});
+%bits = parse_cgi_content($content);
+is($bits{basehref}, "/wiki/");
+is($bits{stylehref}, "/wiki/style.css");
+is($bits{tophref}, "/wiki/");
+is($bits{cgihref}, "/cgi-bin/ikiwiki.cgi");
+
+# when accessed via HTTPS, links are secure - this is easy because under
+# html5 they're independent of the URL at which the CGI was accessed
+run(["./t/tmp/ikiwiki.cgi"], \undef, \$content, init => sub {
+	$ENV{REQUEST_METHOD} = 'GET';
+	$ENV{SERVER_PORT} = '443';
+	$ENV{SCRIPT_NAME} = '/cgi-bin/ikiwiki.cgi';
+	$ENV{QUERY_STRING} = 'do=prefs';
+	$ENV{HTTP_HOST} = 'example.com';
+	$ENV{HTTPS} = 'on';
+});
+%bits = parse_cgi_content($content);
+is($bits{basehref}, "/wiki/");
+is($bits{stylehref}, "/wiki/style.css");
+is($bits{tophref}, "/wiki/");
+is($bits{cgihref}, "/cgi-bin/ikiwiki.cgi");
+
+# when accessed via a different hostname, links stay on that host -
+# this is really easy in html5 because we can use relative URLs
+run(["./t/tmp/ikiwiki.cgi"], \undef, \$content, init => sub {
+	$ENV{REQUEST_METHOD} = 'GET';
+	$ENV{SERVER_PORT} = '80';
+	$ENV{SCRIPT_NAME} = '/cgi-bin/ikiwiki.cgi';
+	$ENV{QUERY_STRING} = 'do=prefs';
+	$ENV{HTTP_HOST} = 'staging.example.net';
+});
+%bits = parse_cgi_content($content);
+is($bits{basehref}, "/wiki/");
+is($bits{stylehref}, "/wiki/style.css");
+is($bits{tophref}, "/wiki/");
+is($bits{cgihref}, "/cgi-bin/ikiwiki.cgi");
+
+# previewing a page
+$in = 'do=edit&page=a/b/c&Preview';
+run(["./t/tmp/ikiwiki.cgi"], \$in, \$content, init => sub {
+	$ENV{REQUEST_METHOD} = 'POST';
+	$ENV{SERVER_PORT} = '80';
+	$ENV{SCRIPT_NAME} = '/cgi-bin/ikiwiki.cgi';
+	$ENV{HTTP_HOST} = 'example.com';
+	$ENV{CONTENT_LENGTH} = length $in;
+});
+%bits = parse_cgi_content($content);
+is($bits{basehref}, "/wiki/a/b/c/");
+is($bits{stylehref}, "/wiki/style.css");
+like($bits{tophref}, qr{^(?:/wiki|\.\./\.\./\.\.)/$});
+is($bits{cgihref}, "/cgi-bin/ikiwiki.cgi");
+
 #######################################################################
 # site 2: static content and CGI are on different servers
 
@@ -175,6 +276,7 @@ url: "http://static.example.com/"
 cgiurl: "http://cgi.example.com/ikiwiki.cgi"
 cgi_wrapper: t/tmp/ikiwiki.cgi
 cgi_wrappermode: 0754
+html5: 0
 # make it easier to test previewing
 add_plugins:
 - anonok
@@ -246,11 +348,101 @@ run(["./t/tmp/ikiwiki.cgi"], \$in, \$content, init => sub {
 like($bits{basehref}, qr{^http://static.example.com/a/b/c/$});
 like($bits{stylehref}, qr{^(?:(?:http:)?//static.example.com|\.\./\.\./\.\.)/style.css$});
 like($bits{tophref}, qr{^(?:(?:http:)?//static.example.com|\.\./\.\./\.\.)/$});
+like($bits{cgihref}, qr{^(?:(?:http:)?//(?:staging\.example\.net|cgi\.example\.com))?/ikiwiki.cgi$});
 TODO: {
 local $TODO = "use self-referential CGI URL?";
 like($bits{cgihref}, qr{^(?:(?:http:)?//staging.example.net)?/ikiwiki.cgi$});
 }
 
+writefile("test.setup", "t/tmp", <<EOF
+# IkiWiki::Setup::Yaml - YAML formatted setup file
+wikiname: this is the name of my wiki
+srcdir: t/tmp/in
+destdir: t/tmp/out
+templatedir: templates
+url: "http://static.example.com/"
+cgiurl: "http://cgi.example.com/ikiwiki.cgi"
+cgi_wrapper: t/tmp/ikiwiki.cgi

(Diff truncated)
offer myself to the ravenous consulting market
diff --git a/doc/consultants.mdwn b/doc/consultants.mdwn
index ee09156..26525e4 100644
--- a/doc/consultants.mdwn
+++ b/doc/consultants.mdwn
@@ -5,5 +5,8 @@ functionality to ikiwiki. The following is a list of people who are
 available to do consulting or other work on ikiwiki.
 
 * [[Joey]] wrote ikiwiki. He is available for consulting on a part-time basis.
+* [[Amitai Schlair]] (a.k.a. [[schmonz]]) wrote [[rcs/cvs]],
+  [[plugins/rsync]], and [[todo/fancypodcast]], among other things.
+  Contact him via [his website](http://www.schmonz.com/).
 
 Feel free to add yourself to this list.
diff --git a/doc/users/Amitai_Schlair.mdwn b/doc/users/Amitai_Schlair.mdwn
new file mode 100644
index 0000000..6b0dbed
--- /dev/null
+++ b/doc/users/Amitai_Schlair.mdwn
@@ -0,0 +1 @@
+[[!meta redir=users/schmonz]]

remaining bugs after fixing some of the easier situations
diff --git a/doc/todo/design_for_cross-linking_between_content_and_CGI.mdwn b/doc/todo/design_for_cross-linking_between_content_and_CGI.mdwn
index 7c920f0..c66126f 100644
--- a/doc/todo/design_for_cross-linking_between_content_and_CGI.mdwn
+++ b/doc/todo/design_for_cross-linking_between_content_and_CGI.mdwn
@@ -116,3 +116,29 @@ I've added a regression test in `t/relativity.t`. We might want to
 consider dropping some of it or skipping it unless a special environment
 variable is set once this is all working, since it's a bit slow.
 --[[smcv]]
+
+# Remaining bugs
+
+## Definitely a bug
+
+* Configure url: "http://example.com/wiki/",
+  cgiurl: "https://example.com/cgi-bin/ikiwiki.cgi" and access the
+  CGI via https://example.com (the "NetBSD wiki" use-case).
+  The static content should be loaded from https://example.com
+  to avoid mixed-content, but it is loaded from http://example.com.
+
+* Put IkiWiki behind a reverse-proxy so the web server tells the CGI
+  that it is being accessed via http://localhost or http://127.0.0.1
+  or something. Links should not point to http://localhost.
+
+## Arguable
+
+* Configure the url and cgiurl to both be https, then access the
+  CGI via a non-https address. The stylesheet is loaded from the http
+  version of the static site, but maybe it should be forced to https?
+
+* Configure url = "http://static.example.com/",
+  cgiurl = "http://cgi.example.com/ikiwiki.cgi" and access the
+  CGI via staging.example.net. Self-referential links to the
+  CGI point to cgi.example.com, but maybe they should point to
+  staging.example.net?

Use protocol-relative URIs if cgiurl and url differ only by authority (hostname)
diff --git a/IkiWiki.pm b/IkiWiki.pm
index d5d11ee..c1518a2 100644
--- a/IkiWiki.pm
+++ b/IkiWiki.pm
@@ -613,12 +613,19 @@ sub checkconfig () {
 
 			$local_cgiurl = $cgiurl->path;
 
-			if ($cgiurl->scheme ne $baseurl->scheme or
-				$cgiurl->authority ne $baseurl->authority) {
+			if ($cgiurl->scheme ne $baseurl->scheme) {
 				# too far apart, fall back to absolute URLs
 				$local_url = "$config{url}/";
 				$local_cgiurl = $config{cgiurl};
 			}
+			elsif ($cgiurl->authority ne $baseurl->authority) {
+				# slightly too far apart, fall back to
+				# protocol-relative URLs
+				$local_url = "$config{url}/";
+				$local_url =~ s{^https?://}{//};
+				$local_cgiurl = $config{cgiurl};
+				$local_cgiurl =~ s{^https?://}{//};
+			}
 		}
 
 		$local_url =~ s{//$}{/};
diff --git a/doc/todo/Protocol_relative_urls_for_stylesheet_linking.mdwn b/doc/todo/Protocol_relative_urls_for_stylesheet_linking.mdwn
index ccbaf4e..0ab4814 100644
--- a/doc/todo/Protocol_relative_urls_for_stylesheet_linking.mdwn
+++ b/doc/todo/Protocol_relative_urls_for_stylesheet_linking.mdwn
@@ -26,6 +26,14 @@ but this breaks all sorts of things, like the 404 plugin and wiki rebuilds will
 > protocol-relative URLs in this situation, but it isn't clear to me how
 > widely-supported those are.
 >
+>> HTML5 says protocol-relative URLs work, and they seem to be widely
+>> supported in practice, so I've changed the rule to: if the url and cgiurl
+>> share a scheme (protocol) but differ only by hostname, use `//foo/bar`
+>> protocol-relative URLs. This partially addresses this todo.
+>> I'm still thinking about what the right thing is for more complicated
+>> situations: see [[todo/design for cross-linking between content and CGI]].
+>> --[[smcv]]
+>
 > If you set both the `$config{url}` and `$config{cgiurl}` to https, but make
 > the resulting HTML available over HTTP as well as HTTPS, that should work
 > fine - accesses will be over http until the user either explicitly
diff --git a/t/relativity.t b/t/relativity.t
index eb6cc44..6c4d110 100755
--- a/t/relativity.t
+++ b/t/relativity.t
@@ -227,13 +227,10 @@ run(["./t/tmp/ikiwiki.cgi"], \undef, \$content, init => sub {
 	$ENV{HTTPS} = 'on';
 });
 %bits = parse_cgi_content($content);
-TODO: {
-local $TODO = "avoid mixed content";
 like($bits{basehref}, qr{^https://static.example.com/$});
 like($bits{stylehref}, qr{^(?:(?:https:)?//static.example.com)?/style.css$});
 like($bits{tophref}, qr{^(?:https:)?//static.example.com/$});
 like($bits{cgihref}, qr{^(?:(?:https:)?//cgi.example.com)?/ikiwiki.cgi$});
-}
 
 # when accessed via a different hostname, links to the CGI (only) should
 # stay on that host?
diff --git a/t/urlto.t b/t/urlto.t
index 338632e..025409b 100755
--- a/t/urlto.t
+++ b/t/urlto.t
@@ -1,7 +1,7 @@
 #!/usr/bin/perl
 use warnings;
 use strict;
-use Test::More tests => 26;
+use Test::More tests => 31;
 
 BEGIN { use_ok("IkiWiki"); }
 
@@ -41,11 +41,20 @@ is(IkiWiki::urlto('', 'penguin/herring'), "../../");
 is(IkiWiki::cgiurl(cgiurl => 'https://foo/ikiwiki'), "https://foo/ikiwiki");
 is(IkiWiki::cgiurl(do => 'badger', cgiurl => 'https://foo/ikiwiki'), "https://foo/ikiwiki?do=badger");
 
-# with url and cgiurl on different sites, "local" degrades to absolute
+# with url and cgiurl on different sites, "local" degrades to protocol-relative
 $IkiWiki::config{url} = "http://example.co.uk/~smcv";
 $IkiWiki::config{cgiurl} = "http://dynamic.example.co.uk/~smcv/ikiwiki.cgi";
 is(IkiWiki::checkconfig(), 1);
-is(IkiWiki::cgiurl(), "http://dynamic.example.co.uk/~smcv/ikiwiki.cgi");
+is(IkiWiki::cgiurl(), "//dynamic.example.co.uk/~smcv/ikiwiki.cgi");
+is(IkiWiki::baseurl(undef), "//example.co.uk/~smcv/");
+is(IkiWiki::urlto('stoats', undef), "//example.co.uk/~smcv/stoats/");
+is(IkiWiki::urlto('', undef), "//example.co.uk/~smcv/");
+
+# with url and cgiurl on different schemes, "local" degrades to absolute
+$IkiWiki::config{url} = "http://example.co.uk/~smcv";
+$IkiWiki::config{cgiurl} = "https://dynamic.example.co.uk/~smcv/ikiwiki.cgi";
+is(IkiWiki::checkconfig(), 1);
+is(IkiWiki::cgiurl(), "https://dynamic.example.co.uk/~smcv/ikiwiki.cgi");
 is(IkiWiki::baseurl(undef), "http://example.co.uk/~smcv/");
 is(IkiWiki::urlto('stoats', undef), "http://example.co.uk/~smcv/stoats/");
 is(IkiWiki::urlto('', undef), "http://example.co.uk/~smcv/");

Force use of $config{url} as top URL in w3mmode
diff --git a/IkiWiki/CGI.pm b/IkiWiki/CGI.pm
index cb83319..b6f47a3 100644
--- a/IkiWiki/CGI.pm
+++ b/IkiWiki/CGI.pm
@@ -58,7 +58,10 @@ sub cgitemplate ($$$;@) {
 	
 	my $template=template("page.tmpl");
 
-	my $topurl = defined $cgi ? $cgi->url : $config{url};
+	my $topurl = $config{url};
+	if (defined $cgi && ! $config{w3mmode}) {
+		$topurl = $cgi->url;
+	}
 
 	my $page="";
 	if (exists $params{page}) {
diff --git a/doc/bugs/W3MMode_still_uses_http:__47____47__localhost__63__.mdwn b/doc/bugs/W3MMode_still_uses_http:__47____47__localhost__63__.mdwn
index 34eecef..c21329b 100644
--- a/doc/bugs/W3MMode_still_uses_http:__47____47__localhost__63__.mdwn
+++ b/doc/bugs/W3MMode_still_uses_http:__47____47__localhost__63__.mdwn
@@ -32,3 +32,5 @@ The problem is that IkiWiki::CGI::cgitemplate() and IkiWiki::CGI::redirect() use
 A quick workaround might be to force the use of $config{url} instead of $cgi->url as a base for URLs when w3mmode is set.
 
 -- Martin
+
+> [[Fixed|done]] --[[smcv]]
diff --git a/t/relativity.t b/t/relativity.t
index 8903d03..0f7d014 100755
--- a/t/relativity.t
+++ b/t/relativity.t
@@ -521,11 +521,8 @@ run(["./t/tmp/ikiwiki.cgi"], \undef, \$content, init => sub {
 %bits = parse_cgi_content($content);
 like($bits{tophref}, qr{^(?:\Q$pwd\E/t/tmp/out|\.)/$});
 like($bits{cgihref}, qr{^(?:file://)?/\$LIB/ikiwiki-w3m.cgi/ikiwiki.cgi$});
-TODO: {
-local $TODO = "should be file:///";
 like($bits{basehref}, qr{^(?:(?:file:)?//)?\Q$pwd\E/t/tmp/out/$});
 like($bits{stylehref}, qr{^(?:(?:(?:file:)?//)?\Q$pwd\E/t/tmp/out|\.)/style.css$});
-}
 
 #######################################################################
 # site 6: we're behind a reverse-proxy

Add WAI-ARIA roles to #main, #comments and #footer when in HTML5 mode
Based on a patch from Patrick.
diff --git a/doc/todo/add_aria_landmarks_to_make_ikiwiki_websites_more_accessible.mdwn b/doc/todo/add_aria_landmarks_to_make_ikiwiki_websites_more_accessible.mdwn
index a07cd84..d13fa0a 100644
--- a/doc/todo/add_aria_landmarks_to_make_ikiwiki_websites_more_accessible.mdwn
+++ b/doc/todo/add_aria_landmarks_to_make_ikiwiki_websites_more_accessible.mdwn
@@ -67,6 +67,8 @@ The `role` attribute is not allowed by the XHTML 1.0 Strict DTD, so we
 should only emit it in HTML5 mode (and we should probably
 [[todo/generate_HTML5_by_default]]).
 
+Specific roles:
+
 [[!format diff """
 -<div class="banner">
 +<div class="banner" role="banner">
@@ -86,4 +88,8 @@ reasonable guess. I would hope that the fact that it's an `<aside>`
 in HTML5 mode is enough to give accessibility tools a clue already?
 Would declaring this to be a `note` be sufficient?
 
+I've applied your suggested roles for #main, #comments and #footer,
+but only in HTML5 mode for the reason given above. I have not applied
+a role to the sidebar just yet.
+
 --[[smcv]]
diff --git a/templates/page.tmpl b/templates/page.tmpl
index c886b22..c709c4f 100644
--- a/templates/page.tmpl
+++ b/templates/page.tmpl
@@ -134,7 +134,7 @@
 
 <div id="pagebody">
 
-<TMPL_IF HTML5><section id="content"><TMPL_ELSE><div id="content"></TMPL_IF>
+<TMPL_IF HTML5><section id="content" role="main"><TMPL_ELSE><div id="content"></TMPL_IF>
 <TMPL_VAR CONTENT>
 <TMPL_IF HTML5></section><TMPL_ELSE></div></TMPL_IF>
 
@@ -146,7 +146,7 @@
 
 <TMPL_UNLESS DYNAMIC>
 <TMPL_IF COMMENTS>
-<TMPL_IF HTML5><section id="comments"><TMPL_ELSE><div id="comments"></TMPL_IF>
+<TMPL_IF HTML5><section id="comments" role="complementary"><TMPL_ELSE><div id="comments"></TMPL_IF>
 <TMPL_VAR COMMENTS>
 <TMPL_IF ADDCOMMENTURL>
 <div class="addcomment">
@@ -161,7 +161,7 @@
 
 </div>
 
-<TMPL_IF HTML5><footer id="footer" class="pagefooter"><TMPL_ELSE><div id="footer" class="pagefooter"></TMPL_IF>
+<TMPL_IF HTML5><footer id="footer" class="pagefooter" role="contentinfo"><TMPL_ELSE><div id="footer" class="pagefooter"></TMPL_IF>
 <TMPL_UNLESS DYNAMIC>
 <TMPL_IF HTML5><nav id="pageinfo"><TMPL_ELSE><div id="pageinfo"></TMPL_IF>
 

add the beginnings of a test for CGI/static URL interactions
diff --git a/doc/todo/design_for_cross-linking_between_content_and_CGI.mdwn b/doc/todo/design_for_cross-linking_between_content_and_CGI.mdwn
index 64b3e84..7c920f0 100644
--- a/doc/todo/design_for_cross-linking_between_content_and_CGI.mdwn
+++ b/doc/todo/design_for_cross-linking_between_content_and_CGI.mdwn
@@ -109,3 +109,10 @@ in the setup file as http if you intend that they will most commonly
 be accessed via http (e.g. the "my cert is not CA-cartel approved"
 use-case), or as https if you intend to force accesses into
 being via https (the "my wiki is secret" use-case).
+
+# Regression test
+
+I've added a regression test in `t/relativity.t`. We might want to
+consider dropping some of it or skipping it unless a special environment
+variable is set once this is all working, since it's a bit slow.
+--[[smcv]]
diff --git a/t/relativity.t b/t/relativity.t
new file mode 100755
index 0000000..ca1664f
--- /dev/null
+++ b/t/relativity.t
@@ -0,0 +1,601 @@
+#!/usr/bin/perl
+use warnings;
+use strict;
+
+use Cwd qw(getcwd);
+use Errno qw(ENOENT);
+
+BEGIN {
+	if (!eval q{
+		use IPC::Run qw(run);
+		1;
+	}) {
+		eval q{use Test::More skip_all => "IPC::Run not available"};
+	}
+	else {
+		eval q{use Test::More};
+	}
+	use_ok("IkiWiki");
+}
+
+my $pwd = getcwd();
+
+# Black-box (ish) test for relative linking between CGI and static content
+
+my $blob;
+my ($content, $in, %bits);
+
+sub parse_cgi_content {
+	my %bits;
+	if ($content =~ qr{<base href="([^"]+)" */>}) {
+		$bits{basehref} = $1;
+	}
+	if ($content =~ qr{href="([^"]+/style.css)"}) {
+		$bits{stylehref} = $1;
+	}
+	if ($content =~ qr{class="parentlinks">\s+<a href="([^"]+)">this is the name of my wiki</a>/}s) {
+		$bits{tophref} = $1;
+	}
+	if ($content =~ qr{<a[^>]+href="([^"]+)\?do=prefs"}) {
+		$bits{cgihref} = $1;
+	}
+	return %bits;
+}
+
+ok(! system("make -s ikiwiki.out"));
+ok(! system("rm -rf t/tmp"));
+ok(! system("mkdir t/tmp"));
+
+sub write_old_file {
+	my $name = shift;
+	my $content = shift;
+
+	writefile($name, "t/tmp/in", $content);
+	ok(utime(333333333, 333333333, "t/tmp/in/$name"));
+}
+
+write_old_file("a.mdwn", "A");
+write_old_file("a/b.mdwn", "B");
+write_old_file("a/b/c.mdwn",
+"* A: [[a]]\n".
+"* B: [[b]]\n".
+"* E: [[a/d/e]]\n");
+write_old_file("a/d.mdwn", "D");
+write_old_file("a/d/e.mdwn", "E");
+
+#######################################################################
+# site 1: a perfectly ordinary ikiwiki
+
+writefile("test.setup", "t/tmp", <<EOF
+# IkiWiki::Setup::Yaml - YAML formatted setup file
+wikiname: this is the name of my wiki
+srcdir: t/tmp/in
+destdir: t/tmp/out
+templatedir: templates
+url: "http://example.com/wiki/"
+cgiurl: "http://example.com/cgi-bin/ikiwiki.cgi"
+cgi_wrapper: t/tmp/ikiwiki.cgi
+cgi_wrappermode: 0754
+# make it easier to test previewing
+add_plugins:
+- anonok
+anonok_pagespec: "*"
+EOF
+);
+
+ok(unlink("t/tmp/ikiwiki.cgi") || $!{ENOENT});
+ok(! system("./ikiwiki.out --setup t/tmp/test.setup --rebuild --wrappers"));
+
+# CGI wrapper should be exactly the requested mode
+my (undef, undef, $mode, undef, undef,
+	undef, undef, undef, undef, undef,
+	undef, undef, undef) = stat("t/tmp/ikiwiki.cgi");
+is($mode & 07777, 0754);
+
+ok(-e "t/tmp/out/a/b/c/index.html");
+$content = readfile("t/tmp/out/a/b/c/index.html");
+# no <base> on static HTML
+unlike($content, qr{<base\W});
+# url and cgiurl are on the same host so the cgiurl is host-relative
+like($content, qr{<a[^>]+href="/cgi-bin/ikiwiki.cgi\?do=prefs"});
+# cross-links between static pages are relative
+like($content, qr{<li>A: <a href="../../">a</a></li>});
+like($content, qr{<li>B: <a href="../">b</a></li>});
+like($content, qr{<li>E: <a href="../../d/e/">e</a></li>});
+
+run(["./t/tmp/ikiwiki.cgi"], \undef, \$content, init => sub {
+	$ENV{REQUEST_METHOD} = 'GET';
+	$ENV{SERVER_PORT} = '80';
+	$ENV{SCRIPT_NAME} = '/cgi-bin/ikiwiki.cgi';
+	$ENV{QUERY_STRING} = 'do=prefs';
+	$ENV{HTTP_HOST} = 'example.com';
+});
+%bits = parse_cgi_content($content);
+is($bits{basehref}, "http://example.com/wiki/");
+like($bits{stylehref}, qr{^(?:(?:http:)?//example.com)?/wiki/style.css$});
+like($bits{tophref}, qr{^(?:/wiki|\.)/$});
+like($bits{cgihref}, qr{^(?:(?:http:)?//example.com)?/cgi-bin/ikiwiki.cgi$});
+
+# when accessed via HTTPS, links are secure
+run(["./t/tmp/ikiwiki.cgi"], \undef, \$content, init => sub {
+	$ENV{REQUEST_METHOD} = 'GET';
+	$ENV{SERVER_PORT} = '443';
+	$ENV{SCRIPT_NAME} = '/cgi-bin/ikiwiki.cgi';
+	$ENV{QUERY_STRING} = 'do=prefs';
+	$ENV{HTTP_HOST} = 'example.com';
+	$ENV{HTTPS} = 'on';
+});
+%bits = parse_cgi_content($content);
+is($bits{basehref}, "https://example.com/wiki/");
+like($bits{stylehref}, qr{^(?:(?:https:)?//example.com)?/wiki/style.css$});
+like($bits{tophref}, qr{^(?:/wiki|\.)/$});
+like($bits{cgihref}, qr{^(?:(?:https:)?//example.com)?/cgi-bin/ikiwiki.cgi$});
+
+# when accessed via a different hostname, links stay on that host
+run(["./t/tmp/ikiwiki.cgi"], \undef, \$content, init => sub {
+	$ENV{REQUEST_METHOD} = 'GET';
+	$ENV{SERVER_PORT} = '80';
+	$ENV{SCRIPT_NAME} = '/cgi-bin/ikiwiki.cgi';
+	$ENV{QUERY_STRING} = 'do=prefs';
+	$ENV{HTTP_HOST} = 'staging.example.net';
+});
+%bits = parse_cgi_content($content);
+is($bits{basehref}, "http://staging.example.net/wiki/");
+like($bits{stylehref}, qr{^(?:(?:http:)?//staging.example.net)?/wiki/style.css$});
+like($bits{tophref}, qr{^(?:/wiki|\.)/$});
+like($bits{cgihref}, qr{^(?:(?:http:)?//staging.example.net)?/cgi-bin/ikiwiki.cgi$});
+
+# previewing a page
+$in = 'do=edit&page=a/b/c&Preview';
+run(["./t/tmp/ikiwiki.cgi"], \$in, \$content, init => sub {
+	$ENV{REQUEST_METHOD} = 'POST';
+	$ENV{SERVER_PORT} = '80';
+	$ENV{SCRIPT_NAME} = '/cgi-bin/ikiwiki.cgi';
+	$ENV{HTTP_HOST} = 'example.com';
+	$ENV{CONTENT_LENGTH} = length $in;
+});
+%bits = parse_cgi_content($content);
+is($bits{basehref}, "http://example.com/wiki/a/b/c/");
+like($bits{stylehref}, qr{^(?:(?:http:)?//example.com)?/wiki/style.css$});
+like($bits{tophref}, qr{^(?:/wiki|\.\./\.\./\.\.)/$});
+like($bits{cgihref}, qr{^(?:(?:http:)?//example.com)?/cgi-bin/ikiwiki.cgi$});
+
+#######################################################################
+# site 2: static content and CGI are on different servers
+
+writefile("test.setup", "t/tmp", <<EOF
+# IkiWiki::Setup::Yaml - YAML formatted setup file
+wikiname: this is the name of my wiki
+srcdir: t/tmp/in
+destdir: t/tmp/out
+templatedir: templates
+url: "http://static.example.com/"
+cgiurl: "http://cgi.example.com/ikiwiki.cgi"
+cgi_wrapper: t/tmp/ikiwiki.cgi
+cgi_wrappermode: 0754
+# make it easier to test previewing
+add_plugins:
+- anonok
+anonok_pagespec: "*"

(Diff truncated)
review
diff --git a/doc/todo/add_aria_landmarks_to_make_ikiwiki_websites_more_accessible.mdwn b/doc/todo/add_aria_landmarks_to_make_ikiwiki_websites_more_accessible.mdwn
index f8e38a4..a07cd84 100644
--- a/doc/todo/add_aria_landmarks_to_make_ikiwiki_websites_more_accessible.mdwn
+++ b/doc/todo/add_aria_landmarks_to_make_ikiwiki_websites_more_accessible.mdwn
@@ -1,5 +1,7 @@
 Here is a patch for page.tmpl to add these landmarks.
 
+--[Patrick](https://www.google.com/accounts/o8/id?id=AItOawlnBLXDQbzD3OCcqZshcmExPNwlgD0tJ7A)
+
 > This can't be applied as a patch as-is because it's based on Tails'
 > modified `page.tmpl`, but I get the general idea. A reviewer will need
 > to check the ARIA meanings of those roles to confirm that they
@@ -53,3 +55,35 @@ index 5efad1a..cb76590 100644
  <TMPL_IF HTML5><nav id="pageinfo"><TMPL_ELSE><div id="pageinfo"></TMPL_IF>
  
 """]]
+
+----
+
+Here is a review. Please "sign" any responses so we can keep track of
+who is talking to who :-)
+
+General points:
+
+The `role` attribute is not allowed by the XHTML 1.0 Strict DTD, so we
+should only emit it in HTML5 mode (and we should probably
+[[todo/generate_HTML5_by_default]]).
+
+[[!format diff """
+-<div class="banner">
++<div class="banner" role="banner">
+"""]]
+
+There is no such class in IkiWiki's page.tmpl, so this part can't be applied.
+After this is applied to the main IkiWiki, you'll need to talk to the
+maintainers of the Tails wiki about changing that in their fork of the template.
+
+[[!format diff """
+-<TMPL_IF HTML5><aside class="sidebar"><TMPL_ELSE><div class="sidebar"></TMPL_IF>
++<TMPL_IF HTML5><aside class="sidebar" role="navigation"><TMPL_ELSE><div class="sidebar" role="navigation"></TMPL_IF>
+"""]]
+
+I don't think the sidebar is *necessarily* navigation, although it's a
+reasonable guess. I would hope that the fact that it's an `<aside>`
+in HTML5 mode is enough to give accessibility tools a clue already?
+Would declaring this to be a `note` be sufficient?
+
+--[[smcv]]

new
diff --git a/doc/todo/generate_HTML5_by_default.mdwn b/doc/todo/generate_HTML5_by_default.mdwn
new file mode 100644
index 0000000..3adce8c
--- /dev/null
+++ b/doc/todo/generate_HTML5_by_default.mdwn
@@ -0,0 +1,33 @@
+The `html5` option was added in 2010 and marked as "not experimental" in 2011
+but is not the default.
+
+According to <http://caniuse.com/#feat=html5semantic>, current versions of
+all recent versions of all major browsers - even IE - support the HTML5
+semantic elements (`<section>` etc.), except for `<main>` which IkiWiki
+doesn't use anyway. With that being the case, I'm not sure whether we gain
+anything from not generating HTML5 (or "HTML" as it's now labelled) all the time.
+
+In particular, non-HTML5 mode uses `<!DOCTYPE html PUBLIC
+"-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">`
+which doesn't allow newer markup like the `role` attribute, so we can't close
+[[todo/add_aria_landmarks_to_make_ikiwiki_websites_more_accessible]] while
+remaining XHTML 1.0 Strict. The recommended pseudo-doctype for HTML5, and for
+HTML with ARIA markup, is `<!DOCTYPE html>`.
+
+(I do think we should continue to use `<xml-compatible-tags />` and output
+well-formed XML so people who want to do XSLT tricks with IkiWiki's output
+can do so, though.)
+
+In practice, real browsers have never actually implemented a strict XHTML mode:
+they've always parsed `text/html` as "tag soup", because they need a tag-soup
+parser anyway, and nobody wants to maintain two parsers.
+
+Options include:
+
+* set html5 to 1 by default but retain the dual-mode templates
+* remove the option and always behave as if it had been 1, simplifying
+  the templates
+
+Thoughts?
+
+--[[smcv]]

clarify
diff --git a/doc/bugs/escaped_style_tag_becomes_elyts.mdwn b/doc/bugs/escaped_style_tag_becomes_elyts.mdwn
index b7aa659..7095425 100644
--- a/doc/bugs/escaped_style_tag_becomes_elyts.mdwn
+++ b/doc/bugs/escaped_style_tag_becomes_elyts.mdwn
@@ -15,8 +15,10 @@ or use indentation like
     &lt;style type="text/css"&gt;...&lt;/style&gt;
 </code></pre>
 
-then that gets turned into `&lt;elyts` in the HTML too. This makes it quite
-difficult to talk about HTML on an IkiWiki instance (I had to use raw HTML in
+then that gets turned into `<elyts` in the source before passing through
+`markdown`, comes out as `&lt;elyts` in the output HTML, and is rendered
+as `<elyts` by the browser. This makes it quite difficult to talk about
+HTML stylesheet markup on an IkiWiki instance (I had to use raw HTML in
 this bug report's source to avoid the bug).
 
 I think the side-effect of the workaround is more damaging than the actual bug

mix markdown with HTML more correctly
diff --git a/doc/bugs/escaped_style_tag_becomes_elyts.mdwn b/doc/bugs/escaped_style_tag_becomes_elyts.mdwn
index 24d8fbf..b7aa659 100644
--- a/doc/bugs/escaped_style_tag_becomes_elyts.mdwn
+++ b/doc/bugs/escaped_style_tag_becomes_elyts.mdwn
@@ -7,7 +7,7 @@ $r=~s/&lt;elyts/&lt;style/ig;
 </code></pre>
 
 However, this workaround also applies to indented text or text in backticks:
-if you write <code>there is a bug involving the `&lt;style&gt;` tag</code>,
+if you write <code>there is a bug involving the \`&lt;style&gt;\` tag</code>,
 or use indentation like
 
 <pre><code>you can use this markup:

new bug report
diff --git a/doc/bugs/escaped_style_tag_becomes_elyts.mdwn b/doc/bugs/escaped_style_tag_becomes_elyts.mdwn
new file mode 100644
index 0000000..24d8fbf
--- /dev/null
+++ b/doc/bugs/escaped_style_tag_becomes_elyts.mdwn
@@ -0,0 +1,28 @@
+When IkiWiki uses discount to implement [[plugins/mdwn]] rendering,
+there is a workaround for <https://rt.cpan.org/Ticket/Display.html?id=74016>:
+
+<pre><code>$t=~s/&lt;style/&lt;elyts/ig;
+my $r=Text::Markdown::Discount::markdown($t);
+$r=~s/&lt;elyts/&lt;style/ig;
+</code></pre>
+
+However, this workaround also applies to indented text or text in backticks:
+if you write <code>there is a bug involving the `&lt;style&gt;` tag</code>,
+or use indentation like
+
+<pre><code>you can use this markup:
+
+    &lt;style type="text/css"&gt;...&lt;/style&gt;
+</code></pre>
+
+then that gets turned into `&lt;elyts` in the HTML too. This makes it quite
+difficult to talk about HTML on an IkiWiki instance (I had to use raw HTML in
+this bug report's source to avoid the bug).
+
+I think the side-effect of the workaround is more damaging than the actual bug
+being worked around: I've never wanted to write inline style tags in the body of
+a Markdown page (which isn't even valid HTML) but I have certainly wanted to
+discuss style markup several times. The first couple of times I saw this happen,
+I thought it was some sort of misguided anti-cross-site-scripting filter...
+
+--[[smcv]]

amend comment
diff --git a/doc/forum/Export_images_when_building_the_wiki/comment_5_7e0a6336c6a6785d9cf4b6b4b124fd6d._comment b/doc/forum/Export_images_when_building_the_wiki/comment_5_7e0a6336c6a6785d9cf4b6b4b124fd6d._comment
index 81ea1b4..068d49e 100644
--- a/doc/forum/Export_images_when_building_the_wiki/comment_5_7e0a6336c6a6785d9cf4b6b4b124fd6d._comment
+++ b/doc/forum/Export_images_when_building_the_wiki/comment_5_7e0a6336c6a6785d9cf4b6b4b124fd6d._comment
@@ -18,6 +18,8 @@ In setup file, you specify which command is to be applied to files. For instance
 
 Then, in your wiki pages, you can use `\[[!compile files=\"foo.odt\"]]`. This will convert file to pdf, and render as a link to the `pdf` file. If option `inline` is set, you can also simply use a wikilink `\[[foo.odt]]`, which will have the same effect.
 
+The only problem I see is that when linking several times to the same file, it will be compiled several times. I marked it as [[a feature request|http://atelier.gresille.org/issues/420]] to the plugin.
+
 Regards,    
 -- [[Louis|spalax]]
 

Added a comment: Plugin compile
diff --git a/doc/forum/Export_images_when_building_the_wiki/comment_5_7e0a6336c6a6785d9cf4b6b4b124fd6d._comment b/doc/forum/Export_images_when_building_the_wiki/comment_5_7e0a6336c6a6785d9cf4b6b4b124fd6d._comment
new file mode 100644
index 0000000..81ea1b4
--- /dev/null
+++ b/doc/forum/Export_images_when_building_the_wiki/comment_5_7e0a6336c6a6785d9cf4b6b4b124fd6d._comment
@@ -0,0 +1,24 @@
+[[!comment format=mdwn
+ username="spalax"
+ ip="82.233.196.200"
+ subject="Plugin compile"
+ date="2014-10-04T10:37:16Z"
+ content="""
+Hello,
+I enventually wrote a plugin that might fit your need: [[plugins/contrib/compile]].
+
+In setup file, you specify which command is to be applied to files. For instance, to convent `odt` files to `pdf`, you can use:
+
+    compile_filetypes = '
+        \"odt\": {
+          \"build\": \"libreoffice --headless --convert-to pdf %{srcname}s\",
+          \"destname\": \"%{basename}s.pdf\"
+        }
+      }'
+
+Then, in your wiki pages, you can use `\[[!compile files=\"foo.odt\"]]`. This will convert file to pdf, and render as a link to the `pdf` file. If option `inline` is set, you can also simply use a wikilink `\[[foo.odt]]`, which will have the same effect.
+
+Regards,    
+-- [[Louis|spalax]]
+
+"""]]

New contrib plugin: compile
diff --git a/doc/plugins/contrib/compile.mdwn b/doc/plugins/contrib/compile.mdwn
new file mode 100644
index 0000000..7ae4968
--- /dev/null
+++ b/doc/plugins/contrib/compile.mdwn
@@ -0,0 +1,208 @@
+[[!meta author="spalax"]]
+[[!template id=plugin name=compile author="[[Louis|spalax]]"]]
+
+# Compile
+
+The compile plugin provides the `compile` directive, used to on-the-fly compile
+and publish documents.
+
+For instance, if you want to publish files together with their sources (like
+`.tex` and `.pdf` files), you can have the `.tex` file in your source wiki
+directory, and command `\[[!compile files="foo.tex"]]` (or wikilink
+`\[[foo.tex]]`, if the right option is set) will compile file and render as a
+link to the `.pdf` file.
+
+[[!toc startlevel=2]]
+
+## Warning
+
+Some important security notice.
+
+- This plugins allows user to execute arbitrary commands when compiling the
+  wiki.  Use at your own risk. If you use Ikiwiki as a static web site compiler
+  (and not a wiki), and you are the only one to compile the wiki, there is no
+  risk.
+
+- Source files are published, wheter option `source` is true or not. If
+  `source` is false, source may not be *advertised*, but it is still available
+  somewhere on your website (most likely by replacing in the compiled file URL
+  the extension of the compiled file by the extension of the source file). So,
+  do not use this plugin if you do not want to publish your source files
+    (sorry: I designed this plugin to publish free stuff).
+
+## Rationale
+
+I want to publish some latex files, both source (`.tex`) and compiled (`.pdf`)
+version, but I do not want to maintain two versions of the same file.
+
+Using this plugin, I only have to maintain the `.tex` files, and thoses files
+are compiled on the fly, so that the `pdf` is published.
+
+## String formatting
+
+Strings (destination name, template name and build command) accept python-like
+syntax ``%{name}s``, which is replaced by the value of variable ``name``. The
+following variables are abailable.
+
+- `srcname`: Source name.
+- `srcextension`: Extension of the source name.
+- `filetype`: File type (extension of the source name, otherwise specified by directive).
+- `dirname`: Directory of the source file.
+- `wikiname`: Name of source file, relative to source wiki directory.
+- `srcfullname`: Name of source file, relative to file system root.
+- `basename`: Source name, without directory nor extension.
+- `destname`: Destination name (without directory).
+- `destextension`: Extension of the destination name.
+- `targetname`: Destination name, relative to the destination directory.
+- `destfullname`: Destination name, relative to file system root.
+
+## Directive
+
+### Usage
+
+Basic usage of this plugin is:
+
+    \[[!compile files="foo.ext"]]
+
+It renders file `foo.ext` according to rules defined in the setup file, and
+publish the compiled version.
+
+### Arguments
+
+All the arguments (but `source` and `filetype`) are string which are processed
+using python-like string formatting, and described in the setup options section.
+
+- `files`: List of files used in compilation, as space separated string. For
+  instance, to compile some tex file including a png image, you will have:
+  `files="foo.tex image.png"`. It is not possible to have filenames containing
+  spaces (unless you provide me a patch to recognize escaped spaces).
+- `filetype`: By default, the source file extension is used to determine build
+  command and other configuration. If the same extension refer to different
+  type of files, you can enforce the filetype using this argument. For
+  instance, if some your LaTeX files have to be compiled with `pdflatex`, while
+  the other require `latex`, your `compile_filetypes` can contains two keys
+  `tex` and `texdvi`. By default, LaTeX files will be compiled using
+  configuration associated to `tex`, unless directive has argument
+  `filetype=texdvi`, in which case the latter configuration is used.
+- `destname`: Name of the compiled file name.
+- `build`: Build command.
+- `source`: Boolean to choose whether to publish source file or not. The only
+  effect is the template choice: source is always published (but not always
+  advertised).
+- `template`: Name of the template to use (if set, the `source` option is
+  irrelevant).
+
+### Extensions
+
+Note: This directive does not work if source file name does not have an
+extension (i.e. does not contain a dot). This should not be too hard to
+implement, but I do not need it. Patches welcome.
+
+## Configuration
+
+Here are the setup options (most of them can be overloaded on a per-extension
+basis by setup option `compile_filetypes`, or by directive arguments):
+
+- `compile_source` (boolean): should sources be published with compiled file
+  (this only affect template choice; see warning)? Default is true.
+- `compile_template_source` (string): name of the template to use for compiled
+  files when option `source` is true. Default is `compile_source.tmpl`.
+- `compile_template_nosource` (string): name of the template to use for
+  compiled files when option `source` is false. Default is
+  `compile_nosource.tmpl`.
+- `compile_filetypes` (string): Per extension configuration (see paragraph
+  below).
+- `compile_tmpdir` (string): Path of a directory to use to compile files:
+  source file (and dependency) are copied to this directory before being
+  compiled (to avoid messing the ikiwiki directory with compiled version or
+  auxiliary files). Default is `SOURCE_WIKI/.ikwiki/tmp/compile`.
+- `compile_bindir` (string): Directory containing binaries to use to compile
+  files. Default is undefined.
+- `compile_depends` (string): List of files all compiled files will depend on
+  (see *Compilation* section below).
+- `compile_build` (string): Command to use to compile files. Default
+  is undefined.
+- `compile_inline` (boolean): If true, wikilinks pointing to files with an
+  extension specified in `compile_filetypes` are treated as a directive
+  \[[!compile files="LINK"]]. For instance, if this is set globally (or just
+  for tex), a wikilink \[[foo.tex]] will compile file `foo.tex`, and publish
+  the compiled `foo.pdf` file.
+
+### The `compile_filetypes` option
+
+This variable is a json string, representing a dictionary. Keys are source file
+extensions, values are dictionary of options applying only to files with this
+extension.
+
+Keys of these new directory are `source`, `template_nosource`,
+`template_source`, `build`, `depends`, `inline`, and overrides generic options
+defined above. They are themselves overriden by directive arguments (excepted
+`inline`).
+
+Example:
+
+    compile_filetypes => '{
+      "tex": {
+        "build": "pdflatex %{basename}s",
+        "destname": "%{basename}s.pdf",
+        "depends": ["logo.png"],
+        "inline": "1"
+      },
+      "texdvi": {
+        "build": "latex %{basename}s",
+        "destname": "%{basename}s.pdf",
+        "depends": ["logo.eps"]
+      }
+    }'
+
+## Compilation
+
+### Dependencies
+
+Before compilation, the source file and all dependencies are copied to the
+temporary directory defined by option `compile_tmpdir`. For instance, if all
+you LaTeX files are compiled using a custom class `foo.sty`, and a particular
+file `bar.tex` uses the `logo.png` file, your setup option will contain
+`foo.sty` as `depends`, and `compile` directive will be called using
+`\[[!compile files="bar.tex logo.png"]]`. Then, before compilation, files
+`foo.sty`, `bar.tex` and `logo.png` will be copied in the same temporary
+directory.
+
+Note that path are *flattened* when copied: before performing compilation of
+directive `\[[!compile files="sub1/foo sub2/bar"]]`, files `foo` and `bar` will
+be copied in the same directory: this temporary directory will contain failes
+`foo` and `bar`, but not `sub1/foo` and `sub2/bar`.
+
+### Build command
+
+The build command used is (if defined, by priority order):
+
+- defined by argument `build` of directive;
+- setup command ``compile_filetypes{TYPE}{build}``;
+- setup command ``compile_build`` (if you have a generic build command);
+- command ``$config{compile_bindir}/${extension}s %{srcname}s`` (if setup variable ``compile_bindir``is defined, is a directory, and contains an executable file matching the extension, it will be used);
+- command ``make -f $config{compile_bindir}/make.${extension}s %{destname}s`` (if setup variable ``compile_bindir`` is defined, is a directory, and contains a readable makefile ``make.EXTENSION``, it will be used).
+
+## Template
+
+The way links are rendered is defined in a template, which is (by order of
+priority, some of them depends on whether ``source`` is true):
+
+- argument `template` of directive;
+- setup variable ``compile_filetypes{TYPE}{template_source}`` or ``compile_filetypes{TYPE}{template_nosource}``;
+- setup variable ``compile_source`` or ``compile_nosource``;
+- `compile_source.mdwn` or `compile_nosource.mdwn`.

(Diff truncated)
d and r aren't even on the same row
diff --git a/doc/todo/remove_Google_from_OpenID_selector_unless_grandfathered.mdwn b/doc/todo/remove_Google_from_OpenID_selector_unless_grandfathered.mdwn
index 2dfee8e..87b82fe 100644
--- a/doc/todo/remove_Google_from_OpenID_selector_unless_grandfathered.mdwn
+++ b/doc/todo/remove_Google_from_OpenID_selector_unless_grandfathered.mdwn
@@ -4,7 +4,7 @@ seen by Google in at least one request by 19 May 2014, or whose admins had email
 request an extension by 15 June 2014 ... this according to Miguel Andres's answer on
 [this thread](http://stackoverflow.com/questions/23773275/changed-domain-error-openid-auth-request-contains-an-unregistered-domain).
 
-Google will not work as an OpenID provided for any ikiwiki set up since that time.
+Google will not work as an OpenID provider for any ikiwiki set up since that time.
 
 So, probably that Google option shouldn't be in the OpenID selector; maybe there
 should be an option: default _off_, can be turned _on_ for an established ikiwiki

Google stay of execution no comfort if you're already dead
diff --git a/doc/todo/remove_Google_from_OpenID_selector_unless_grandfathered.mdwn b/doc/todo/remove_Google_from_OpenID_selector_unless_grandfathered.mdwn
new file mode 100644
index 0000000..2dfee8e
--- /dev/null
+++ b/doc/todo/remove_Google_from_OpenID_selector_unless_grandfathered.mdwn
@@ -0,0 +1,13 @@
+The [stay of execution](http://source.ikiwiki.branchable.com/?p=source.git;a=commit;h=6660fd643bf3b65745d62b24cb16fef1b5205207) of Google's OpenID support, possibly until 2017,
+_only_ applies to ikiwikis that had already been live and whose `openid_realm`s had been
+seen by Google in at least one request by 19 May 2014, or whose admins had emailed Google to
+request an extension by 15 June 2014 ... this according to Miguel Andres's answer on
+[this thread](http://stackoverflow.com/questions/23773275/changed-domain-error-openid-auth-request-contains-an-unregistered-domain).
+
+Google will not work as an OpenID provided for any ikiwiki set up since that time.
+
+So, probably that Google option shouldn't be in the OpenID selector; maybe there
+should be an option: default _off_, can be turned _on_ for an established ikiwiki
+instance that is known to be grandfathered.
+
+-- [[jcflack]]

many people grok "static site generator" nowadays
diff --git a/doc/index.mdwn b/doc/index.mdwn
index 89802c6..f4073aa 100644
--- a/doc/index.mdwn
+++ b/doc/index.mdwn
@@ -5,6 +5,9 @@ There are many other [[features]], including support for
 [[blogging|blog]] and [[podcasting|podcast]], as well as a large
 array of [[plugins]].
 
+Alternatively, think of ikiwiki as a particularly flexible static
+site generator with some dynamic features.
+
 [[!template id=links]]
 
 ## using ikiwiki

testing the sandbox
diff --git a/doc/sandbox.mdwn b/doc/sandbox.mdwn
index f9fa321..451d77e 100644
--- a/doc/sandbox.mdwn
+++ b/doc/sandbox.mdwn
@@ -1,4 +1,3 @@
-
 This is the [[SandBox]], a page anyone can edit to try out ikiwiki
 (version [[!version  ]]).
 
@@ -120,4 +119,5 @@ Räksmörgås.
 
 `pre?`
 
+Testing. Test. 
 

recap of yamlfront issue opened on github
diff --git a/doc/plugins/contrib/ymlfront/discussion.mdwn b/doc/plugins/contrib/ymlfront/discussion.mdwn
index b122294..868e9cd 100644
--- a/doc/plugins/contrib/ymlfront/discussion.mdwn
+++ b/doc/plugins/contrib/ymlfront/discussion.mdwn
@@ -1,3 +1,29 @@
+I have just opened [rubykat/ikiplugins issue #4](https://github.com/rubykat/ikiplugins/issues/4)
+regarding the fact that ymlfront doesn't seem to delete any old pagestate when fields have been
+removed in an edit. The fields are stuck there with their old values until a full rebuild. Seems
+to me ymlfront should just clear out all of the `{ymlfront}` pagestate before parsing the new
+stuff - including in the case where the new page has no ymlfront section at all.
+
+I discovered another slightly-different-but-related issue where simply _changing_ a field value
+in the YAML section doesn't always cause the generated HTML to be updated. Oddly, ikiwiki will
+_say_ it's building the page, but when you look at the HTML output, it's the old content.
+
+Could this involve some clever optimization where ikiwiki looks at the content (that's left over
+after ymlfront stripped out the YAML) and sees it hasn't changed? Does ymlfront need to do
+something more to indicate there is a change? Does the _template_ need to somehow be declared
+to depend on more stuff?
+
+As I said, the log does have a line for 'building' the page, so whatever optimization is happening
+must come later than the determination of what pages to 'build'.
+
+I'm mentioning it here because I'm not sure whether this or the issue on github will be seen
+first - there's a pretty old one open there. This seems to be quite
+potentially useful stuff that never quite got finished - is [[KathrynAndersen]] still
+interested? -- [[jcflack]]
+
+----
+Previous discussion re: delimiters
+
 Now that I have implemented a \[[!ymlfront ...]] directive, I would like to remove support for the old "---" delimited format, because
 
 * it is fragile (easily breakable)

I'm not really anti-vowel
diff --git a/doc/todo/make_localstyle__44___pagetemplate__44___edittemplate_more_similar__63__.mdwn b/doc/todo/make_localstyle__44___pagetemplate__44___edittemplate_more_similar__63__.mdwn
index 78a3cf4..6ac5100 100644
--- a/doc/todo/make_localstyle__44___pagetemplate__44___edittemplate_more_similar__63__.mdwn
+++ b/doc/todo/make_localstyle__44___pagetemplate__44___edittemplate_more_similar__63__.mdwn
@@ -11,7 +11,7 @@ of a site:
 That last is the one that seems least useful. The [[ikiwiki/PageSpec]] approach seems
 most flexible.
 
-Would it be a bad thing to allow `pagetemplate` to work the way `edittmplate` does?
+Would it be a bad thing to allow `pagetemplate` to work the way `edittemplate` does?
 Maybe just extend the existing directive? If it has a `pages` parameter, it specifies
 the template for the supplied [[ikiwiki/PageSpec]], otherwise it just affects the enclosing page
 as it does now?

a wish for more from pagetemplate
diff --git a/doc/todo/make_localstyle__44___pagetemplate__44___edittemplate_more_similar__63__.mdwn b/doc/todo/make_localstyle__44___pagetemplate__44___edittemplate_more_similar__63__.mdwn
new file mode 100644
index 0000000..78a3cf4
--- /dev/null
+++ b/doc/todo/make_localstyle__44___pagetemplate__44___edittemplate_more_similar__63__.mdwn
@@ -0,0 +1,19 @@
+If I'm reading the docs right, I count three different ways
+of associating some local styling information with a portion
+of a site:
+
+* [[plugins/localstyle]] uses the [[ikiwiki/subpage/LinkingRules]] to find the 'nearest' stylesheet
+* [[plugins/edittemplate]] uses a directive with a [[ikiwiki/PageSpec]] to indicate which
+    pages should get which templates
+* [[plugins/pagetemplate]] doesn't do a thing for you unless you shoehorn a
+    `pagetemplate` directive into every affected page.
+
+That last is the one that seems least useful. The [[ikiwiki/PageSpec]] approach seems
+most flexible.
+
+Would it be a bad thing to allow `pagetemplate` to work the way `edittmplate` does?
+Maybe just extend the existing directive? If it has a `pages` parameter, it specifies
+the template for the supplied [[ikiwiki/PageSpec]], otherwise it just affects the enclosing page
+as it does now?
+
+--Chap

typo
diff --git a/doc/todo/add_aria_landmarks_to_make_ikiwiki_websites_more_accessible.mdwn b/doc/todo/add_aria_landmarks_to_make_ikiwiki_websites_more_accessible.mdwn
index 16fb745..f8e38a4 100644
--- a/doc/todo/add_aria_landmarks_to_make_ikiwiki_websites_more_accessible.mdwn
+++ b/doc/todo/add_aria_landmarks_to_make_ikiwiki_websites_more_accessible.mdwn
@@ -1,7 +1,7 @@
 Here is a patch for page.tmpl to add these landmarks.
 
 > This can't be applied as a patch as-is because it's based on Tails'
-> modified `page.tmpl`, but I get the general idea. A reviewed will need
+> modified `page.tmpl`, but I get the general idea. A reviewer will need
 > to check the ARIA meanings of those roles to confirm that they
 > are appropriate (I haven't done that yet). [[!tag patch]] --[[smcv]]
 

non-review
diff --git a/doc/todo/add_aria_landmarks_to_make_ikiwiki_websites_more_accessible.mdwn b/doc/todo/add_aria_landmarks_to_make_ikiwiki_websites_more_accessible.mdwn
index 36e5d0f..16fb745 100644
--- a/doc/todo/add_aria_landmarks_to_make_ikiwiki_websites_more_accessible.mdwn
+++ b/doc/todo/add_aria_landmarks_to_make_ikiwiki_websites_more_accessible.mdwn
@@ -1,5 +1,10 @@
 Here is a patch for page.tmpl to add these landmarks.
 
+> This can't be applied as a patch as-is because it's based on Tails'
+> modified `page.tmpl`, but I get the general idea. A reviewed will need
+> to check the ARIA meanings of those roles to confirm that they
+> are appropriate (I haven't done that yet). [[!tag patch]] --[[smcv]]
+
 [[!format diff """
 diff --git a/templates/page.tmpl b/templates/page.tmpl
 index 5efad1a..cb76590 100644

fix patch formatting
diff --git a/doc/todo/add_aria_landmarks_to_make_ikiwiki_websites_more_accessible.mdwn b/doc/todo/add_aria_landmarks_to_make_ikiwiki_websites_more_accessible.mdwn
index 745ed05..36e5d0f 100644
--- a/doc/todo/add_aria_landmarks_to_make_ikiwiki_websites_more_accessible.mdwn
+++ b/doc/todo/add_aria_landmarks_to_make_ikiwiki_websites_more_accessible.mdwn
@@ -1,5 +1,7 @@
 Here is a patch for page.tmpl to add these landmarks.
-{{{diff --git a/templates/page.tmpl b/templates/page.tmpl
+
+[[!format diff """
+diff --git a/templates/page.tmpl b/templates/page.tmpl
 index 5efad1a..cb76590 100644
 --- a/templates/page.tmpl
 +++ b/templates/page.tmpl
@@ -45,4 +47,4 @@ index 5efad1a..cb76590 100644
  <TMPL_UNLESS DYNAMIC>
  <TMPL_IF HTML5><nav id="pageinfo"><TMPL_ELSE><div id="pageinfo"></TMPL_IF>
  
-}}}
+"""]]

diff --git a/doc/todo/add_aria_landmarks_to_make_ikiwiki_websites_more_accessible.mdwn b/doc/todo/add_aria_landmarks_to_make_ikiwiki_websites_more_accessible.mdwn
index 85f194f..745ed05 100644
--- a/doc/todo/add_aria_landmarks_to_make_ikiwiki_websites_more_accessible.mdwn
+++ b/doc/todo/add_aria_landmarks_to_make_ikiwiki_websites_more_accessible.mdwn
@@ -1,5 +1,5 @@
 Here is a patch for page.tmpl to add these landmarks.
-diff --git a/templates/page.tmpl b/templates/page.tmpl
+{{{diff --git a/templates/page.tmpl b/templates/page.tmpl
 index 5efad1a..cb76590 100644
 --- a/templates/page.tmpl
 +++ b/templates/page.tmpl
@@ -45,3 +45,4 @@ index 5efad1a..cb76590 100644
  <TMPL_UNLESS DYNAMIC>
  <TMPL_IF HTML5><nav id="pageinfo"><TMPL_ELSE><div id="pageinfo"></TMPL_IF>
  
+}}}

Adding ARIA landmarks allows for example screen readers users to move directly to the page main content
diff --git a/doc/todo/add_aria_landmarks_to_make_ikiwiki_websites_more_accessible.mdwn b/doc/todo/add_aria_landmarks_to_make_ikiwiki_websites_more_accessible.mdwn
new file mode 100644
index 0000000..85f194f
--- /dev/null
+++ b/doc/todo/add_aria_landmarks_to_make_ikiwiki_websites_more_accessible.mdwn
@@ -0,0 +1,47 @@
+Here is a patch for page.tmpl to add these landmarks.
+diff --git a/templates/page.tmpl b/templates/page.tmpl
+index 5efad1a..cb76590 100644
+--- a/templates/page.tmpl
++++ b/templates/page.tmpl
+@@ -30,7 +30,7 @@
+ </head>
+ <body>
+ 
+-<div class="banner">
++<div class="banner" role="banner">
+   <a class="tails" href="<TMPL_VAR HOMEPAGEURL>">
+     <span class="acronym">Tails</span><br/>
+     <span class="slogan">The Amnesic Incognito Live System</span>
+@@ -155,20 +155,20 @@
+ <TMPL_IF HTML5></section><TMPL_ELSE></div></TMPL_IF>
+ 
+ <TMPL_IF SIDEBAR>
+-<TMPL_IF HTML5><aside class="sidebar"><TMPL_ELSE><div class="sidebar"></TMPL_IF>
++<TMPL_IF HTML5><aside class="sidebar" role="navigation"><TMPL_ELSE><div class="sidebar" role="navigation"></TMPL_IF>
+ <TMPL_VAR SIDEBAR>
+ <TMPL_IF HTML5></aside><TMPL_ELSE></div></TMPL_IF>
+ </TMPL_IF>
+ 
+ <div id="pagebody">
+ 
+-<TMPL_IF HTML5><section id="content"><TMPL_ELSE><div id="content"></TMPL_IF>
++<TMPL_IF HTML5><section id="content" role="main"><TMPL_ELSE><div id="content" role="main"></TMPL_IF>
+ <TMPL_VAR CONTENT>
+ <TMPL_IF HTML5></section><TMPL_ELSE></div></TMPL_IF>
+ 
+ <TMPL_UNLESS DYNAMIC>
+ <TMPL_IF COMMENTS>
+-<TMPL_IF HTML5><section id="comments"><TMPL_ELSE><div id="comments"></TMPL_IF>
++<TMPL_IF HTML5><section id="comments" role="complementary"><TMPL_ELSE><div id="comments" role="complementary"></TMPL_IF>
+ <TMPL_VAR COMMENTS>
+ <TMPL_IF ADDCOMMENTURL>
+ <div class="addcomment">
+@@ -183,7 +183,7 @@
+ 
+ </div>
+ 
+-<TMPL_IF HTML5><footer id="footer" class="pagefooter"><TMPL_ELSE><div id="footer" class="pagefooter"></TMPL_IF>
++<TMPL_IF HTML5><footer id="footer" class="pagefooter" role="contentinfo"><TMPL_ELSE><div id="footer" class="pagefooter" role="contentinfo"></TMPL_IF>
+ <TMPL_UNLESS DYNAMIC>
+ <TMPL_IF HTML5><nav id="pageinfo"><TMPL_ELSE><div id="pageinfo"></TMPL_IF>
+ 

Added a comment: Apache redirection
diff --git a/doc/forum/Serving_Blog_under_different_Subdomain/comment_2_63ddd76a8215d463b5db7754f0be0f01._comment b/doc/forum/Serving_Blog_under_different_Subdomain/comment_2_63ddd76a8215d463b5db7754f0be0f01._comment
new file mode 100644
index 0000000..ab0e4da
--- /dev/null
+++ b/doc/forum/Serving_Blog_under_different_Subdomain/comment_2_63ddd76a8215d463b5db7754f0be0f01._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="spalax"
+ ip="82.233.196.200"
+ subject="Apache redirection"
+ date="2014-09-27T06:20:09Z"
+ content="""
+I think you can also (assuming you are using Apache2, and having some control over it) make apache redirect [[blog.example.com]] to [[wiki.example.com/blog]].
+"""]]

Added a comment: Several .setup files
diff --git a/doc/forum/Serving_Blog_under_different_Subdomain/comment_1_33dab1457f7ff6d5e599897e0ebd45a0._comment b/doc/forum/Serving_Blog_under_different_Subdomain/comment_1_33dab1457f7ff6d5e599897e0ebd45a0._comment
new file mode 100644
index 0000000..0732a82
--- /dev/null
+++ b/doc/forum/Serving_Blog_under_different_Subdomain/comment_1_33dab1457f7ff6d5e599897e0ebd45a0._comment
@@ -0,0 +1,28 @@
+[[!comment format=mdwn
+ username="spalax"
+ ip="82.233.196.200"
+ subject="Several .setup files"
+ date="2014-09-27T06:18:29Z"
+ content="""
+I am not sure to have understood your question, but I assume the following:
+
+- your source wiki contains some subdirectory `blog`;
+- you want the whole wiki to be served as [[wiki.example.com]]
+- you want the `blog` subdirectory serves as [[blog.example.com]]
+
+If so, what you can do is having two different setup files.
+
+- the first one would contain (using the old setup file format, but you can adapt it for the new one):
+
+      srcdir => \"/path/to/your/source/wiki/\",
+      url => \"http://wiki.example.com\",
+
+- and the second one would contain:
+
+      srcdir => \"/path/to/your/source/wiki/blog\",
+      url => \"http://blog.example.com\",
+
+I hope I answered your question.
+
+-- [[Louis|spalax]]
+"""]]

typos
diff --git a/doc/forum/Serving_Blog_under_different_Subdomain.mdwn b/doc/forum/Serving_Blog_under_different_Subdomain.mdwn
index e747294..ebda8cd 100644
--- a/doc/forum/Serving_Blog_under_different_Subdomain.mdwn
+++ b/doc/forum/Serving_Blog_under_different_Subdomain.mdwn
@@ -1,3 +1,3 @@
-I'm working on consolidating my blog and wiki with ikiwiki. I have the following question: Is it possible to serve a blog under a different subdomain? For example: URL of the wiki: ```wiki.example.com``` and I would like to be able to reach the blog under the URL ```blog.example.com```. The permalink structure right now looks like this: ```wiki.example.com/blog/post/``` is it possible to rewrite is so it is served as ```blog.example.com/post/```. I don't even know if this is a question for the ikiwiki forum, but I need to start somewhere.
+I'm working on consolidating my blog and wiki with ikiwiki. I have the following question: Is it possible to serve a blog under a different subdomain? For example: URL of the wiki: ```wiki.example.com``` and I would like to be able to reach the blog under the URL ```blog.example.com```. The permalink structure right now looks like this: ```wiki.example.com/blog/post/``` is it possible to rewrite it so it is served as ```blog.example.com/post/```? I don't even know if this is a question for the ikiwiki forum, but I need to start somewhere.
 
 Thanks in advance for any ideas on how to accomplish that!

diff --git a/doc/forum/Serving_Blog_under_different_Subdomain.mdwn b/doc/forum/Serving_Blog_under_different_Subdomain.mdwn
new file mode 100644
index 0000000..e747294
--- /dev/null
+++ b/doc/forum/Serving_Blog_under_different_Subdomain.mdwn
@@ -0,0 +1,3 @@
+I'm working on consolidating my blog and wiki with ikiwiki. I have the following question: Is it possible to serve a blog under a different subdomain? For example: URL of the wiki: ```wiki.example.com``` and I would like to be able to reach the blog under the URL ```blog.example.com```. The permalink structure right now looks like this: ```wiki.example.com/blog/post/``` is it possible to rewrite is so it is served as ```blog.example.com/post/```. I don't even know if this is a question for the ikiwiki forum, but I need to start somewhere.
+
+Thanks in advance for any ideas on how to accomplish that!

diff --git a/doc/shortcuts.mdwn b/doc/shortcuts.mdwn
index 72e4c7c..1748a02 100644
--- a/doc/shortcuts.mdwn
+++ b/doc/shortcuts.mdwn
@@ -64,6 +64,8 @@ This page controls what shortcut links the wiki supports.
 * [[!shortcut name=freebsdwiki url="http://wiki.freebsd.org/%s"]]
 * [[!shortcut name=hackage url="http://hackage.haskell.org/package/%s"]]
 * [[!shortcut name=pkgsrc url="http://pkgsrc.se/%S"]]
+* [[!shortcut name=doi url="http://dx.doi.org/%s" desc="doi:%s"]]
+* [[!shortcut name=arxiv url="http://arxiv.org/abs/%s" desc="arXiv:%s"]]
 
 To add a new shortcut, use the `shortcut`
 [[ikiwiki/directive]]. In the url, "%s" is replaced with the

diff --git a/doc/todo/Any_todo_because_CGI.pm_deprecated__63__.mdwn b/doc/todo/Any_todo_because_CGI.pm_deprecated__63__.mdwn
index e90d041..ab87c8b 100644
--- a/doc/todo/Any_todo_because_CGI.pm_deprecated__63__.mdwn
+++ b/doc/todo/Any_todo_because_CGI.pm_deprecated__63__.mdwn
@@ -22,6 +22,12 @@ Or is it just a matter of 'hold course until [[rewrite ikiwiki in haskell]]'?
 >>
 >> I, for one, would be happy to see some improvements in this area... --[[anarcat]]
 
+>>> That would be a rewrite, in whatever language: IkiWiki assumes that
+>>> global state is OK, and I don't think keeping existing APIs or
+>>> plugins working unmodified when that changes would be feasible.
+>>>
+>>> It isn't on *my* to-do list, put it that way. --[[smcv]]
+
 >> I'm on a thin pipe, but IIRC CGI.pm is simply no longer going to be bundled with Perl core, and is not deprecated in any other way. Just old, and now an explicit dependency. I may be wrong. --[[schmonz]]
 
 >>> Yeah, that's what perldelta says. Also, in Debian, the future is already

diff --git a/doc/todo/Any_todo_because_CGI.pm_deprecated__63__.mdwn b/doc/todo/Any_todo_because_CGI.pm_deprecated__63__.mdwn
index 0810157..e90d041 100644
--- a/doc/todo/Any_todo_because_CGI.pm_deprecated__63__.mdwn
+++ b/doc/todo/Any_todo_because_CGI.pm_deprecated__63__.mdwn
@@ -16,6 +16,12 @@ Or is it just a matter of 'hold course until [[rewrite ikiwiki in haskell]]'?
 > like most webapps, because it produces static HTML for as much of
 > its content as possible anyway. --[[smcv]]
 
+>> One reason for such a change (although a rewrite in haskell is a little drastic, and overlaps with "gitit") would be to allow ikiwiki to run as a shared thread under FastCGI or mod_perl, instead of forking all the time for every new user. The discussion for this is in [[todo/fastcgi_or_modperl_installation_instructions]] and [[todo/multi-thread_ikiwiki]].
+>>
+>> Also right now, there are serious lock contention issues in ikiwiki: any `?do=` action in the CGI is under a global lock right now (`lockwiki()`), for example, which makes scaling ikiwiki to multiple editing users a significant problem. I have seen such contention as a user on this wiki but mostly on the git-annex wiki.
+>>
+>> I, for one, would be happy to see some improvements in this area... --[[anarcat]]
+
 >> I'm on a thin pipe, but IIRC CGI.pm is simply no longer going to be bundled with Perl core, and is not deprecated in any other way. Just old, and now an explicit dependency. I may be wrong. --[[schmonz]]
 
 >>> Yeah, that's what perldelta says. Also, in Debian, the future is already

Added a comment
diff --git a/doc/forum/Changing_when_a_page_is_posted/comment_2_72eece90a36af447ebdc4a1e4751c790._comment b/doc/forum/Changing_when_a_page_is_posted/comment_2_72eece90a36af447ebdc4a1e4751c790._comment
new file mode 100644
index 0000000..f6765d2
--- /dev/null
+++ b/doc/forum/Changing_when_a_page_is_posted/comment_2_72eece90a36af447ebdc4a1e4751c790._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="openmedi"
+ ip="141.23.120.160"
+ subject="comment 2"
+ date="2014-09-24T13:19:58Z"
+ content="""
+Thank you for pointing out the meta directive to me! This was exactly what I was looking for. :) Also, you were right, I didn't use the right offset. Everything works now.
+"""]]

Added a comment
diff --git a/doc/forum/Changing_when_a_page_is_posted/comment_1_936fc8e91ae9a8aad0fb53944e4c33bb._comment b/doc/forum/Changing_when_a_page_is_posted/comment_1_936fc8e91ae9a8aad0fb53944e4c33bb._comment
new file mode 100644
index 0000000..9b2861a
--- /dev/null
+++ b/doc/forum/Changing_when_a_page_is_posted/comment_1_936fc8e91ae9a8aad0fb53944e4c33bb._comment
@@ -0,0 +1,15 @@
+[[!comment format=mdwn
+ username="smcv"
+ ip="81.100.115.242"
+ subject="comment 1"
+ date="2014-09-24T07:27:38Z"
+ content="""
+It does sound as though you have some sort of DST issue going on.
+Did you specify the time zone taking into account DST
+(e.g. if you are in USA Eastern time (UTC-05:00) and you wrote
+a blog post in summer, you'll want to use -0400)?
+
+You don't need to alter the git commit dates, you can use
+something like \[[!meta date=\"2014-09-24 08:26:05+0100\"]]
+which takes precedence over the commit date from git.
+"""]]

diff --git a/doc/forum/Changing_when_a_page_is_posted.mdwn b/doc/forum/Changing_when_a_page_is_posted.mdwn
new file mode 100644
index 0000000..acc847b
--- /dev/null
+++ b/doc/forum/Changing_when_a_page_is_posted.mdwn
@@ -0,0 +1,9 @@
+I try to merge my existing blog with my wiki. I just started the process and ran into a problem:
+
+I created a blog in my ikiwiki install and wanted to import my blogposts, that are just a bunch of (octopress) text files. Of course, ikiwiki can read them, etc. Here's my problem: When adding an old post to git, the imported blog article in my wiki is shown to be posted today. This is not the desired behaviour, since I have published this article a while before. The only way to change this I found was to fiddle around with the commit where I added the post. A way to this is described in [this stackoverflow answer](http://stackoverflow.com/a/454750).
+
+This works. Well, almost.
+
+For some weird reason the "posted" time is off one hour. Let's say, I published an article Fri Mar 2 01:30:00 2012. I corrected the commit as outlined by the link I provided. Ikiwiki will show that the article got posted at Fri Mar 2 00:30:00 2012. The only reason I can think of, that could produce this error, is DST. Has anyone an idea how to correct this error? Did I do something wrong or did I overlook something?
+
+Any help is appreciated!