Recent changes to this wiki:

add "ssm"'s ikiwiki site.
diff --git a/doc/ikiwikiusers.mdwn b/doc/ikiwikiusers.mdwn
index 1de766d..1fe2719 100644
--- a/doc/ikiwikiusers.mdwn
+++ b/doc/ikiwikiusers.mdwn
@@ -193,3 +193,5 @@ Personal sites and blogs
 * [Wouter's Blog](http://grep.be/blog/), with a custom CSS stylesheet based off the rest of his website.
 * [Julian Andres Klode's blog](http://jak-linux.org/)
 * [KheOps's blog](https://w.ceops.eu/words/)
+* [Stig Sandbeck Mathisen](http://fnord.no/) - Personal site and blog, with a bootstrap theme, and varnish frontend.
+

todo entry
diff --git a/doc/todo/concatenating_or_compiling_CSS.mdwn b/doc/todo/concatenating_or_compiling_CSS.mdwn
new file mode 100644
index 0000000..ed3f2e8
--- /dev/null
+++ b/doc/todo/concatenating_or_compiling_CSS.mdwn
@@ -0,0 +1,110 @@
+It would be great if IkiWiki could apply some sort of preprocessing to
+CSS. I'm just "thinking out loud" at the moment, but I might write
+a plugin.
+
+The simplest starting point would be concatenating a list of files:
+
+* The actiontabs and monochrome themes are not ready for use as-is;
+  the Makefile constructs the real stylesheet by concatenating the
+  anti-theme's CSS and the relevant theme's CSS. It would be better
+  if they could just drop a file in an underlay, and IkiWiki would
+  concatenate the anti-theme stylesheet and the theme's file.
+
+* The blueview theme is the same, but the theme's CSS also starts
+  with a couple of stylesheets from YUI. IkiWiki could maybe
+  concatenate the anti-theme stylesheet, the two YUI stylesheets
+  and the blueview-specific part? Or maybe that's too complicated.
+
+* The goldtype theme is the blueview theme with some overrides
+  added to the end. Again, IkiWiki could concatenate all the pieces.
+
+* The [[plugins/contrib/album]] plugin needs to append some
+  stuff to the stylesheet, making its installation more involved
+  than it ought to be. If it could append the pieces by putting them
+  in an underlay, installation would just be a matter of "add
+  the files".
+
+I'm not sure whether local.css should be concatenated too, or whether
+it should be separate.
+
+It would also be great if the same mechanism could be extended
+to compile CSS-like languages like [[!debpkg ruby-sass desc=SASS]]
+or [[!debpkg node-less desc=LESS]] down to CSS, but for dependency
+reasons, I don't think the themes shipped with IkiWiki should rely on that.
+
+If the compiled CSS ended up with a content-based filename (perhaps
+ikiwiki/compiled-HASH.css where HASH is the (possibly truncated) MD5 or SHA1
+hash of the content), that would mitigate stale CSS being served from cache
+(as long as the HTML has a short expiry, which is desirable anyway),
+and ikiwiki-hosting could maybe even do something like this to allow
+long-term caching of the files with content-based names:
+
+    <LocationMatch /ikiwiki/compiled-[a-f0-9]+\.css>
+        ExpiresByType text/css "now plus 1 year"
+    </LocationMatch>
+
+A similar mechanism could maybe be used to minify JavaScript.
+
+## vague syntax proposal: controlled by directive
+
+    \[[!css files="""
+        style.css
+        ikiwiki/plugin*.css
+        ikiwiki/theme*.css
+        local.css
+    """]]
+
+* *css* directive, placed in any page, concatenates the given files
+  and uses them as the stylesheet for that page and its subpages,
+  replacing `<TMPL_VAR BASEURL>style.css`
+
+* the files can be globs, which are sorted lexicographically within
+  a glob, and do not have to match anything (so it's OK if you don't
+  have anything that matches `plugin*.css`); "-" happens to sort
+  before ".", so theme-base.css would sort before theme.css,
+  which is nice to have
+
+* the default would be `style.css`, then `ikiwiki/plugin*.css`,
+  then `ikiwiki/theme*.css` and maybe `local.css`, as in the
+  example above
+
+* `style.css` would continue to be the anti-theme
+
+* themes would ship `ikiwiki/theme.css` instead of `style.css`,
+  resulting in concatenation
+
+* goldtype would ship `ikiwiki/theme-base.css` (which is a copy of
+  blueview, or a symlink to blueview if we can make symlinks safe)
+  and `ikiwiki/theme.css` (which is the goldtype additions)
+
+* [[plugins/contrib/album]] would put its templates and
+  `ikiwiki/plugin-album.css` in an underlay
+
+* any non-contrib plugin with complicated CSS requirements
+  could also move its CSS to an underlay
+
+I think this could be done entirely in a plugin, except for this
+change to `page.tmpl` to allow the `<style>`s to be overridden:
+
+    <TMPL_IF COMPILED_CSS>
+        <style type="text/css" href="<TMPL_VAR BASEURL><TMPL_VAR COMPILED_CSS>" />
+    <TMPL_ELSE>
+        <!-- ... what it does now ... -->
+    </TMPL_IF>
+
+The plugin could also optionally minify its output, and either pass input
+files through an external SASS/SCSS/LESS implementation according
+to their extension, or have a hook system to do so.
+
+People who want SASS/LESS would probably just do this in their top-level page:
+
+    \[[!css files="mywiki.less"]]
+
+and do the inclusion/concatenation logic via @import.
+
+Security consideration: the SASS/LESS compilers will read arbitrary local
+files, so if you use those languages, ability to upload the appropriate
+extension would have to be locked-down. Perhaps it's better to implement
+this without that feature initially.
+
+--[[smcv]]

added Smuxi website with sophiscated CSS and jQuery
diff --git a/doc/ikiwikiusers.mdwn b/doc/ikiwikiusers.mdwn
index b205aa7..1de766d 100644
--- a/doc/ikiwikiusers.mdwn
+++ b/doc/ikiwikiusers.mdwn
@@ -90,6 +90,7 @@ Projects & Organizations
 * [[Les Barricades|http://barricades.int.eu.org]] - A French socialist choir (CSS has been adapted from the one of [[Grésille|http://www.gresille.org]]).
 * [DKØTU Amateur Radio Station](http://www.dk0tu.de), TU Berlin
 * [[Plan A|http://www.plan-a-muenchen.de/]] - A proposal for improvement of the urban public transport in Munich (by PRO BAHN, Bund Naturschutz and others)
+* [[Smuxi IRC Client|https://smuxi.im/]] - powerful IRC client for GNOME
 
 Personal sites and blogs
 ========================

Added links to two blogs (with nice CSS)
diff --git a/doc/ikiwikiusers.mdwn b/doc/ikiwikiusers.mdwn
index 18dd7ca..b205aa7 100644
--- a/doc/ikiwikiusers.mdwn
+++ b/doc/ikiwikiusers.mdwn
@@ -190,3 +190,5 @@ Personal sites and blogs
 * Julien Lefrique's [homepage](http://julien.lefrique.name/), hosted on [GitHub pages](https://github.com/jlefrique/jlefrique.github.com) with CGI disabled
 * [Anarcat's homepage](http://anarcat.ath.cx/) - with a custom [[theme|theme_market]]
 * [Wouter's Blog](http://grep.be/blog/), with a custom CSS stylesheet based off the rest of his website.
+* [Julian Andres Klode's blog](http://jak-linux.org/)
+* [KheOps's blog](https://w.ceops.eu/words/)

cosmetic change
diff --git a/doc/bugs/openid_login_fails_wirth_Could_not_determine_ID_provider_from_URL.mdwn b/doc/bugs/openid_login_fails_wirth_Could_not_determine_ID_provider_from_URL.mdwn
index ba3de36..4b506ae 100644
--- a/doc/bugs/openid_login_fails_wirth_Could_not_determine_ID_provider_from_URL.mdwn
+++ b/doc/bugs/openid_login_fails_wirth_Could_not_determine_ID_provider_from_URL.mdwn
@@ -71,7 +71,7 @@ From there we look at `_find_semantic_info()`, which is supposed to hit the Open
 
 To get this little wonder, I had to change the `_find_semantic_info()` as followed:
 
-~~~~
+[[!format perl """
 sub _find_semantic_info {
     my Net::OpenID::Consumer $self = shift;
     my $url = shift;
@@ -84,7 +84,7 @@ sub _find_semantic_info {
 
     return $info;
 }
-~~~~
+"""]]
 
 A minimal test case would be:
 

add workaround
diff --git a/doc/bugs/openid_login_fails_wirth_Could_not_determine_ID_provider_from_URL.mdwn b/doc/bugs/openid_login_fails_wirth_Could_not_determine_ID_provider_from_URL.mdwn
index fccb547..ba3de36 100644
--- a/doc/bugs/openid_login_fails_wirth_Could_not_determine_ID_provider_from_URL.mdwn
+++ b/doc/bugs/openid_login_fails_wirth_Could_not_determine_ID_provider_from_URL.mdwn
@@ -133,3 +133,19 @@ $ perl -e 'use LWPx::ParanoidAgent;
 500 Can't read entity body: Ressource temporairement non disponible
 500 Can't read entity body: Ressource temporairement non disponible
 ~~~~
+
+Workaround - disable error checking:
+
+~~~~
+--- /home/anarcat/src/ikiwiki/IkiWiki/Plugin/openid.pm  2014-02-03 20:21:09.502878631 -0500
++++ /usr/share/perl5/IkiWiki/Plugin/openid.pm   2014-04-13 16:00:06.875744596 -0400
+@@ -237,7 +237,7 @@
+
+        my $ua;
+        eval q{use LWPx::ParanoidAgent};
+-       if (! $@) {
++       if (! $@ && 0) {
+                $ua=LWPx::ParanoidAgent->new;
+        }
+        else {
+~~~~

reproduceable
diff --git a/doc/bugs/openid_login_fails_wirth_Could_not_determine_ID_provider_from_URL.mdwn b/doc/bugs/openid_login_fails_wirth_Could_not_determine_ID_provider_from_URL.mdwn
index 9cffe24..fccb547 100644
--- a/doc/bugs/openid_login_fails_wirth_Could_not_determine_ID_provider_from_URL.mdwn
+++ b/doc/bugs/openid_login_fails_wirth_Could_not_determine_ID_provider_from_URL.mdwn
@@ -112,3 +112,24 @@ I filed this bug in the Debian BTS as [#702124](https://bugs.debian.org/cgi-bin/
     500 Can't read entity body: Resource temporarily unavailable
 
 ... yet the commandline client works fine... I'm out of ideas for this sucker.
+
+Update: i found a way to reproduce the problem even with LWPx::ParanoidAgent 1.07:
+
+~~~~
+$ perl -e 'use LWPx::ParanoidAgent;
+  print $LWPx::ParanoidAgent::VERSION, " $]\n";
+  $ua = new LWPx::ParanoidAgent; for (my $i = 0; $i< 10 ; $i++) { $c = LWPx::ParanoidAgent->new->get
+      ("https://id.koumbit.net/anarcat")
+      ->decoded_content; if (length($c) < 100) { print $c; } else { print length($c),"\n";}}'
+1.07 5.018002
+5720
+500 Can't read entity body: Ressource temporairement non disponible
+500 Can't read entity body: Ressource temporairement non disponible
+500 Can't read entity body: Ressource temporairement non disponible
+500 Can't read entity body: Ressource temporairement non disponible
+500 Can't read entity body: Ressource temporairement non disponible
+500 Can't read entity body: Ressource temporairement non disponible
+500 Can't read entity body: Ressource temporairement non disponible
+500 Can't read entity body: Ressource temporairement non disponible
+500 Can't read entity body: Ressource temporairement non disponible
+~~~~

diff --git a/doc/bugs/openid_login_fails_wirth_Could_not_determine_ID_provider_from_URL.mdwn b/doc/bugs/openid_login_fails_wirth_Could_not_determine_ID_provider_from_URL.mdwn
index da7e92d..9cffe24 100644
--- a/doc/bugs/openid_login_fails_wirth_Could_not_determine_ID_provider_from_URL.mdwn
+++ b/doc/bugs/openid_login_fails_wirth_Could_not_determine_ID_provider_from_URL.mdwn
@@ -101,7 +101,7 @@ And the results vary according to the version of perl:
 * wheezy: 1.07 5.014002: 5720
 * jessie: 1.10 5.018002: 398
 
-Thanks [jwz](http://www.jwz.org/blog/2014/03/apple-broke-lwp-in-a-new-and-exciting-way-on-10-9-2/) for that.. And this *could* have been packaged in Debian, except it overlaps with the `ca-certificates` package, so it was [basically barred entry](https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=702124).
+Thanks [jwz](http://www.jwz.org/blog/2014/03/apple-broke-lwp-in-a-new-and-exciting-way-on-10-9-2/) for that.. Mozilla::CA *could* have been packaged in Debian, except it overlaps with the `ca-certificates` package, so it was [basically barred entry](https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=702124).
 
 I tried the workaround of hardcoding the path to the CA root, using `PERL_LWP_SSL_CA_PATH=/etc/ssl/certs`, but then I hit *another* bug in LWP: [#738493](https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=738493).
 

workaround but still out of ideas for an actual fix
diff --git a/doc/bugs/openid_login_fails_wirth_Could_not_determine_ID_provider_from_URL.mdwn b/doc/bugs/openid_login_fails_wirth_Could_not_determine_ID_provider_from_URL.mdwn
index 0b1a1a2..da7e92d 100644
--- a/doc/bugs/openid_login_fails_wirth_Could_not_determine_ID_provider_from_URL.mdwn
+++ b/doc/bugs/openid_login_fails_wirth_Could_not_determine_ID_provider_from_URL.mdwn
@@ -106,3 +106,9 @@ Thanks [jwz](http://www.jwz.org/blog/2014/03/apple-broke-lwp-in-a-new-and-exciti
 I tried the workaround of hardcoding the path to the CA root, using `PERL_LWP_SSL_CA_PATH=/etc/ssl/certs`, but then I hit *another* bug in LWP: [#738493](https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=738493).
 
 Note that this bug is similar to [[bugs/ssl_certificates_not_checked_with_openid/]], but backwards: it checks the SSL certs but then fails to verify.
+
+I filed this bug in the Debian BTS as [#702124](https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=702124). Downgrading to wheezy's version of LWPx::ParanoidAgent doesn't fix the problem, instead i get this error:
+
+    500 Can't read entity body: Resource temporarily unavailable
+
+... yet the commandline client works fine... I'm out of ideas for this sucker.

more details, down the rabbit hole, i found a dead apple
diff --git a/doc/bugs/openid_login_fails_wirth_Could_not_determine_ID_provider_from_URL.mdwn b/doc/bugs/openid_login_fails_wirth_Could_not_determine_ID_provider_from_URL.mdwn
index 98f60ec..0b1a1a2 100644
--- a/doc/bugs/openid_login_fails_wirth_Could_not_determine_ID_provider_from_URL.mdwn
+++ b/doc/bugs/openid_login_fails_wirth_Could_not_determine_ID_provider_from_URL.mdwn
@@ -3,3 +3,106 @@ On some ikiwikis that I run, I get the following error on OpenID logins:
     no_identity_server: Could not determine ID provider from URL.
 
 I seem recall having that error before, and fixing it, but it always seems to come back and I forget how to fix it. So I'll just open this bug and document it if i can figure it out... -- [[users/anarcat]]
+
+The Perl module manual says:
+
+>            "no_identity_server"
+>               (CV) Tried to do discovery on a URL that does not seem to have any providers at all.
+
+Yet on the server side, I see no request coming in on the OpenID provider... 
+
+Adding debugging helps in figuring out wtf is going on:
+
+~~~~
+anarcat@marcos:~$ diff -u ~/src/ikiwiki/IkiWiki/Plugin/openid.pm /usr/share/perl5/IkiWiki/Plugin/openid.pm
+--- /home/anarcat/src/ikiwiki/IkiWiki/Plugin/openid.pm  2014-02-03 20:21:09.502878631 -0500
++++ /usr/share/perl5/IkiWiki/Plugin/openid.pm   2014-04-13 11:45:25.413297420 -0400
+@@ -257,6 +256,7 @@
+        return Net::OpenID::Consumer->new(
+                ua => $ua,
+                args => $q,
++               debug => 1,
+                consumer_secret => sub { return shift()+$secret },
+                required_root => auto_upgrade_https($q, $cgiurl),
+        );
+~~~~
+
+In my case, I see:
+
+
+~~~~
+[Sun Apr 13 11:45:35.796531 2014] [cgi:error] [pid 7299] [client 162.223.3.24:39547] AH01215: [DEBUG Net::OpenID::Consumer] Cache MISS for https://id.koumbit.net/anarcat, referer: http://cats.orangeseeds.org/ikiwiki.cgi?do=signin&action=verify&openid_identifier=https%3A%2F%2Fid.koumbit.net%2Fanarcat
+[Sun Apr 13 11:45:35.842520 2014] [cgi:error] [pid 7299] [client 162.223.3.24:39547] AH01215: [DEBUG Net::OpenID::Consumer] Cache MISS for https://id.koumbit.net/anarcat, referer: http://cats.orangeseeds.org/ikiwiki.cgi?do=signin&action=verify&openid_identifier=https%3A%2F%2Fid.koumbit.net%2Fanarcat
+[Sun Apr 13 11:45:35.845603 2014] [cgi:error] [pid 7299] [client 162.223.3.24:39547] AH01215: [DEBUG Net::OpenID::Consumer] semantic info (https://id.koumbit.net/anarcat) = , referer: http://cats.orangeseeds.org/ikiwiki.cgi?do=signin&action=verify&openid_identifier=https%3A%2F%2Fid.koumbit.net%2Fanarcat
+[Sun Apr 13 11:45:35.845672 2014] [cgi:error] [pid 7299] [client 162.223.3.24:39547] AH01215: [DEBUG Net::OpenID::Consumer] fail(no_identity_server) Could not determine ID provider from URL., referer: http://cats.orangeseeds.org/ikiwiki.cgi?do=signin&action=verify&openid_identifier=https%3A%2F%2Fid.koumbit.net%2Fanarcat
+~~~~
+
+There are three places in the code the original error message happens:
+
+* Net::OpenID::claimed_identity
+* Net::OpenID::verified_identity
+* Net::OpenID::_find_openid_server
+
+We'll look at the last one because it's where the URL data is actually fetched.
+
+[[!format perl """
+sub _find_openid_server {
+    my Net::OpenID::Consumer $self = shift;
+    my $url = shift;
+    my $final_url_ref = shift;
+
+    my $sem_info = $self->_find_semantic_info($url, $final_url_ref) or
+        return;
+
+    return $self->_fail("no_identity_server") unless $sem_info->{"openid.server"};
+    $sem_info->{"openid.server"};
+}
+"""]]
+
+From there we look at `_find_semantic_info()`, which is supposed to hit the OpenID server, but doesn't somehow.... By cranking up debugging, we can see that the consumer fails to verify the HTTPS signature on the host:
+
+~~~~
+[Sun Apr 13 11:58:30.284511 2014] [cgi:error] [pid 11141] [client 162.223.3.24:39563] AH01215: [DEBUG Net::OpenID::Consumer] url dump (https://id.koumbit.net/anarcat, SCALAR(0x3275ac0)) = 500 Can't verify SSL peers without knowing which Certificate Authorities to trust, referer: http://cats.orangeseeds.org/ikiwiki.cgi?do=signin&action=verify&openid_identifier=https%3A%2F%2Fid.koumbit.net%2Fanarcat
+[Sun Apr 13 11:58:30.284551 2014] [cgi:error] [pid 11141] [client 162.223.3.24:39563] AH01215: , referer: http://cats.orangeseeds.org/ikiwiki.cgi?do=signin&action=verify&openid_identifier=https%3A%2F%2Fid.koumbit.net%2Fanarcat
+[Sun Apr 13 11:58:30.284573 2014] [cgi:error] [pid 11141] [client 162.223.3.24:39563] AH01215: This problem can be fixed by either setting the PERL_LWP_SSL_CA_FILE, referer: http://cats.orangeseeds.org/ikiwiki.cgi?do=signin&action=verify&openid_identifier=https%3A%2F%2Fid.koumbit.net%2Fanarcat
+[Sun Apr 13 11:58:30.284593 2014] [cgi:error] [pid 11141] [client 162.223.3.24:39563] AH01215: envirionment variable or by installing the Mozilla::CA module., referer: http://cats.orangeseeds.org/ikiwiki.cgi?do=signin&action=verify&openid_identifier=https%3A%2F%2Fid.koumbit.net%2Fanarcat
+[Sun Apr 13 11:58:30.284597 2014] [cgi:error] [pid 11141] [client 162.223.3.24:39563] AH01215: , referer: http://cats.orangeseeds.org/ikiwiki.cgi?do=signin&action=verify&openid_identifier=https%3A%2F%2Fid.koumbit.net%2Fanarcat
+~~~~
+
+To get this little wonder, I had to change the `_find_semantic_info()` as followed:
+
+~~~~
+sub _find_semantic_info {
+    my Net::OpenID::Consumer $self = shift;
+    my $url = shift;
+    my $final_url_ref = shift;
+
+    my $doc = $self->_get_url_contents($url, $final_url_ref);
+    $self->_debug("url dump ($url, $final_url_ref) = " . $doc) if $self->{debug};
+    my $info = _document_to_semantic_info($doc);
+    $self->_debug("semantic info ($url) = " . join(", ", map { $_.' => '.$info->{$_} } keys %$info)) if $self->{debug};
+
+    return $info;
+}
+~~~~
+
+A minimal test case would be:
+
+~~~~
+perl -e 'use LWPx::ParanoidAgent;
+  print $LWPx::ParanoidAgent::VERSION, " $]: ";
+  print length(LWPx::ParanoidAgent->new->get
+      ("https://id.koumbit.net/anarcat")
+      ->decoded_content), "\n";'
+~~~~
+
+And the results vary according to the version of perl:
+
+* wheezy: 1.07 5.014002: 5720
+* jessie: 1.10 5.018002: 398
+
+Thanks [jwz](http://www.jwz.org/blog/2014/03/apple-broke-lwp-in-a-new-and-exciting-way-on-10-9-2/) for that.. And this *could* have been packaged in Debian, except it overlaps with the `ca-certificates` package, so it was [basically barred entry](https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=702124).
+
+I tried the workaround of hardcoding the path to the CA root, using `PERL_LWP_SSL_CA_PATH=/etc/ssl/certs`, but then I hit *another* bug in LWP: [#738493](https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=738493).
+
+Note that this bug is similar to [[bugs/ssl_certificates_not_checked_with_openid/]], but backwards: it checks the SSL certs but then fails to verify.

diff --git a/doc/bugs/openid_login_fails_wirth_Could_not_determine_ID_provider_from_URL.mdwn b/doc/bugs/openid_login_fails_wirth_Could_not_determine_ID_provider_from_URL.mdwn
new file mode 100644
index 0000000..98f60ec
--- /dev/null
+++ b/doc/bugs/openid_login_fails_wirth_Could_not_determine_ID_provider_from_URL.mdwn
@@ -0,0 +1,5 @@
+On some ikiwikis that I run, I get the following error on OpenID logins:
+
+    no_identity_server: Could not determine ID provider from URL.
+
+I seem recall having that error before, and fixing it, but it always seems to come back and I forget how to fix it. So I'll just open this bug and document it if i can figure it out... -- [[users/anarcat]]

update for rename of plugins/contrib/ssm.mdwn to users/ssm.mdwn
diff --git a/doc/plugins/contrib/purge.mdwn b/doc/plugins/contrib/purge.mdwn
index cac3c50..62fcfb3 100644
--- a/doc/plugins/contrib/purge.mdwn
+++ b/doc/plugins/contrib/purge.mdwn
@@ -1,4 +1,4 @@
-[[!template id=plugin name=purge core=0 author="[[ssm]]"]]
+[[!template id=plugin name=purge core=0 author="[[users/ssm]]"]]
 
 IkiWiki plugin to send PURGE requests to remote http cache server (like Varnish Cache) when your content changes.
 

rename plugins/contrib/ssm.mdwn to users/ssm.mdwn
diff --git a/doc/plugins/contrib/ssm.mdwn b/doc/plugins/contrib/ssm.mdwn
deleted file mode 100644
index f2ebb8e..0000000
--- a/doc/plugins/contrib/ssm.mdwn
+++ /dev/null
@@ -1,3 +0,0 @@
-Stig Sandbeck Mathisen has a [web page somewhere](http://fnord.no).
-
-Somewhat fond of perl, ikiwiki and varnish, and wrote the [[plugins/contrib/purge]] plugin to glue them together.
diff --git a/doc/users/ssm.mdwn b/doc/users/ssm.mdwn
new file mode 100644
index 0000000..f2ebb8e
--- /dev/null
+++ b/doc/users/ssm.mdwn
@@ -0,0 +1,3 @@
+Stig Sandbeck Mathisen has a [web page somewhere](http://fnord.no).
+
+Somewhat fond of perl, ikiwiki and varnish, and wrote the [[plugins/contrib/purge]] plugin to glue them together.

diff --git a/doc/plugins/contrib/ssm.mdwn b/doc/plugins/contrib/ssm.mdwn
new file mode 100644
index 0000000..f2ebb8e
--- /dev/null
+++ b/doc/plugins/contrib/ssm.mdwn
@@ -0,0 +1,3 @@
+Stig Sandbeck Mathisen has a [web page somewhere](http://fnord.no).
+
+Somewhat fond of perl, ikiwiki and varnish, and wrote the [[plugins/contrib/purge]] plugin to glue them together.

diff --git a/doc/plugins/contrib/purge.mdwn b/doc/plugins/contrib/purge.mdwn
new file mode 100644
index 0000000..cac3c50
--- /dev/null
+++ b/doc/plugins/contrib/purge.mdwn
@@ -0,0 +1,38 @@
+[[!template id=plugin name=purge core=0 author="[[ssm]]"]]
+
+IkiWiki plugin to send PURGE requests to remote http cache server (like Varnish Cache) when your content changes.
+
+PURGE requests are sent for the changed page, as well as all pages indirectly changed when ikiwiki rebuilds the web pages.
+
+# Download
+
+Download from [Github](https://github.com/ssm/ikiwiki-plugin-purge)
+
+# Configure ikiwiki
+
+    # purge_url (mandatory), the address of your cache server.
+    purge_url: http://example.com/
+
+    # purge_timeout (optional, default 5) timeout in seconds for a purge request.
+
+    # purge_method (optional, default "PURGE") HTTP method to use.
+    
+# Configure your cache server
+
+For Varnish, you'll need to add a handler for the non-standard "PURGE" method, and preferrably an ACL which restricts who can send these requests to empty your cache.
+
+    acl origin_server {
+        "localhost";
+        "192.0.2.0"/24;
+        "2001:db8::"/64;
+    }
+ 
+    sub vcl_recv {
+        if (req.method == "PURGE") {
+            if (!client.ip ~ origin_server) {
+                return(synth(405,"Not allowed."));
+            }
+            return (purge);
+        }
+    }
+

addendum: missed branch template
diff --git a/doc/bugs/svg_and_pdf_conversion_fails.mdwn b/doc/bugs/svg_and_pdf_conversion_fails.mdwn
index b5880a6..41637c5 100644
--- a/doc/bugs/svg_and_pdf_conversion_fails.mdwn
+++ b/doc/bugs/svg_and_pdf_conversion_fails.mdwn
@@ -1,3 +1,5 @@
+[[!template  id=gitbranch branch=chrysn/imgforpdf author="[[chrysn]]"]]
+
 when using the [[img plugin|plugins/img]] with an svg file, it is supposed to
 convert it into a png for display in all browsers, and because the typical use
 case is rendering small preview versions.

addendum: rationale for not changing everything
diff --git a/doc/bugs/svg_and_pdf_conversion_fails.mdwn b/doc/bugs/svg_and_pdf_conversion_fails.mdwn
index 5b910bc..b5880a6 100644
--- a/doc/bugs/svg_and_pdf_conversion_fails.mdwn
+++ b/doc/bugs/svg_and_pdf_conversion_fails.mdwn
@@ -12,6 +12,9 @@ branch.
 
 i'd prefer to go a step further, and not only convert pdf and svg files to png,
 but everything (with the possible exception of jpg files), as most other image
-formats can't be displayed in a browser anyway.
+formats can't be displayed in a browser anyway -- but i didn't in this patch
+series, as it would alter the file names of existing images, i don't know if
+that needs special care or breaks something i don't use; this way, my patches
+should be safe for inclusion.
 
 --[[chrysn]]

svg (and pdf) handling: bug and fix
diff --git a/doc/bugs/svg_and_pdf_conversion_fails.mdwn b/doc/bugs/svg_and_pdf_conversion_fails.mdwn
new file mode 100644
index 0000000..5b910bc
--- /dev/null
+++ b/doc/bugs/svg_and_pdf_conversion_fails.mdwn
@@ -0,0 +1,17 @@
+when using the [[img plugin|plugins/img]] with an svg file, it is supposed to
+convert it into a png for display in all browsers, and because the typical use
+case is rendering small preview versions.
+
+this currently doesn't work (at least with graphicsmagick-libmagick-dev-compat
+1.3.18-1) due to the sequence imagemagick options are set, needs an extension
+to work for pdfs (or any other imagemagick compatibile file) too, and should
+have an additional parameter for page selection.
+
+i've provided a series of [[!taglink patch]]es in the chrysn/imgforpdf [[git]]
+branch.
+
+i'd prefer to go a step further, and not only convert pdf and svg files to png,
+but everything (with the possible exception of jpg files), as most other image
+formats can't be displayed in a browser anyway.
+
+--[[chrysn]]
diff --git a/doc/users/chrysn/interests.mdwn b/doc/users/chrysn/interests.mdwn
index cd7acf3..2db49d1 100644
--- a/doc/users/chrysn/interests.mdwn
+++ b/doc/users/chrysn/interests.mdwn
@@ -5,6 +5,7 @@ these are the topics [[chrysn]] is or was interested in inside ikiwiki:
 * [[bugs/preprocessing loop control too tight]]
 * [[bugs/proxy.py utf8 troubles]]
 * [[bugs/pythonproxy-utf8 again]]
+* [[bugs/svg and pdf conversion fails]]
 * [[bugs/Underscores in links don't appear]]
 * [[bugs/unicode encoded urls and recentchanges]]
 * [[bugs/wrong link in recentchanges when reverting an ikiwiki outside git root]]

forgot to sign
diff --git a/doc/plugins/contrib/album/discussion.mdwn b/doc/plugins/contrib/album/discussion.mdwn
index 7fd0170..8e5c5b5 100644
--- a/doc/plugins/contrib/album/discussion.mdwn
+++ b/doc/plugins/contrib/album/discussion.mdwn
@@ -521,7 +521,7 @@ My wishlist for the plugin would include:
 >
 > For the third, you can get the same practical effect using an inline
 > as documented in the main page. --[[smcv]]
->> The downside to current behaviour is that clicking an inlined thumbnail will take you to the original album context. Previous/Next image will not match the thumbnails in the inline but the thumbnails in the album. This is a bit confusing for users and prevents using the image in multiple contexts without duplicating the image. To achieve what I'm looking for there would have to be several AlbumViewer pages for a single image.
+>> The downside to current behaviour is that clicking an inlined thumbnail will take you to the original album context. Previous/Next image will not match the thumbnails in the inline but the thumbnails in the album. This is a bit confusing for users and prevents using the image in multiple contexts without duplicating the image. To achieve what I'm looking for there would have to be several AlbumViewer pages for a single image. --kjs
 
 ----
 

kjs wishlist updated
diff --git a/doc/plugins/contrib/album/discussion.mdwn b/doc/plugins/contrib/album/discussion.mdwn
index afd9963..7fd0170 100644
--- a/doc/plugins/contrib/album/discussion.mdwn
+++ b/doc/plugins/contrib/album/discussion.mdwn
@@ -510,8 +510,9 @@ I've changed the behavior of the "slideshow" to show the next image when clickin
 My wishlist for the plugin would include:
 
 - Reading exif info from the imagefile
-- Keeping the full resolution image files out of version control
-- Being able to create new albums by tag or bym anually picking images from other albums. Could be a simple comma separated list of viewer names, or even full urls, in the album directive.
+- ~~Keeping the full resolution image files out of version control~~ Solved this by simply creating a underlay for the images. Works out of the box for my non cgi workflow.
+- Being able to create new albums by tag or by manually picking images from other albums. Could be a simple comma separated list of viewer names, or even full urls, in the album directive.
+- A counter showing **current image/total number of images in album**. This would mean that you know how many images you have left to click through before you have seen all images in an album. This gives you enought info to decide weather to click through or go back/leave.
 
 --kjs
 
@@ -520,6 +521,7 @@ My wishlist for the plugin would include:
 >
 > For the third, you can get the same practical effect using an inline
 > as documented in the main page. --[[smcv]]
+>> The downside to current behaviour is that clicking an inlined thumbnail will take you to the original album context. Previous/Next image will not match the thumbnails in the inline but the thumbnails in the album. This is a bit confusing for users and prevents using the image in multiple contexts without duplicating the image. To achieve what I'm looking for there would have to be several AlbumViewer pages for a single image.
 
 ----
 

testing notifications
diff --git a/doc/tips/monitor_page_changes_through_IRC.mdwn b/doc/tips/monitor_page_changes_through_IRC.mdwn
index 06b6c86..ebddbfe 100644
--- a/doc/tips/monitor_page_changes_through_IRC.mdwn
+++ b/doc/tips/monitor_page_changes_through_IRC.mdwn
@@ -5,3 +5,5 @@ the workaround I found so far was to join the `#ikiwiki` channel on freenode, an
     /hilight -channels #ikiwiki  -word tips/monitor_page_changes_through_IRC
 
 this will watch for any change to this page. -- [[anarcat]]
+
+hello anarcat, I'm editing your page! -- [[micah]]

dumb way
diff --git a/doc/tips/monitor_page_changes_through_IRC.mdwn b/doc/tips/monitor_page_changes_through_IRC.mdwn
new file mode 100644
index 0000000..06b6c86
--- /dev/null
+++ b/doc/tips/monitor_page_changes_through_IRC.mdwn
@@ -0,0 +1,7 @@
+because of [[bugs/notifyemail_fails_with_some_openid_providers]], I have been struggling with finding ways of being notified of changes to pages I want to watch here.
+
+the workaround I found so far was to join the `#ikiwiki` channel on freenode, and set the following "hilight" in irssi:
+
+    /hilight -channels #ikiwiki  -word tips/monitor_page_changes_through_IRC
+
+this will watch for any change to this page. -- [[anarcat]]

known bugs
diff --git a/doc/plugins/contrib/album.mdwn b/doc/plugins/contrib/album.mdwn
index 745a44e..7344a15 100644
--- a/doc/plugins/contrib/album.mdwn
+++ b/doc/plugins/contrib/album.mdwn
@@ -91,6 +91,14 @@ to download):
 
 ## Bugs
 
+* `thumbnailsize` doesn't actually work, they're always 96x96.
+  [[KathrynAndersen]] suggested a fix on the [[discussion]] page;
+  search for her name and look for a context diff.
+
+* The album index is limited to 10 images. kjs suggested a fix on
+  the [[discussion]] page: the plugin should pass `show => 0`
+  to `preprocess_inline`.
+
 * There's currently a hard-coded list of extensions that are treated as
   images: `png`, `gif`, `jpg`, `jpeg` or `mov` files. More image and video
   types could be added in future.

respond
diff --git a/doc/plugins/contrib/album/discussion.mdwn b/doc/plugins/contrib/album/discussion.mdwn
index 074e2ec..afd9963 100644
--- a/doc/plugins/contrib/album/discussion.mdwn
+++ b/doc/plugins/contrib/album/discussion.mdwn
@@ -58,6 +58,8 @@ i'm new to ikiwiki, apologies if this is dealt with elsewhere.  -brush
 
 ----
 
+## design feedback from joeyh on an earlier version
+
 You had wanted my feedback on the design of this. I have not looked at the
 code or tried it yet, but here goes. --[[Joey]]	
 
@@ -259,6 +261,8 @@ code or tried it yet, but here goes. --[[Joey]]
 
 ----
 
+## alternative "special extension" design (conclusion: "don't")
+
 '''I think the "special extension" design is a dead-end, but here's what
 happened when I tried to work out how it would work. --[[smcv]]'''
 
@@ -405,14 +409,20 @@ Things that would be nice, and are probably possible:
 
 ----
 
+## bug: unable to vary thumbnail size
+
 Hi smcv, great plugin. I am an ikiwiki newbie but so far I've had success using your plugin.
 I've integrated the jquery masonry plugin into the albumitem template and it works great.
 But is there a way to create thumnails of different sizes? I've passed thumnailsize option
 and value to album directive and while it does create the new thumbnail sizes it doesn't use them,
 The 96x96 thumbnails still appear on the page no matter what I do. - jaime
 
+> [[KathrynAndersen]] fixed this, see below. --[[smcv]]
+
 ----
 
+## failed installation
+
 Hi, the plugin looks great, but I am probably too dumb to use it ;( here is what I did:
 created page gal.mdwn with just \[\[!album\]\] directive (no arguments) and subdirectory gal/ with images in form img_1234.jpg
 
@@ -458,14 +468,45 @@ Thanks Lukas
 >> Thanks for all the work you did on the plugin! --Lukas
 
 ----
-Hi smcv, we spoke on irc the other day. Passed `show => "0"` on line 126 in album.pm to remove the limit on the thumbnails shown on the album page. Setting it on the album directive didn't work. As mentioned above by Jaime setting the thumbnailsize doesn't catch either. Or rather if I git push after changing the album directive the generated thumbnails (the image files) are the correct size as set in the directive. The html however uses the default thumbnailsize as hardcoded in album.pm and has broken thumbnails as it links to a file with the default size in the filename.
+
+## bug + patch: not all images shown on album page
+
+Hi smcv, we spoke on irc the other day. Passed `show => "0"` on line 126 in album.pm to remove the limit on the thumbnails shown on the album page. Setting it on the album directive didn't work.
+
+--kjs
+
+> That sounds like a correct solution. I'll fix that in my branch when I work on
+> this again. --[[smcv]]
+
+----
+
+## bug: thumbnailsize doesn't work
+
+As mentioned above by Jaime setting the thumbnailsize doesn't catch either. Or rather if I git push after changing the album directive the generated thumbnails (the image files) are the correct size as set in the directive. The html however uses the default thumbnailsize as hardcoded in album.pm and has broken thumbnails as it links to a file with the default size in the filename.
+
+> [[KathrynAndersen]] fixed this, see below. --[[smcv]]
 
 Issuing `ikiwiki --rebuild` knocks the system into another gear where the thumbnails show up correctly but this is only due to the html being the same as above (linking to hardcoded thumbnailsize) but the generated thumbnail images are now matching the hardcoded size ignoring the thumbnailsize attribute on the album directive.
 
 For me this behaviour is way beyond my skills to sort out (I'm no coder). The albumplugin ikiwiki combo is very attractive to me and the plugin i soo close to working!
 
+--kjs
+
+----
+
+## wishlist + patch: make clicking on the large image go to the next
+
 I've changed the behavior of the "slideshow" to show the next image when clicking the large image as downloading a full resolution image is a rare use case in a gallery of this type imho. The large clicktarget means you are likely to unnecessarily download large files otherwise. I can't quite follow the template, album.pm flow so I can't figure out how to put a "download full resolution" link on the viewer page which would be my next step. To achieve the next link i added ` link => ($nextpage or $album),` around line 454 in `my $img`
 
+--kjs
+
+> That seems reasonable. I'll consider that when I work on this
+> plugin again next. --[[smcv]]
+
+----
+
+## wishlist from kjs
+
 My wishlist for the plugin would include:
 
 - Reading exif info from the imagefile
@@ -474,8 +515,16 @@ My wishlist for the plugin would include:
 
 --kjs
 
+> I want the first two of those too, perhaps one day I'll get round to
+> implementing them.
+>
+> For the third, you can get the same practical effect using an inline
+> as documented in the main page. --[[smcv]]
+
 ----
 
+## suggested fix for thumbnail size bug
+
 I've tracked down the "always showing the 96x96 thumbnails" bug!
 
 The problem is in the pagetemplate function, which calls "thumbnail" to determine the name of the thumbnail image to use. As you know, the "img" method of generating thumbnails includes the size of the thumbnail as part of its name (to ensure that resizing thumbnails will create a new file of the correct size). The problem is... that in the pagetemplate function, the thumbnailsize is NOT passed in to the call to "thumbnail", so it always returns the default size, 96x96. Hence nothing that anyone can do will change the thumbnails to anything else. Oh, the different-sized thumbnail images ARE created, but they're never linked to.
@@ -516,10 +565,29 @@ Here's a context-diff of my fix:
 
 -- [[KathrynAndersen]]
 
+> I haven't tried this change, but it seems sane. I'll apply it
+> when I next work on this plugin.
+>
+> (OOI: why not a unified diff? The VCS world seems to have
+> settled on those as universal, and I find them easier to
+> read.)
+>
+> --[[smcv]]
+
 ----
 
+## bug: inability to show more than 10 items
+
 I've found another bug. The album plugin doesn't allow one to have more than 10 items in an album section. This is because it uses "inline" to display album sections, and the default for inline is to show only 10 items. So it only shows 10 items.
 
 What would be good is if the album directive could have a "show" parameter which is passed on to preprocess_inline, so that users could decide how many items to show (including ALL of them, if they give show=0).
 
 -- [[KathrynAndersen]]
+
+> My intention was that all items would always be shown, so I would always pass
+> `show => 0` to `preprocess_inline` (as kjs suggested above), but that must have
+> got lost somewhere. I'll apply it next time I work on this plugin.
+>
+> An optional `show` parameter would be a possible enhancement beyond that,
+> although I don't know how useful it would be; if it isn't passed, the
+> default should be 0 (unlimited). --[[smcv]]

diff --git a/doc/ikiwikiusers.mdwn b/doc/ikiwikiusers.mdwn
index dfd16d7..18dd7ca 100644
--- a/doc/ikiwikiusers.mdwn
+++ b/doc/ikiwikiusers.mdwn
@@ -89,6 +89,7 @@ Projects & Organizations
 * [[CAS Libres|http://cas-libres.poivron.org]] - A French feminist radio program.
 * [[Les Barricades|http://barricades.int.eu.org]] - A French socialist choir (CSS has been adapted from the one of [[Grésille|http://www.gresille.org]]).
 * [DKØTU Amateur Radio Station](http://www.dk0tu.de), TU Berlin
+* [[Plan A|http://www.plan-a-muenchen.de/]] - A proposal for improvement of the urban public transport in Munich (by PRO BAHN, Bund Naturschutz and others)
 
 Personal sites and blogs
 ========================

diff --git a/doc/sandbox.mdwn b/doc/sandbox.mdwn
index d11211c..89fa9ca 100644
--- a/doc/sandbox.mdwn
+++ b/doc/sandbox.mdwn
@@ -109,7 +109,7 @@ This is some preformatted text.  Each line is proceeded by four spaces.
       <child />
     </test>
 
-...Now why doesn't it work like that on my copy of ikiwiki? :(
+...Now why doesn't it work like that on my own copy of ikiwiki? :(
 
 Räksmörgås.
 

poll vote (Accept both)
diff --git a/doc/news/openid.mdwn b/doc/news/openid.mdwn
index b6aa71f..30ec2ed 100644
--- a/doc/news/openid.mdwn
+++ b/doc/news/openid.mdwn
@@ -10,4 +10,4 @@ log back in, try out the OpenID signup process if you don't already have an
 OpenID, and see how OpenID works for you. And let me know your feelings about
 making such a switch. --[[Joey]]
 
-[[!poll 72 "Accept only OpenID for logins" 21 "Accept only password logins" 47 "Accept both"]]
+[[!poll 72 "Accept only OpenID for logins" 21 "Accept only password logins" 48 "Accept both"]]

poll vote (Accept only OpenID for logins)
diff --git a/doc/news/openid.mdwn b/doc/news/openid.mdwn
index 56a69c9..b6aa71f 100644
--- a/doc/news/openid.mdwn
+++ b/doc/news/openid.mdwn
@@ -10,4 +10,4 @@ log back in, try out the OpenID signup process if you don't already have an
 OpenID, and see how OpenID works for you. And let me know your feelings about
 making such a switch. --[[Joey]]
 
-[[!poll 71 "Accept only OpenID for logins" 21 "Accept only password logins" 47 "Accept both"]]
+[[!poll 72 "Accept only OpenID for logins" 21 "Accept only password logins" 47 "Accept both"]]

diff --git a/doc/ikiwiki/directive/meta/discussion.mdwn b/doc/ikiwiki/directive/meta/discussion.mdwn
index 9ce81c7..428f454 100644
--- a/doc/ikiwiki/directive/meta/discussion.mdwn
+++ b/doc/ikiwiki/directive/meta/discussion.mdwn
@@ -76,3 +76,5 @@ I guess patching [[/ikiwiki/directive/meta]] to document the fact this attribute
      <meta name="language" content="en" />
 
 The problem is that it does not generate the lang attribute in `<html>` and that's what's required for [hyphenation](https://developer.mozilla.org/en-US/docs/Web/CSS/hyphens) so this would be welcome too!
+
+Also, being able to use the language variable in templates would be very useful for various css tweaks. — [Hugo](https://hroy.eu)

diff --git a/doc/ikiwiki/directive/meta/discussion.mdwn b/doc/ikiwiki/directive/meta/discussion.mdwn
index a0aefe0..9ce81c7 100644
--- a/doc/ikiwiki/directive/meta/discussion.mdwn
+++ b/doc/ikiwiki/directive/meta/discussion.mdwn
@@ -67,3 +67,12 @@ index 984f685..b82fa58 100644
 ----
 
 I guess patching [[/ikiwiki/directive/meta]] to document the fact this attribute is supported would be good. — [[Jon]]
+
+
+----
+
++1 the language attribute works, I see:
+
+     <meta name="language" content="en" />
+
+The problem is that it does not generate the lang attribute in `<html>` and that's what's required for [hyphenation](https://developer.mozilla.org/en-US/docs/Web/CSS/hyphens) so this would be welcome too!

link jperkin's binaries at pkgsrc.org (an ikiwiki!)
diff --git a/doc/tips/ikiwiki_on_mac_os_x.mdwn b/doc/tips/ikiwiki_on_mac_os_x.mdwn
index be9380a..a4d38f8 100644
--- a/doc/tips/ikiwiki_on_mac_os_x.mdwn
+++ b/doc/tips/ikiwiki_on_mac_os_x.mdwn
@@ -5,9 +5,15 @@
 The easiest way of installing an up-to-date ikiwiki on any version of Mac OS X is via
 [pkgsrc](http://www.pkgsrc.org/).
 
+## From source:
+
 7. [Bootstrap pkgsrc](http://www.netbsd.org/docs/pkgsrc/platforms.html#bootstrapping-pkgsrc)
 7. Run `cd .../pkgsrc/www/ikiwiki && make install clean`
 
+## From binary packages:
+
+7. [install binary packages (OSX)](http://www.pkgsrc.org/#index1h1)
+
 {OK} As of 2014/03/19, the [version of ikiwiki in pkgsrc](http://pkgsrc.se/www/ikiwiki) is 3.20140227.
 
 -----

pkgsrc updated, MacPorts still not
diff --git a/doc/tips/ikiwiki_on_mac_os_x.mdwn b/doc/tips/ikiwiki_on_mac_os_x.mdwn
index b1757af..be9380a 100644
--- a/doc/tips/ikiwiki_on_mac_os_x.mdwn
+++ b/doc/tips/ikiwiki_on_mac_os_x.mdwn
@@ -8,7 +8,7 @@ The easiest way of installing an up-to-date ikiwiki on any version of Mac OS X i
 7. [Bootstrap pkgsrc](http://www.netbsd.org/docs/pkgsrc/platforms.html#bootstrapping-pkgsrc)
 7. Run `cd .../pkgsrc/www/ikiwiki && make install clean`
 
-{OK} As of 2013/09/14, the [version of ikiwiki in pkgsrc](http://pkgsrc.se/www/ikiwiki) is 3.20130904.1.
+{OK} As of 2014/03/19, the [version of ikiwiki in pkgsrc](http://pkgsrc.se/www/ikiwiki) is 3.20140227.
 
 -----
 
@@ -33,7 +33,7 @@ enjoy
 
 Enrique Castilla
 
-[!] As of 2013/09/14, the [version of ikiwiki in MacPorts](http://www.macports.org/ports.php?by=name&substr=Ikiwiki) is 3.20110608.
+[!] As of 2014/03/19, the [version of ikiwiki in MacPorts](http://www.macports.org/ports.php?by=name&substr=Ikiwiki) is 3.20110608.
 
 -----
 

please be more specific
diff --git a/doc/tips/ikiwiki_on_mac_os_x/discussion.mdwn b/doc/tips/ikiwiki_on_mac_os_x/discussion.mdwn
index fd81b78..40ac874 100644
--- a/doc/tips/ikiwiki_on_mac_os_x/discussion.mdwn
+++ b/doc/tips/ikiwiki_on_mac_os_x/discussion.mdwn
@@ -1 +1,16 @@
 This recommended method (sc. install Ikiwiki using pkgsrc) is not compatible with homebrew and the packages installed via homebrew,  and, therefore, not always a viable solution to installing Ikiwiki on Mac computers.
+
+> In what way is it "not compatible"? Have you tried it? I can't
+> think of any technical reason why having a working Homebrew
+> installation would prevent one from also having a working pkgsrc
+> installation, or vice versa. (MacPorts and Fink can certainly coexist
+> with each other and with other package managers on the same system.)
+>
+> We used to direct OS X ikiwiki users to MacPorts, but the version
+> there is almost three years old. pkgsrc's ikiwiki stays up to date
+> because I keep it that way. If someone packages ikiwiki for Homebrew
+> and reliably keeps the package updated, then we could discuss
+> whether pointing folks at Homebrew is better advice than what's
+> currently being given here. In the meantime, if you've tried and
+> failed to install ikiwiki from pkgsrc on OS X, please report your
+> problem in detail so it can be addressed in some way. --[[schmonz]]

diff --git a/doc/tips/ikiwiki_on_mac_os_x/discussion.mdwn b/doc/tips/ikiwiki_on_mac_os_x/discussion.mdwn
new file mode 100644
index 0000000..fd81b78
--- /dev/null
+++ b/doc/tips/ikiwiki_on_mac_os_x/discussion.mdwn
@@ -0,0 +1 @@
+This recommended method (sc. install Ikiwiki using pkgsrc) is not compatible with homebrew and the packages installed via homebrew,  and, therefore, not always a viable solution to installing Ikiwiki on Mac computers.

diff --git a/doc/forum/How_to_rename_all_markdown_files_from___42__.mdwn_to___42__.md__63__.mdwn b/doc/forum/How_to_rename_all_markdown_files_from___42__.mdwn_to___42__.md__63__.mdwn
new file mode 100644
index 0000000..d11f7a3
--- /dev/null
+++ b/doc/forum/How_to_rename_all_markdown_files_from___42__.mdwn_to___42__.md__63__.mdwn
@@ -0,0 +1,3 @@
+Github does not take .mdwn as Markdown files:      https://github.com/github/markup/blob/b865add2e053f8cea3d7f4d9dcba001bdfd78994/lib/github/markups.rb#L1 
+
+I'd like to use filename extensions complaint to GitHub.  My question is after renaming all markdown files from *.mdwn to *.md how do I correct all the dependencies?   Does simply committing the renamed files to the source repository suffice?

switch link syntax so this page works in the basewiki
diff --git a/doc/ikiwiki/directive/format.mdwn b/doc/ikiwiki/directive/format.mdwn
index a32ad05..04ed139 100644
--- a/doc/ikiwiki/directive/format.mdwn
+++ b/doc/ikiwiki/directive/format.mdwn
@@ -18,7 +18,7 @@ some other format:
 		4
 	"""]]
 
-Note that if the [[highlight|plugins/highlight]] plugin is enabled, this directive can also be
+Note that if the [[!iki plugins/highlight desc=highlight]] plugin is enabled, this directive can also be
 used to display syntax highlighted code. Many languages and formats are
 supported. For example:
 

vimoutliner.org seems to be taken over by spammers, refer to Github page instead
diff --git a/doc/plugins/otl.mdwn b/doc/plugins/otl.mdwn
index d890b01..f12d6ed 100644
--- a/doc/plugins/otl.mdwn
+++ b/doc/plugins/otl.mdwn
@@ -2,5 +2,5 @@
 [[!tag type/format]]
 
 This plugin allows ikiwiki to process `.otl` outline files, as created by 
-[vimoutliner](http://www.vimoutliner.org/). To use it, you need to have 
+[vimoutliner](https://github.com/vimoutliner/vimoutliner). To use it, you need to have 
 vimoutliner installed, since it uses the `otl2html` program.

Add link to highlight plugin.
diff --git a/doc/ikiwiki/directive/format.mdwn b/doc/ikiwiki/directive/format.mdwn
index 7d11d22..a32ad05 100644
--- a/doc/ikiwiki/directive/format.mdwn
+++ b/doc/ikiwiki/directive/format.mdwn
@@ -18,7 +18,7 @@ some other format:
 		4
 	"""]]
 
-Note that if the highlight plugin is enabled, this directive can also be
+Note that if the [[highlight|plugins/highlight]] plugin is enabled, this directive can also be
 used to display syntax highlighted code. Many languages and formats are
 supported. For example:
 

pythonproxy utf8 trouble again
diff --git a/doc/bugs/pythonproxy-utf8_again.mdwn b/doc/bugs/pythonproxy-utf8_again.mdwn
new file mode 100644
index 0000000..96b0600
--- /dev/null
+++ b/doc/bugs/pythonproxy-utf8_again.mdwn
@@ -0,0 +1,16 @@
+[[!template  id=gitbranch branch=chrysn/more-proxy-utf8-fail author="[[chrysn]]"]]
+
+the recently introduced fixes for [[crashes in the python proxy even if disabled]]
+caused the typical python2 implicit conversion failures ("'ascii' codec
+can't...") on my debian sid system -- to fix it, i had to revert commit 154c4ea9e.
+
+i did not dig down all the way to the xml / xmlrpc modules, but my impression
+is that some module changed its behavior between stable and sid and now
+generates `unicode` strings instead of `str`.
+
+a [[patch]] to allow both versions by inspecting the types and en-/decoding on
+demand should work both for anarcat's and my case. i did not test the python3
+version, but i'm pretty sure it was already broken after the abovementioned
+patch.
+
+-- [[chrysn]]
diff --git a/doc/users/chrysn/interests.mdwn b/doc/users/chrysn/interests.mdwn
index aafe7e4..cd7acf3 100644
--- a/doc/users/chrysn/interests.mdwn
+++ b/doc/users/chrysn/interests.mdwn
@@ -4,6 +4,7 @@ these are the topics [[chrysn]] is or was interested in inside ikiwiki:
 * [[bugs/methodResponse in add__95__plugins]]
 * [[bugs/preprocessing loop control too tight]]
 * [[bugs/proxy.py utf8 troubles]]
+* [[bugs/pythonproxy-utf8 again]]
 * [[bugs/Underscores in links don't appear]]
 * [[bugs/unicode encoded urls and recentchanges]]
 * [[bugs/wrong link in recentchanges when reverting an ikiwiki outside git root]]

add $SELF
diff --git a/doc/ikiwikiusers.mdwn b/doc/ikiwikiusers.mdwn
index ea0e98d..dfd16d7 100644
--- a/doc/ikiwikiusers.mdwn
+++ b/doc/ikiwikiusers.mdwn
@@ -188,3 +188,4 @@ Personal sites and blogs
  * [Z is for Zombies](http://blog.zouish.org/) — personal blog/site of Francesca Ciceri
 * Julien Lefrique's [homepage](http://julien.lefrique.name/), hosted on [GitHub pages](https://github.com/jlefrique/jlefrique.github.com) with CGI disabled
 * [Anarcat's homepage](http://anarcat.ath.cx/) - with a custom [[theme|theme_market]]
+* [Wouter's Blog](http://grep.be/blog/), with a custom CSS stylesheet based off the rest of his website.

diff --git a/doc/bugs/listdirectives_doesn__39__t_register_a_link.mdwn b/doc/bugs/listdirectives_doesn__39__t_register_a_link.mdwn
index aa7a590..ad52d78 100644
--- a/doc/bugs/listdirectives_doesn__39__t_register_a_link.mdwn
+++ b/doc/bugs/listdirectives_doesn__39__t_register_a_link.mdwn
@@ -96,8 +96,8 @@ The [[ikiwiki/directive/listdirectives]]` directive doesn't register a link betw
 >>> --[[smcv]]
 >>>> 
 >>>> (I'll interpet Joeys silence as a good sign ;-). Is there a difference between "link to it" and "path to it"? If we assume autoindex produces bonafide "first class" links there shouldn't be one!?
+>>>>
 >>>> So far your idea sounds great, says me without any knowledge of the source. I'll try to grok it. Is there a medium for silly questions, a wiki seems not the right fit for that? -- [[holger]]
-
 >>>>> Yes, there *has* to be a difference between a first class wikilink
 >>>>> and the thing to which `map` and `inline` can contribute.
 >>>>> `map` and `inline` use a pagespec to decide what they include,
@@ -110,3 +110,5 @@ The [[ikiwiki/directive/listdirectives]]` directive doesn't register a link betw
 >>>>>
 >>>>> If `inline` generated links, it would inline exactly those pages that
 >>>>> it doesn't inline. That's never going to end well :-) --[[smcv]]
+>>>>>> We have to differentiate between what users of ikiwiki consider first class links and what internally is happening. For the user any link contributing to the structured access tree is first class. The code on the other hand has to differentiate between the static links, then generated links, then orphan links. Three "passes", even your proposed solution could be seen as adding another pass since the orphan plugin has to run after all the plugins generating (first class user) links.   -- [[holger]]
+

explain the cycle that is broken by "map and inline can't generate wikilinks"
diff --git a/doc/bugs/listdirectives_doesn__39__t_register_a_link.mdwn b/doc/bugs/listdirectives_doesn__39__t_register_a_link.mdwn
index 03eacd0..aa7a590 100644
--- a/doc/bugs/listdirectives_doesn__39__t_register_a_link.mdwn
+++ b/doc/bugs/listdirectives_doesn__39__t_register_a_link.mdwn
@@ -97,3 +97,16 @@ The [[ikiwiki/directive/listdirectives]]` directive doesn't register a link betw
 >>>> 
 >>>> (I'll interpet Joeys silence as a good sign ;-). Is there a difference between "link to it" and "path to it"? If we assume autoindex produces bonafide "first class" links there shouldn't be one!?
 >>>> So far your idea sounds great, says me without any knowledge of the source. I'll try to grok it. Is there a medium for silly questions, a wiki seems not the right fit for that? -- [[holger]]
+
+>>>>> Yes, there *has* to be a difference between a first class wikilink
+>>>>> and the thing to which `map` and `inline` can contribute.
+>>>>> `map` and `inline` use a pagespec to decide what they include,
+>>>>> and pagespecs can't be evaluated and get a correct answer until the
+>>>>> set of links has been collected, because their results often depend
+>>>>> on the set of links. Otherwise, suppose you had a page `foo` whose only
+>>>>> contents were this:
+>>>>>
+>>>>>     \[[!inline pages="!backlink(foo)"]]
+>>>>>
+>>>>> If `inline` generated links, it would inline exactly those pages that
+>>>>> it doesn't inline. That's never going to end well :-) --[[smcv]]

diff --git a/doc/bugs/listdirectives_doesn__39__t_register_a_link.mdwn b/doc/bugs/listdirectives_doesn__39__t_register_a_link.mdwn
index aad843d..03eacd0 100644
--- a/doc/bugs/listdirectives_doesn__39__t_register_a_link.mdwn
+++ b/doc/bugs/listdirectives_doesn__39__t_register_a_link.mdwn
@@ -96,4 +96,4 @@ The [[ikiwiki/directive/listdirectives]]` directive doesn't register a link betw
 >>> --[[smcv]]
 >>>> 
 >>>> (I'll interpet Joeys silence as a good sign ;-). Is there a difference between "link to it" and "path to it"? If we assume autoindex produces bonafide "first class" links there shouldn't be one!?
->>>> So far your idea sounds great, says me without any knowledge of the source. I'll try to grok it. Is there a medium for silly questions, a wiki seems not the right fit for that?
+>>>> So far your idea sounds great, says me without any knowledge of the source. I'll try to grok it. Is there a medium for silly questions, a wiki seems not the right fit for that? -- [[holger]]

diff --git a/doc/bugs/listdirectives_doesn__39__t_register_a_link.mdwn b/doc/bugs/listdirectives_doesn__39__t_register_a_link.mdwn
index b462948..aad843d 100644
--- a/doc/bugs/listdirectives_doesn__39__t_register_a_link.mdwn
+++ b/doc/bugs/listdirectives_doesn__39__t_register_a_link.mdwn
@@ -94,3 +94,6 @@ The [[ikiwiki/directive/listdirectives]]` directive doesn't register a link betw
 >>> "add_reachable". On the other hand, maybe that's too computationally
 >>> intensive to actually do; I haven't tried it.
 >>> --[[smcv]]
+>>>> 
+>>>> (I'll interpet Joeys silence as a good sign ;-). Is there a difference between "link to it" and "path to it"? If we assume autoindex produces bonafide "first class" links there shouldn't be one!?
+>>>> So far your idea sounds great, says me without any knowledge of the source. I'll try to grok it. Is there a medium for silly questions, a wiki seems not the right fit for that?

unindent the templatebody version to top level, it's getting hard to read otherwise
diff --git a/doc/bugs/template_creation_error.mdwn b/doc/bugs/template_creation_error.mdwn
index 8bdda37..aae75a3 100644
--- a/doc/bugs/template_creation_error.mdwn
+++ b/doc/bugs/template_creation_error.mdwn
@@ -194,63 +194,64 @@ Please, let me know what to do to avoid this kind of error.
 >>>>>
 >>>>> --[[chrysn]]
 
->>>>>> [[!template id=gitbranch author="[[smcv]]" branch=smcv/ready/templatebody
-         browse=http://git.pseudorandom.co.uk/smcv/ikiwiki.git/shortlog/refs/heads/ready/templatebody]]
->>>>>> [[!tag patch]]
->>>>>> Branch and directive renamed to `ready/templatebody` as chrysn suggested.
->>>>>> It's on-by-default now (or will be if that branch is merged).
->>>>>> Joey, any chance you could review this?
->>>>>>
->>>>>> There is one known buglet: `template_syntax.t` asserts that the entire
->>>>>> file is a valid HTML::Template, whereas it would ideally be doing the
->>>>>> same logic as IkiWiki itself. I don't think that's serious. --[[smcv]]
+----
 
->>>>>>> Looking over this, I notice it adds a hash containing all scanned
->>>>>>> files. This seems to me to be potentially a scalability problem on
->>>>>>> rebuild of a site with many pages. Ikiwiki already keeps a lot
->>>>>>> of info in memory, and this adds to it, for what is a fairly
->>>>>>> minor reason. It seems to me there should be a way to avoid this. --[[Joey]] 
+[[!template id=gitbranch author="[[smcv]]" branch=smcv/ready/templatebody
+  browse=http://git.pseudorandom.co.uk/smcv/ikiwiki.git/shortlog/refs/heads/ready/templatebody]]
+[[!tag patch]]
+Branch and directive renamed to `ready/templatebody` as chrysn suggested.
+It's on-by-default now (or will be if that branch is merged).
+Joey, any chance you could review this?
 
->>>>>>>> Maybe. Are plugins expected to cope with scanning the same
->>>>>>>> page more than once? If so, it's just a tradeoff between
->>>>>>>> "spend more time scanning the template repeatedly" and
->>>>>>>> "spend more memory on avoiding it", and it would be OK to
->>>>>>>> omit that, or reduce it to a set of scanned *templates*
->>>>>>>> (in practice that would mean scanning each template twice
->>>>>>>> in a rebuild). --s
+There is one known buglet: `template_syntax.t` asserts that the entire
+file is a valid HTML::Template, whereas it would ideally be doing the
+same logic as IkiWiki itself. I don't think that's serious. --[[smcv]]
 
->>>>>>>>> [Commit f7303db5](http://source.ikiwiki.branchable.com/?p=source.git;a=commitdiff;h=f7303db5)
->>>>>>>>> suggests that scanning the same page more than once is problematic,
->>>>>>>>> so that solution is probably not going to work.
->>>>>>>>>
->>>>>>>>> The best idea I've come up with so far is to track whether
->>>>>>>>> we're in the scan or render phase. If we're in the scan
->>>>>>>>> phase, I think we do need to keep track of which pages
->>>>>>>>> we've scanned, so we don't do them again? (Or perhaps that's
->>>>>>>>> unnecessary - commit f7303db5 removed a scan call that's in
->>>>>>>>> the render phase.) If we're in the render phase, we can assume
->>>>>>>>> that all changed pages have been scanned already, so we can
->>>>>>>>> drop the contents of `%scanned` and rely on a single boolean
->>>>>>>>> flag instead.
->>>>>>>>>
->>>>>>>>> `%scanned` is likely to be no larger than `%rendered`, which
->>>>>>>>> we already track, and whose useful lifetime does not overlap
->>>>>>>>> with `%scanned` now. I was tempted to merge them both and call
->>>>>>>>> the result `%done_in_this_phase`, but that would lead to really
->>>>>>>>> confusing situations if a bug led to `render` being called sooner
->>>>>>>>> than it ought to be.
->>>>>>>>>
->>>>>>>>> My ulterior motive here is that I would like to formalize
->>>>>>>>> the existence of different phases of wiki processing - at the
->>>>>>>>> moment there are at least two phases, namely "it's too soon to
->>>>>>>>> match pagespecs reliably" and "everything has been scanned,
->>>>>>>>> you may use pagespecs now", but those phases don't have names,
->>>>>>>>> so [[plugins/write]] doesn't describe them.
->>>>>>>>>
->>>>>>>>> I'm also considering adding warnings
->>>>>>>>> if people try to match a pagespec before scanning has finished,
->>>>>>>>> which can't possibly guarantee the right result, as discussed in
->>>>>>>>> [[conditional_preprocess_during_scan]]. My `wip-too-soon` branch
->>>>>>>>> is a start towards that; the docwiki builds successfully, but
->>>>>>>>> the tests that use IkiWiki internals also need updating to
->>>>>>>>> set `$phase = PHASE_RENDER` before they start preprocessing. --s
+> Looking over this, I notice it adds a hash containing all scanned
+> files. This seems to me to be potentially a scalability problem on
+> rebuild of a site with many pages. Ikiwiki already keeps a lot
+> of info in memory, and this adds to it, for what is a fairly
+> minor reason. It seems to me there should be a way to avoid this. --[[Joey]] 
+
+>> Maybe. Are plugins expected to cope with scanning the same
+>> page more than once? If so, it's just a tradeoff between
+>> "spend more time scanning the template repeatedly" and
+>> "spend more memory on avoiding it", and it would be OK to
+>> omit that, or reduce it to a set of scanned *templates*
+>> (in practice that would mean scanning each template twice
+>> in a rebuild). --s
+>>> [Commit f7303db5](http://source.ikiwiki.branchable.com/?p=source.git;a=commitdiff;h=f7303db5)
+>>> suggests that scanning the same page more than once is problematic,
+>>> so that solution is probably not going to work.
+>>>
+>>> The best idea I've come up with so far is to track whether
+>>> we're in the scan or render phase. If we're in the scan
+>>> phase, I think we do need to keep track of which pages
+>>> we've scanned, so we don't do them again? (Or perhaps that's
+>>> unnecessary - commit f7303db5 removed a scan call that's in
+>>> the render phase.) If we're in the render phase, we can assume
+>>> that all changed pages have been scanned already, so we can
+>>> drop the contents of `%scanned` and rely on a single boolean
+>>> flag instead.
+>>>
+>>> `%scanned` is likely to be no larger than `%rendered`, which
+>>> we already track, and whose useful lifetime does not overlap
+>>> with `%scanned` now. I was tempted to merge them both and call
+>>> the result `%done_in_this_phase`, but that would lead to really
+>>> confusing situations if a bug led to `render` being called sooner
+>>> than it ought to be.
+>>>
+>>> My ulterior motive here is that I would like to formalize
+>>> the existence of different phases of wiki processing - at the
+>>> moment there are at least two phases, namely "it's too soon to
+>>> match pagespecs reliably" and "everything has been scanned,
+>>> you may use pagespecs now", but those phases don't have names,
+>>> so [[plugins/write]] doesn't describe them.
+>>>
+>>> I'm also considering adding warnings
+>>> if people try to match a pagespec before scanning has finished,
+>>> which can't possibly guarantee the right result, as discussed in
+>>> [[conditional_preprocess_during_scan]]. My `wip-too-soon` branch
+>>> is a start towards that; the docwiki builds successfully, but
+>>> the tests that use IkiWiki internals also need updating to
+>>> set `$phase = PHASE_RENDER` before they start preprocessing. --s

branch updated
diff --git a/doc/bugs/template_creation_error.mdwn b/doc/bugs/template_creation_error.mdwn
index f14652e..8bdda37 100644
--- a/doc/bugs/template_creation_error.mdwn
+++ b/doc/bugs/template_creation_error.mdwn
@@ -218,3 +218,39 @@ Please, let me know what to do to avoid this kind of error.
 >>>>>>>> omit that, or reduce it to a set of scanned *templates*
 >>>>>>>> (in practice that would mean scanning each template twice
 >>>>>>>> in a rebuild). --s
+
+>>>>>>>>> [Commit f7303db5](http://source.ikiwiki.branchable.com/?p=source.git;a=commitdiff;h=f7303db5)
+>>>>>>>>> suggests that scanning the same page more than once is problematic,
+>>>>>>>>> so that solution is probably not going to work.
+>>>>>>>>>
+>>>>>>>>> The best idea I've come up with so far is to track whether
+>>>>>>>>> we're in the scan or render phase. If we're in the scan
+>>>>>>>>> phase, I think we do need to keep track of which pages
+>>>>>>>>> we've scanned, so we don't do them again? (Or perhaps that's
+>>>>>>>>> unnecessary - commit f7303db5 removed a scan call that's in
+>>>>>>>>> the render phase.) If we're in the render phase, we can assume
+>>>>>>>>> that all changed pages have been scanned already, so we can
+>>>>>>>>> drop the contents of `%scanned` and rely on a single boolean
+>>>>>>>>> flag instead.
+>>>>>>>>>
+>>>>>>>>> `%scanned` is likely to be no larger than `%rendered`, which
+>>>>>>>>> we already track, and whose useful lifetime does not overlap
+>>>>>>>>> with `%scanned` now. I was tempted to merge them both and call
+>>>>>>>>> the result `%done_in_this_phase`, but that would lead to really
+>>>>>>>>> confusing situations if a bug led to `render` being called sooner
+>>>>>>>>> than it ought to be.
+>>>>>>>>>
+>>>>>>>>> My ulterior motive here is that I would like to formalize
+>>>>>>>>> the existence of different phases of wiki processing - at the
+>>>>>>>>> moment there are at least two phases, namely "it's too soon to
+>>>>>>>>> match pagespecs reliably" and "everything has been scanned,
+>>>>>>>>> you may use pagespecs now", but those phases don't have names,
+>>>>>>>>> so [[plugins/write]] doesn't describe them.
+>>>>>>>>>
+>>>>>>>>> I'm also considering adding warnings
+>>>>>>>>> if people try to match a pagespec before scanning has finished,
+>>>>>>>>> which can't possibly guarantee the right result, as discussed in
+>>>>>>>>> [[conditional_preprocess_during_scan]]. My `wip-too-soon` branch
+>>>>>>>>> is a start towards that; the docwiki builds successfully, but
+>>>>>>>>> the tests that use IkiWiki internals also need updating to
+>>>>>>>>> set `$phase = PHASE_RENDER` before they start preprocessing. --s

escape pagespec
diff --git a/doc/bugs/enabling_or_disabling_plugin_x_does_not_rebuild_pages_that_use_enabled__40__x__41__.mdwn b/doc/bugs/enabling_or_disabling_plugin_x_does_not_rebuild_pages_that_use_enabled__40__x__41__.mdwn
index e7c6cfb..4b4adb2 100644
--- a/doc/bugs/enabling_or_disabling_plugin_x_does_not_rebuild_pages_that_use_enabled__40__x__41__.mdwn
+++ b/doc/bugs/enabling_or_disabling_plugin_x_does_not_rebuild_pages_that_use_enabled__40__x__41__.mdwn
@@ -1,6 +1,6 @@
 If you have a page like
 
-    [[!if test="enabled(smileys)" then=":-P"]]
+    \[[!if test="enabled(smileys)" then=":-P"]]
 
 then enabling or disabling the smileys plugin will not rebuild it.
 

new bug
diff --git a/doc/bugs/enabling_or_disabling_plugin_x_does_not_rebuild_pages_that_use_enabled__40__x__41__.mdwn b/doc/bugs/enabling_or_disabling_plugin_x_does_not_rebuild_pages_that_use_enabled__40__x__41__.mdwn
new file mode 100644
index 0000000..e7c6cfb
--- /dev/null
+++ b/doc/bugs/enabling_or_disabling_plugin_x_does_not_rebuild_pages_that_use_enabled__40__x__41__.mdwn
@@ -0,0 +1,11 @@
+If you have a page like
+
+    [[!if test="enabled(smileys)" then=":-P"]]
+
+then enabling or disabling the smileys plugin will not rebuild it.
+
+Unfortunately, I can't think of a good way to solve this without
+introducing a special case for `enabled()` in Render.pm, either a
+new dependency type `"enabled(smileys)" => $DEPENDS_ENABLED`
+or a special case that treats `"enabled(smileys)" => $DEPENDS_PRESENCE`
+differently. --[[smcv]]

Point to my Email::Send patch.
diff --git a/doc/bugs/password_reset_fails_with___34__Wide_character_in_subroutine_entry__34__.mdwn b/doc/bugs/password_reset_fails_with___34__Wide_character_in_subroutine_entry__34__.mdwn
index b49fdb5..b9452a5 100644
--- a/doc/bugs/password_reset_fails_with___34__Wide_character_in_subroutine_entry__34__.mdwn
+++ b/doc/bugs/password_reset_fails_with___34__Wide_character_in_subroutine_entry__34__.mdwn
@@ -24,3 +24,6 @@ Help! :) --[[anarcat]]
 > (If you know Python 2, the analogous situation would be "doesn't
 > know how to send unicode objects, so you have to get a str object
 > with `a_unicode_object.encode('utf-8')`".) --[[smcv]]
+
+>> Shameless plug: [[todo/passwordauth:_sendmail_interface]].  Though, I have
+>> no idea whether that is UTF-8-safe.  --[[tschwinge]]
diff --git a/doc/todo/passwordauth:_sendmail_interface.mdwn b/doc/todo/passwordauth:_sendmail_interface.mdwn
index aba651e..a640d65 100644
--- a/doc/todo/passwordauth:_sendmail_interface.mdwn
+++ b/doc/todo/passwordauth:_sendmail_interface.mdwn
@@ -42,6 +42,8 @@ Remaining TODOs:
   * Resolve TODOs as denoted inside the patch.
   * Update for the last years of ikiwiki development, such as adapting the
     [[plugins/notifyemail]] plugin.
+  * Is this
+    [[UTF-8-safe|bugs/password_reset_fails_with___34__Wide_character_in_subroutine_entry__34__]]?
   * Is it worthwhile to use and depend on [[!cpan Return::Value]]
     just for this bit of functionality?
   * Debian news file.

Reanimate some of my URLs.
diff --git a/doc/bugs/Error:_no_text_was_copied_in_this_page_--_missing_page_dependencies.mdwn b/doc/bugs/Error:_no_text_was_copied_in_this_page_--_missing_page_dependencies.mdwn
index 0082eed..0bbf609 100644
--- a/doc/bugs/Error:_no_text_was_copied_in_this_page_--_missing_page_dependencies.mdwn
+++ b/doc/bugs/Error:_no_text_was_copied_in_this_page_--_missing_page_dependencies.mdwn
@@ -2,7 +2,7 @@ That one has bitten me for some time; here is the minimal testcase.  There is
 also an equivalent (I suppose) problem when using another plugin, but I hope
 it's enough to track it down for this one.
 
-    $ tar -xj < [bug-dep_order.tar.bz2](http://schwinge.homeip.net/~thomas/tmp/bug-dep_order.tar.bz2)
+    $ tar -xj < [bug-dep_order.tar.bz2](http://nic-nac-project.de/~schwinge/ikiwiki/bug-dep_order.tar.bz2)
     $ cd bug-dep_order/
     $ ./render_locally
     [...]
diff --git a/doc/bugs/cutpaste.pm:_missing_filter_call.mdwn b/doc/bugs/cutpaste.pm:_missing_filter_call.mdwn
index 4b22fd0..de42960 100644
--- a/doc/bugs/cutpaste.pm:_missing_filter_call.mdwn
+++ b/doc/bugs/cutpaste.pm:_missing_filter_call.mdwn
@@ -1,7 +1,7 @@
 Consider this:
 
-    $ wget http://schwinge.homeip.net/~thomas/tmp/cutpaste_filter.tar.bz2
-    $ wget http://schwinge.homeip.net/~thomas/tmp/cutpaste_filter.patch
+    $ wget http://nic-nac-project.de/~schwinge/ikiwiki/cutpaste_filter.tar.bz2
+    $ wget http://nic-nac-project.de/~schwinge/ikiwiki/0001-cutpaste.pm-missing-filter-call.patch
     
     $ tar -xj < cutpaste_filter.tar.bz2
     $ cd cutpaste_filter/
diff --git a/doc/forum/cutpaste.pm_not_only_file-local.mdwn b/doc/forum/cutpaste.pm_not_only_file-local.mdwn
index 0c5221c..c75fc53 100644
--- a/doc/forum/cutpaste.pm_not_only_file-local.mdwn
+++ b/doc/forum/cutpaste.pm_not_only_file-local.mdwn
@@ -3,7 +3,7 @@ has \[[!cut id=foo text="foo"]], and fileB does \[[!absorb pagenames=fileA]],
 and can then use \[[!paste id=foo]].
 
 Therefore, I've written an [*absorb* directive /
-plugin](http://schwinge.homeip.net/~thomas/tmp/absorb.pm), which is meant to
+plugin](http://nic-nac-project.de/~schwinge/ikiwiki/absorb.pm), which is meant to
 absorb pages in order to get hold of their *cut* and *copy* directives'
 contents.  This does work as expected.  But it also absorbs page fileA's *meta*
 values, like a *meta title*, etc.  How to avoid / solve this?
diff --git a/doc/todo/__42__forward__42__ing_functionality_for_the_meta_plugin.mdwn b/doc/todo/__42__forward__42__ing_functionality_for_the_meta_plugin.mdwn
index b3804d6..dd007b9 100644
--- a/doc/todo/__42__forward__42__ing_functionality_for_the_meta_plugin.mdwn
+++ b/doc/todo/__42__forward__42__ing_functionality_for_the_meta_plugin.mdwn
@@ -3,9 +3,6 @@ to the [[`meta`_plugin|plugins/meta]].
 
 > [[done]], with some changes --[[Joey]]
 
-Find the most recent version at
-<http://schwinge.homeip.net/~thomas/tmp/meta_forward.patch>.
-
 I can't use `scrub(...)`, as that will strip out the forwarding HTML command.
 How to deal with that?
 
diff --git a/doc/todo/passwordauth:_sendmail_interface.mdwn b/doc/todo/passwordauth:_sendmail_interface.mdwn
index 5562409..aba651e 100644
--- a/doc/todo/passwordauth:_sendmail_interface.mdwn
+++ b/doc/todo/passwordauth:_sendmail_interface.mdwn
@@ -35,11 +35,13 @@ in the ikiwiki source code, where emailing is done.
 OK, so I'll have a look at replacing all email handling with *Email::Send*.
 
 [[!tag patch]]
-*<http://schwinge.homeip.net/~thomas/tmp/ikiwiki-sendmail.patch>*
+*<http://nic-nac-project.de/~schwinge/ikiwiki/0001-Use-Email-Send-instead-of-Mail-Sendmail.patch>*
 
 Remaining TODOs:
 
   * Resolve TODOs as denoted inside the patch.
+  * Update for the last years of ikiwiki development, such as adapting the
+    [[plugins/notifyemail]] plugin.
   * Is it worthwhile to use and depend on [[!cpan Return::Value]]
     just for this bit of functionality?
   * Debian news file.

diagnosis
diff --git a/doc/bugs/password_reset_fails_with___34__Wide_character_in_subroutine_entry__34__.mdwn b/doc/bugs/password_reset_fails_with___34__Wide_character_in_subroutine_entry__34__.mdwn
index b688430..b49fdb5 100644
--- a/doc/bugs/password_reset_fails_with___34__Wide_character_in_subroutine_entry__34__.mdwn
+++ b/doc/bugs/password_reset_fails_with___34__Wide_character_in_subroutine_entry__34__.mdwn
@@ -5,3 +5,22 @@ We get the following error in a password reset:
     Error: Wide character in subroutine entry at /usr/share/perl5/Mail/Sendmail.pm line 308.
 
 Help! :) --[[anarcat]]
+
+> I assume this means Mail::Sendmail doesn't know how to send Unicode
+> strings, so any string passed to it (or any message body, or something?)
+> will need to be passed through `encode_utf8()`. It looks as though
+> Mail::Sendmail also defaults to
+>
+>     Content-Type: 'text/plain; charset="iso-8859-1"'
+>
+> so it'll need a `'Content-Type' => 'text/plain; charset="utf-8"'`
+> too.
+>
+> I'm disappointed to see how many of the library modules used by ikiwiki
+> are not Unicode-clean... but then again, Mail::Sendmail was last released
+> in 2003 so it's hardly surprising. I wonder whether [[!cpan Email::Sender]]
+> is any better?
+>
+> (If you know Python 2, the analogous situation would be "doesn't
+> know how to send unicode objects, so you have to get a str object
+> with `a_unicode_object.encode('utf-8')`".) --[[smcv]]

another unicode problem, again with the title
diff --git a/doc/bugs/password_reset_fails_with___34__Wide_character_in_subroutine_entry__34__.mdwn b/doc/bugs/password_reset_fails_with___34__Wide_character_in_subroutine_entry__34__.mdwn
new file mode 100644
index 0000000..b688430
--- /dev/null
+++ b/doc/bugs/password_reset_fails_with___34__Wide_character_in_subroutine_entry__34__.mdwn
@@ -0,0 +1,7 @@
+Similar to [[bugs/syslog_fails_with_non-ASCII_wikinames]], this bug happens when the wiki name has non-ascii characters in the site name. In my case, it has the "CⒶTS" string.
+
+We get the following error in a password reset:
+
+    Error: Wide character in subroutine entry at /usr/share/perl5/Mail/Sendmail.pm line 308.
+
+Help! :) --[[anarcat]]

documentation merge request
diff --git a/doc/todo/document_dependency_influences_in_code.mdwn b/doc/todo/document_dependency_influences_in_code.mdwn
new file mode 100644
index 0000000..18afb3d
--- /dev/null
+++ b/doc/todo/document_dependency_influences_in_code.mdwn
@@ -0,0 +1,22 @@
+[[!template id=gitbranch branch=smcv/ready/document-success-reason author="[[smcv]]"
+browse=http://git.pseudorandom.co.uk/smcv/ikiwiki.git/shortlog/refs/heads/ready/document-success-reason]]
+[[!tag patch]]
+
+Whenever I look at dependency calculation, for instance to solve
+[[bugs/editing gitbranch template is really slow]], it takes me a while to
+get my head round the concept of influences. The design documentation is
+in [[todo/dependency_types]], but that takes the form of a long discussion
+between [[Joey]] and [[Will]], so it's difficult to tell which of the
+attempts to define influences were incorrect or have been superseded.
+
+I think it would be valuable to have brief documentation
+as doc-comments in the source code. My branch adds some;
+please confirm whether I got it right? :-)
+
+It would also be great to have a definition of what
+should or shouldn't be counted as an influence, and which influences
+should count as static or dynamic, perhaps analogous to
+[git-annex's design pages](http://git-annex.branchable.com/design/)
+and linked from the `match_foo` section of [[plugins/write]]. I haven't
+written this myself because I'm somewhat stuck on the subtlety of what
+"indirectly influenced" means... --[[smcv]]

new bug report with patch
diff --git a/doc/bugs/possible_to_post_comments_that_will_not_be_displayed.mdwn b/doc/bugs/possible_to_post_comments_that_will_not_be_displayed.mdwn
new file mode 100644
index 0000000..488fa00
--- /dev/null
+++ b/doc/bugs/possible_to_post_comments_that_will_not_be_displayed.mdwn
@@ -0,0 +1,32 @@
+[[!template id=gitbranch branch=smcv/ready/comments author="[[smcv]]"
+browse="http://git.pseudorandom.co.uk/smcv/ikiwiki.git/shortlog/refs/heads/ready/comments"]]
+[[!tag patch]]
+
+The ability to post comments depends on several factors:
+
+* `comments_pagespec` controls whether comments on a particular
+  page will be displayed
+* `comments_closed_pagespec` controls whether comments on
+  a particular page are allowed
+* the `check_canedit` call controls whether comments are allowed
+  for a particular combination of page and user
+
+If `check_canedit` says that a user can post a comment
+(in particular, if [[plugins/opendiscussion]] is enabled or
+[[plugins/lockedit]] is disabled or permissive),
+and `comments_closed_pagespec` does not contradict it,
+then users who construct a `do=comment` CGI URL manually
+can post comments that will not be displayed. I don't think
+this is a security flaw as such, which is why I'm not
+reporting it privately, but it violates least-astonishment.
+
+My `ready/comments` branch fixes this, by changing the test
+at submission time from (pseudocode)
+
+    !comments_closed_pagespec && check_canedit
+
+to
+
+    comments_pagespec && !comments_closed_pagespec && check_canedit
+
+--[[smcv]]

escape sample directive
diff --git a/doc/bugs/editing_gitbranch_template_is_really_slow.mdwn b/doc/bugs/editing_gitbranch_template_is_really_slow.mdwn
index 57fdbbf..057a50f 100644
--- a/doc/bugs/editing_gitbranch_template_is_really_slow.mdwn
+++ b/doc/bugs/editing_gitbranch_template_is_really_slow.mdwn
@@ -37,7 +37,7 @@ browse=http://git.pseudorandom.co.uk/smcv/ikiwiki.git/shortlog/refs/heads/ready/
 >
 > Previously, if a page like `plugins/trail` contained a conditional like
 >
->     [[!if test="backlink(plugins/goodstuff)" all=no]]
+>     \[[!if test="backlink(plugins/goodstuff)" all=no]]
 >
 > (which it gets via `templates/gitbranch`), then the
 > [[plugins/conditional]] plugin would give `plugins/trail` a dependency on

an order-of-magnitude optimization which also improves correctness
diff --git a/doc/bugs/editing_gitbranch_template_is_really_slow.mdwn b/doc/bugs/editing_gitbranch_template_is_really_slow.mdwn
index d8af150..57fdbbf 100644
--- a/doc/bugs/editing_gitbranch_template_is_really_slow.mdwn
+++ b/doc/bugs/editing_gitbranch_template_is_really_slow.mdwn
@@ -29,3 +29,37 @@ of the problem is that it evaluates the pagespec
 `backlink(plugins/goodstuff)` up to a million times, with various pages and locations.
 
 --[[smcv]]
+
+> [[!template id=gitbranch branch=smcv/ready/perf
+author="[[Simon McVittie|smcv]]"
+browse=http://git.pseudorandom.co.uk/smcv/ikiwiki.git/shortlog/refs/heads/ready/perf]]
+> [[!tag patch]]
+>
+> Previously, if a page like `plugins/trail` contained a conditional like
+>
+>     [[!if test="backlink(plugins/goodstuff)" all=no]]
+>
+> (which it gets via `templates/gitbranch`), then the
+> [[plugins/conditional]] plugin would give `plugins/trail` a dependency on
+> `(backlink(plugins/goodstuff)) and plugins/trail`. This dependency is
+> useless: that pagespec can never match any page other than
+> `plugins/trail`, but if `plugins/trail` has been modified or deleted,
+> then it's going to be rendered or deleted *anyway*, so there's no point
+> in spending time evaluating match_backlink for it.
+>
+> Conversely, the influences from the result were not taken into account,
+> so `plugins/trail` did not have the
+> `{ "plugins/goodstuff" => $DEPEND_LINKS }` dependency that it should.
+>
+> We should invert that, depending on the influences but not on the test.
+>
+> This is at least an order of magnitude faster: when I edit the docwiki
+> as described above, a refresh takes 37s with nytprof overhead, compared
+> with 458s with nytprof overhead before this change. Without nytprof,
+> that refresh takes 14s, which is faster than the 24s rebuild again.
+> I didn't record how long the refresh took without nytprof before this
+> change, but it was something like 200s.
+>
+> `bestlink` is still the single most expensive function in this refresh
+> at ~ 9.5s, with `match_glob` at ~ 5.2s as the runner-up.
+> --[[smcv]]

diff --git a/doc/bugs/redirect.mdwn b/doc/bugs/redirect.mdwn
index 521c29f..6296c3d 100644
--- a/doc/bugs/redirect.mdwn
+++ b/doc/bugs/redirect.mdwn
@@ -10,3 +10,17 @@ if we do this,
 then the following command should print 302
 
     curl -o /dev/null -s -w "%{http_code}" http://baz.thomaslevine.com/bar/
+
+> An interesting idea, but it conflicts somewhat with wanting symlinks to be
+> treated as the referenced file when it's safe to do so, which would be
+> great for [[todo/git-annex support]], and also good to avoid duplication
+> for files in system-wide underlays.
+>
+> Also, I don't think this is possible without help from the web server
+> configuration: for instance, under Apache, I believe the only way to get
+> an HTTP 302 redirect is via Apache-specific `.htaccess` files or
+> system-level Apache configuration.
+>
+> In current ikiwiki, you can get a broadly similar effect by either
+> using \[[!meta redir=foo]] (which does a HTML `<meta>` redirect)
+> or reconfiguring the web server. --[[smcv]]

diff --git a/doc/bugs/redirect.mdwn b/doc/bugs/redirect.mdwn
index 5061a79..521c29f 100644
--- a/doc/bugs/redirect.mdwn
+++ b/doc/bugs/redirect.mdwn
@@ -3,14 +3,10 @@ I suppose this isn't technically a bug, but whetever.
 I want symbolic links to be rendered as HTTP redirects. For example,
 if we do this,
 
-```
-touch foo.mkdwn
-ln -s foo.mkdwn bar.mkdwn
-git push baz.branchable.com
-```
+    touch foo.mkdwn
+    ln -s foo.mkdwn bar.mkdwn
+    git push baz.branchable.com
 
 then the following command should print 302
 
-```
-curl -o /dev/null -s -w "%{http_code}" http://baz.thomaslevine.com/bar/
-```
+    curl -o /dev/null -s -w "%{http_code}" http://baz.thomaslevine.com/bar/

diff --git a/doc/bugs/redirect.mdwn b/doc/bugs/redirect.mdwn
index f7dac60..5061a79 100644
--- a/doc/bugs/redirect.mdwn
+++ b/doc/bugs/redirect.mdwn
@@ -12,5 +12,5 @@ git push baz.branchable.com
 then the following command should print 302
 
 ```
-curl -o /dev/null -s -w "%{http_code}" http://wiki.thomaslevine.com
+curl -o /dev/null -s -w "%{http_code}" http://baz.thomaslevine.com/bar/
 ```

diff --git a/doc/bugs/redirect.mdwn b/doc/bugs/redirect.mdwn
new file mode 100644
index 0000000..f7dac60
--- /dev/null
+++ b/doc/bugs/redirect.mdwn
@@ -0,0 +1,16 @@
+I suppose this isn't technically a bug, but whetever.
+
+I want symbolic links to be rendered as HTTP redirects. For example,
+if we do this,
+
+```
+touch foo.mkdwn
+ln -s foo.mkdwn bar.mkdwn
+git push baz.branchable.com
+```
+
+then the following command should print 302
+
+```
+curl -o /dev/null -s -w "%{http_code}" http://wiki.thomaslevine.com
+```

Answer
diff --git a/doc/bugs/empty_div_element.mdwn b/doc/bugs/empty_div_element.mdwn
index 938db3e..7e28730 100644
--- a/doc/bugs/empty_div_element.mdwn
+++ b/doc/bugs/empty_div_element.mdwn
@@ -29,3 +29,7 @@ This can then be used to move things around. For instance, I have on my website'
 which adds my hackergochi to the bottom left of the webpage, with some margin.
 
 I tried looking for something like this, but I couldn't find it. Perhaps I just didn't look in the right places, though; apologies if that is the case.
+
+> This can easily be achieved by modifying [[templates]]. Simply copy the default page template to the template directory of your wiki, and modify it to add your empty divs.
+>
+> -- [[Louis|spalax]]

unconfuse
diff --git a/doc/bugs/empty_div_element.mdwn b/doc/bugs/empty_div_element.mdwn
index 7a196e4..938db3e 100644
--- a/doc/bugs/empty_div_element.mdwn
+++ b/doc/bugs/empty_div_element.mdwn
@@ -7,7 +7,7 @@ For instance, something like this:
 
 etc. For bonus points, the number could be configurable. To avoid empty content, style.css should have something like this:
 
-    .extra {
+    .aux {
         display: none;
     }
 

add wishlist item
diff --git a/doc/bugs/empty_div_element.mdwn b/doc/bugs/empty_div_element.mdwn
new file mode 100644
index 0000000..7a196e4
--- /dev/null
+++ b/doc/bugs/empty_div_element.mdwn
@@ -0,0 +1,31 @@
+For some more flexibility in creating a stylesheet for ikiwiki, it would be nice if there were a few unused elements on the page that one can move around and assign content to using CSS.
+
+For instance, something like this:
+
+    <div class='aux' id='aux1'></div>
+    <div class='aux' id='aux2'></div>
+
+etc. For bonus points, the number could be configurable. To avoid empty content, style.css should have something like this:
+
+    .extra {
+        display: none;
+    }
+
+This can then be used to move things around. For instance, I have on my website's CSS stylesheet the following:
+
+    #aux1 {
+        position: fixed;
+        width: 150px;
+        height: 150px;
+        bottom: 0px;
+        left: 0px;
+        background-image: url("wouter3.png");
+        background-position: top right;
+        background-repeat: no-repeat;
+        background-origin: content-box;
+        display-block;
+    }
+
+which adds my hackergochi to the bottom left of the webpage, with some margin.
+
+I tried looking for something like this, but I couldn't find it. Perhaps I just didn't look in the right places, though; apologies if that is the case.

no test edits outside /sandbox, please
This reverts commit 77e987059bf303b44f5ab7e95af390cfe0efbdf1
diff --git a/doc/this_page.mdwn b/doc/this_page.mdwn
deleted file mode 100644
index 64accd8..0000000
--- a/doc/this_page.mdwn
+++ /dev/null
@@ -1,2 +0,0 @@
-== This is a page ==
-You should learn your lesson.

diff --git a/doc/this_page.mdwn b/doc/this_page.mdwn
new file mode 100644
index 0000000..64accd8
--- /dev/null
+++ b/doc/this_page.mdwn
@@ -0,0 +1,2 @@
+== This is a page ==
+You should learn your lesson.

diff --git a/doc/sandbox.mdwn b/doc/sandbox.mdwn
index 33c558e..d11211c 100644
--- a/doc/sandbox.mdwn
+++ b/doc/sandbox.mdwn
@@ -1,6 +1,8 @@
 This is the [[SandBox]], a page anyone can edit to try out ikiwiki
 (version [[!version  ]]).
 
+What about [[this page]]?
+
 hello world (right back at ya)
 
 test

+ rescaling distortion
diff --git a/doc/bugs/image_rescaling_distorts_with_small_pictures.mdwn b/doc/bugs/image_rescaling_distorts_with_small_pictures.mdwn
new file mode 100644
index 0000000..c535f88
--- /dev/null
+++ b/doc/bugs/image_rescaling_distorts_with_small_pictures.mdwn
@@ -0,0 +1 @@
+If you use the rescaling feature of the directive [[ikiwiki/directive/img/]] with a smaller image it will distort. E.g. an image with 150x250 rescaled into size=200x200. --bastla

diff --git a/doc/sandbox.mdwn b/doc/sandbox.mdwn
index 06c2d7c..33c558e 100644
--- a/doc/sandbox.mdwn
+++ b/doc/sandbox.mdwn
@@ -2,10 +2,8 @@ This is the [[SandBox]], a page anyone can edit to try out ikiwiki
 (version [[!version  ]]).
 
 hello world (right back at ya)
-asfddsaf sadfkjal;skdfj saldkfjasdf  
-sdafljas;dlfk safdiuhsdf
-
 
+test
 
 > This is a blockquote.
 >

add news item for ikiwiki 3.20140227
diff --git a/doc/news/version_3.20130711.mdwn b/doc/news/version_3.20130711.mdwn
deleted file mode 100644
index 2f4a5ef..0000000
--- a/doc/news/version_3.20130711.mdwn
+++ /dev/null
@@ -1,5 +0,0 @@
-ikiwiki 3.20130711 released with [[!toggle text="these changes"]]
-[[!toggleable text="""
-   * Deal with git behavior change in 1.7.2 and newer that broke support
-     for commits with an empty commit message.
-   * Pass --no-edit when used with git 1.7.8 and newer."""]]
\ No newline at end of file
diff --git a/doc/news/version_3.20140227.mdwn b/doc/news/version_3.20140227.mdwn
new file mode 100644
index 0000000..e5f0154
--- /dev/null
+++ b/doc/news/version_3.20140227.mdwn
@@ -0,0 +1,27 @@
+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

python proxy: Avoid utf-8 related crash. Thanks, Antoine Beaupré
diff --git a/debian/changelog b/debian/changelog
index ff2fe82..1db9864 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -21,6 +21,8 @@ ikiwiki (3.20140126) UNRELEASED; urgency=medium
     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.
 
diff --git a/doc/bugs/crashes_in_the_python_proxy_even_if_disabled.mdwn b/doc/bugs/crashes_in_the_python_proxy_even_if_disabled.mdwn
index 746a56f..3d5b056 100644
--- a/doc/bugs/crashes_in_the_python_proxy_even_if_disabled.mdwn
+++ b/doc/bugs/crashes_in_the_python_proxy_even_if_disabled.mdwn
@@ -70,3 +70,5 @@ error: ikiwiki failed
 > > > > (I'm trying to review some of the pending patches.) --[[smcv]]
 
 >>>>> Ooops.. I forgot to push the branch, it should be good now! --[[anarcat]]
+
+>>>>>> [[merged|done]] --[[Joey]]

pushed the branch, sorry!!
diff --git a/doc/bugs/crashes_in_the_python_proxy_even_if_disabled.mdwn b/doc/bugs/crashes_in_the_python_proxy_even_if_disabled.mdwn
index 4af8c9f..746a56f 100644
--- a/doc/bugs/crashes_in_the_python_proxy_even_if_disabled.mdwn
+++ b/doc/bugs/crashes_in_the_python_proxy_even_if_disabled.mdwn
@@ -68,3 +68,5 @@ error: ikiwiki failed
 
 > > > > I don't see that branch in your git repo, could you repost it please?
 > > > > (I'm trying to review some of the pending patches.) --[[smcv]]
+
+>>>>> Ooops.. I forgot to push the branch, it should be good now! --[[anarcat]]

comments, and thanks!
diff --git a/doc/bugs/do_not_let_big_brother_spy_on_our_users_on_login.mdwn b/doc/bugs/do_not_let_big_brother_spy_on_our_users_on_login.mdwn
index 5c1e7b2..6d259d0 100644
--- a/doc/bugs/do_not_let_big_brother_spy_on_our_users_on_login.mdwn
+++ b/doc/bugs/do_not_let_big_brother_spy_on_our_users_on_login.mdwn
@@ -45,7 +45,11 @@ A simple fix would be to ship those icons with ikiwiki and serve them locally, b
 >> by technologists, the OpenID selector is a bit of a waste of time.
 >>
 >>> Not done yet. -s
->>
+>>>
+>>>> FWIW, I don't think we should implement this. The current selector is 
+>>>> fine: if elite technologists don't want the selector, they can just 
+>>>> turn off javascript. :) -- [[anarcat]]
+>> 
 >> One way to have recognisable icons would be to ship DFSG imitations of
 >> the "real" logos in the underlay. Between gnome-online-accounts and
 >> Empathy, we can probably find most of them (mostly or perhaps all done by
@@ -60,6 +64,8 @@ A simple fix would be to ship those icons with ikiwiki and serve them locally, b
 >>> -s
 >>>>
 >>>> Awesome work Simon! I owe you a beer. [[merged|done]] --[[Joey]] 
+>>>>
+>>>> Same here, thanks for this!!! -- [[anarcat]]
 >>
 >> If people want the "real" logos, we could have some code to make IkiWiki
 >> download the favicons into transient underlay (which I think is
@@ -69,4 +75,5 @@ A simple fix would be to ship those icons with ikiwiki and serve them locally, b
 >>> Not done yet. I'm not sure whether I'm going to bother, but I'd review
 >>> someone else's implementation. -s
 >>
+>>>> Doesn't seem to be a priority to me either. --[[anarcat]]
 >> --[[smcv]]

mention fdo
diff --git a/doc/tips/convert_moinmoin_to_ikiwiki/discussion.mdwn b/doc/tips/convert_moinmoin_to_ikiwiki/discussion.mdwn
index 2fe55d9..ad35a30 100644
--- a/doc/tips/convert_moinmoin_to_ikiwiki/discussion.mdwn
+++ b/doc/tips/convert_moinmoin_to_ikiwiki/discussion.mdwn
@@ -3,3 +3,5 @@ I look forward to trying this.  I have a large (~10 year old) MoinMoin installat
 > I'll make that clearer in the docs, but we do not deal with ACL (yet?), as ikiwiki doesn't support Moinmoin's level of ACL flexibility. See [[todo/per_page_ACLs]] for more information. --[[anarcat]]
 
 >> I was actually thinking the ACLs would cause a problem just for the crawler, I hadn't considered their re-implementation (but yes, that would be good!) — [[Jon]]
+
+Note that freedesktop.org are doing a moinmoin to ikiwiki conversion, see [this page](http://www.freedesktop.org/wiki/conversion/) for some documentation. It's unclear which software they are using for that purpose. — [[anarcat]]

diff --git a/doc/bugs/Spurious___60__p__62___elements_added_to_tags_in_inliine_pages.mdwn b/doc/bugs/Spurious___60__p__62___elements_added_to_tags_in_inliine_pages.mdwn
index 08b3a6c..15f74c4 100644
--- a/doc/bugs/Spurious___60__p__62___elements_added_to_tags_in_inliine_pages.mdwn
+++ b/doc/bugs/Spurious___60__p__62___elements_added_to_tags_in_inliine_pages.mdwn
@@ -45,8 +45,15 @@ A fix is to change inlinepage.tmpl to remove new lines around tag links, as foll
 > I don't think that this is specific to the [[syntax_(3rd_party)_plugin|plugins/contrib/syntax]].
 > It's happening on my pages that just use ordinary templates.
 > I've documented my versions below. --[[daveloyall]]
-
-    ikiwiki: 3.20140125
-    libtext-markdown-discount-perl: 0.11-1
-    libtext-multimarkdown-perl: 1.000034-1
-    libhtml-template-perl: 2.95-1
+>
+>     ikiwiki: 3.20140125
+>     libtext-markdown-discount-perl: 0.11-1
+>     libtext-multimarkdown-perl: 1.000034-1
+>     libhtml-template-perl: 2.95-1
+
+>> Can you show us the source code and output for a page that has this
+>> bug?
+>>
+>> If you enable [[plugins/htmlbalance]], does the problem go away?
+>> (If it does, then I think I might know what the bug is.)
+>> --[[smcv]]

diff --git a/doc/bugs/Spurious___60__p__62___elements_added_to_tags_in_inliine_pages.mdwn b/doc/bugs/Spurious___60__p__62___elements_added_to_tags_in_inliine_pages.mdwn
index e3b1d85..08b3a6c 100644
--- a/doc/bugs/Spurious___60__p__62___elements_added_to_tags_in_inliine_pages.mdwn
+++ b/doc/bugs/Spurious___60__p__62___elements_added_to_tags_in_inliine_pages.mdwn
@@ -41,3 +41,12 @@ A fix is to change inlinepage.tmpl to remove new lines around tag links, as foll
 > 
 > I don't have the prerequisites for the syntax plugin installed here
 > to debug it myself. --[[Joey]]
+
+> I don't think that this is specific to the [[syntax_(3rd_party)_plugin|plugins/contrib/syntax]].
+> It's happening on my pages that just use ordinary templates.
+> I've documented my versions below. --[[daveloyall]]
+
+    ikiwiki: 3.20140125
+    libtext-markdown-discount-perl: 0.11-1
+    libtext-multimarkdown-perl: 1.000034-1
+    libhtml-template-perl: 2.95-1

diff --git a/doc/bugs/editing_gitbranch_template_is_really_slow.mdwn b/doc/bugs/editing_gitbranch_template_is_really_slow.mdwn
index 713dcfa..d8af150 100644
--- a/doc/bugs/editing_gitbranch_template_is_really_slow.mdwn
+++ b/doc/bugs/editing_gitbranch_template_is_really_slow.mdwn
@@ -25,7 +25,7 @@ NYTProf says:
 which is about half the execution time (458s on my laptop).
 
 Adding code to log each call to match_backlink indicates that a large part
-of the problem is that there are about a million calls to
-`bestlink(plugins/goodstuff)` with various pages and locations.
+of the problem is that it evaluates the pagespec
+`backlink(plugins/goodstuff)` up to a million times, with various pages and locations.
 
 --[[smcv]]

diff --git a/doc/bugs/editing_gitbranch_template_is_really_slow.mdwn b/doc/bugs/editing_gitbranch_template_is_really_slow.mdwn
index 33b8f25..713dcfa 100644
--- a/doc/bugs/editing_gitbranch_template_is_really_slow.mdwn
+++ b/doc/bugs/editing_gitbranch_template_is_really_slow.mdwn
@@ -24,4 +24,8 @@ NYTProf says:
 
 which is about half the execution time (458s on my laptop).
 
+Adding code to log each call to match_backlink indicates that a large part
+of the problem is that there are about a million calls to
+`bestlink(plugins/goodstuff)` with various pages and locations.
+
 --[[smcv]]

diff --git a/doc/bugs/template_creation_error.mdwn b/doc/bugs/template_creation_error.mdwn
index 22d112c..f14652e 100644
--- a/doc/bugs/template_creation_error.mdwn
+++ b/doc/bugs/template_creation_error.mdwn
@@ -210,3 +210,11 @@ Please, let me know what to do to avoid this kind of error.
 >>>>>>> rebuild of a site with many pages. Ikiwiki already keeps a lot
 >>>>>>> of info in memory, and this adds to it, for what is a fairly
 >>>>>>> minor reason. It seems to me there should be a way to avoid this. --[[Joey]] 
+
+>>>>>>>> Maybe. Are plugins expected to cope with scanning the same
+>>>>>>>> page more than once? If so, it's just a tradeoff between
+>>>>>>>> "spend more time scanning the template repeatedly" and
+>>>>>>>> "spend more memory on avoiding it", and it would be OK to
+>>>>>>>> omit that, or reduce it to a set of scanned *templates*
+>>>>>>>> (in practice that would mean scanning each template twice
+>>>>>>>> in a rebuild). --s

profiling
diff --git a/doc/bugs/editing_gitbranch_template_is_really_slow.mdwn b/doc/bugs/editing_gitbranch_template_is_really_slow.mdwn
index 028a5b2..33b8f25 100644
--- a/doc/bugs/editing_gitbranch_template_is_really_slow.mdwn
+++ b/doc/bugs/editing_gitbranch_template_is_really_slow.mdwn
@@ -14,4 +14,14 @@ Easy to reproduce offline:
 * `touch templates/gitbranch.mdwn`
 * `/usr/bin/perl -Iblib/lib ikiwiki.in -setup docwiki.setup -refresh`
 
+NYTProf says:
+
+    # spent 279s (237+41.8) within IkiWiki::bestlink which was called 13988949 times, avg 20µs/call:
+    # 13150827 times (222s+37.2s) by IkiWiki::PageSpec::match_link at line 2692, avg 20µs/call
+    # 829606 times (14.9s+4.51s) by IkiWiki::PageSpec::match_link at line 2687, avg 23µs/call
+    ...
+    sub bestlink ($$) {
+
+which is about half the execution time (458s on my laptop).
+
 --[[smcv]]

reviewed, not merged
diff --git a/doc/bugs/template_creation_error.mdwn b/doc/bugs/template_creation_error.mdwn
index 2468e3c..22d112c 100644
--- a/doc/bugs/template_creation_error.mdwn
+++ b/doc/bugs/template_creation_error.mdwn
@@ -204,3 +204,9 @@ Please, let me know what to do to avoid this kind of error.
 >>>>>> There is one known buglet: `template_syntax.t` asserts that the entire
 >>>>>> file is a valid HTML::Template, whereas it would ideally be doing the
 >>>>>> same logic as IkiWiki itself. I don't think that's serious. --[[smcv]]
+
+>>>>>>> Looking over this, I notice it adds a hash containing all scanned
+>>>>>>> files. This seems to me to be potentially a scalability problem on
+>>>>>>> rebuild of a site with many pages. Ikiwiki already keeps a lot
+>>>>>>> of info in memory, and this adds to it, for what is a fairly
+>>>>>>> minor reason. It seems to me there should be a way to avoid this. --[[Joey]] 

Improve templates testing. Thanks, smcv
diff --git a/debian/changelog b/debian/changelog
index 7fa1cbd..ff2fe82 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -19,6 +19,8 @@ ikiwiki (3.20140126) UNRELEASED; urgency=medium
   * 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
   * Special thanks to Simon McVittie for being the patchmeister for this
     release.
 
diff --git a/doc/bugs/template__95__syntax_test_is_incomplete.mdwn b/doc/bugs/template__95__syntax_test_is_incomplete.mdwn
index f9e3bf3..d50b727 100644
--- a/doc/bugs/template__95__syntax_test_is_incomplete.mdwn
+++ b/doc/bugs/template__95__syntax_test_is_incomplete.mdwn
@@ -6,3 +6,5 @@
 `t/template_syntax.t` looks as though it's meant to check the syntax of
 `doc/templates/*.mdwn` as well as `templates/*.tmpl`, but it doesn't.
 Patch in my git repository. --[[smcv]]
+
+> [[merged|done]] --[[Joey]]

forgot to close this one when merging
diff --git a/doc/bugs/assumes___34__git_push_origin__34___is_sufficient.mdwn b/doc/bugs/assumes___34__git_push_origin__34___is_sufficient.mdwn
index 20d1dd4..369be82 100644
--- a/doc/bugs/assumes___34__git_push_origin__34___is_sufficient.mdwn
+++ b/doc/bugs/assumes___34__git_push_origin__34___is_sufficient.mdwn
@@ -14,3 +14,5 @@ the regression test will warn:
 
 The solution is to do "git push origin master" instead (but with the
 configured remote and branch names). --[[smcv]]
+
+> [[fixed|done]] --[[Joey]]

Cleanup of the openid login widget, including replacing of hotlinked images from openid providers with embedded, freely licensed artwork. Thanks, smcv
diff --git a/debian/changelog b/debian/changelog
index f1e5ae9..7723f36 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -16,6 +16,9 @@ ikiwiki (3.20140126) UNRELEASED; urgency=medium
   * 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
 
  -- Joey Hess <joeyh@debian.org>  Sat, 01 Feb 2014 16:53:35 -0400
 
diff --git a/doc/bugs/do_not_let_big_brother_spy_on_our_users_on_login.mdwn b/doc/bugs/do_not_let_big_brother_spy_on_our_users_on_login.mdwn
index 6fc1bf5..5c1e7b2 100644
--- a/doc/bugs/do_not_let_big_brother_spy_on_our_users_on_login.mdwn
+++ b/doc/bugs/do_not_let_big_brother_spy_on_our_users_on_login.mdwn
@@ -58,6 +58,8 @@ A simple fix would be to ship those icons with ikiwiki and serve them locally, b
 >>> drew my own for the rest.
 >>> [See it in use here](http://blueview.hosted.pseudorandom.co.uk/ikiwiki.cgi?do=prefs)
 >>> -s
+>>>>
+>>>> Awesome work Simon! I owe you a beer. [[merged|done]] --[[Joey]] 
 >>
 >> If people want the "real" logos, we could have some code to make IkiWiki
 >> download the favicons into transient underlay (which I think is

git diffurl: Do not escape / in paths to changed files, in order to interoperate with cgit (gitweb works either way) Thanks, intrigeri.
diff --git a/debian/changelog b/debian/changelog
index 7617867..145ac67 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -7,6 +7,9 @@ ikiwiki (3.20140126) UNRELEASED; urgency=medium
     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.
 
  -- Joey Hess <joeyh@debian.org>  Sat, 01 Feb 2014 16:53:35 -0400
 
diff --git a/doc/todo/support_linking_to_cgit.mdwn b/doc/todo/support_linking_to_cgit.mdwn
index c48edbd..ab6172a 100644
--- a/doc/todo/support_linking_to_cgit.mdwn
+++ b/doc/todo/support_linking_to_cgit.mdwn
@@ -38,6 +38,8 @@ the substitution of `\[[file]]` in `diffurl` and `historyurl`?
 >>>> I don't have commit access to ikiwiki.info, but if I did,
 >>>> [[I'd merge this|/users/smcv/yesplease]]. --[[smcv]]
 
+>>>>> [[merged|done]] --[[Joey]]
+
 [[wishlist]]
 
 [[!tag patch]]

Allow up to 8 levels of nested directives, rather than previous 3 in directive infinite loop guard.
diff --git a/IkiWiki.pm b/IkiWiki.pm
index a254177..e5da04a 100644
--- a/IkiWiki.pm
+++ b/IkiWiki.pm
@@ -1508,7 +1508,7 @@ sub preprocess ($$$;$$) {
 					push @params, $val, '';
 				}
 			}
-			if ($preprocessing{$page}++ > 3) {
+			if ($preprocessing{$page}++ > 8) {
 				# Avoid loops of preprocessed pages preprocessing
 				# other pages that preprocess them, etc.
 				return "[[!$command <span class=\"error\">".
diff --git a/debian/changelog b/debian/changelog
index a6ef93e..7617867 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -5,6 +5,8 @@ ikiwiki (3.20140126) UNRELEASED; urgency=medium
   * 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.
 
  -- Joey Hess <joeyh@debian.org>  Sat, 01 Feb 2014 16:53:35 -0400
 
diff --git a/doc/bugs/preprocessing_loop_control_too_tight.mdwn b/doc/bugs/preprocessing_loop_control_too_tight.mdwn
index ba8534b..807d6b7 100644
--- a/doc/bugs/preprocessing_loop_control_too_tight.mdwn
+++ b/doc/bugs/preprocessing_loop_control_too_tight.mdwn
@@ -19,3 +19,5 @@ index 75c9579..ad0f8b0 100644
 [[!tag patch]]
 
 > [[Seems reasonable|users/smcv/yesplease]] --smcv
+
+>> [[done]] --[[Joey]]

merged patch; bug left open
diff --git a/doc/bugs/syslog_fails_with_non-ASCII_wikinames.mdwn b/doc/bugs/syslog_fails_with_non-ASCII_wikinames.mdwn
index 8ee7db0..b641f2d 100644
--- a/doc/bugs/syslog_fails_with_non-ASCII_wikinames.mdwn
+++ b/doc/bugs/syslog_fails_with_non-ASCII_wikinames.mdwn
@@ -23,3 +23,5 @@ Yet I am not sure how to fix that kind of problem in Perl... --[[anarcat]]
 > > One last note: I noticed that this problem also happens elsewhere in ikiwiki. For example, the [[plugins/notifyemail]] plugin will silently fail to send notifications if the pages contain unicode. The [[plugins/notifychanges]] plugin I am working on (in [[todo/option to send only the diff in notifyemail]]) seems to be working around the issue so far, but there's no telling which similar problem are out there.
 
 >> [[I'd merge it|/users/smcv/yesplease]]. --[[smcv]]
+
+>>> I've merged it, but I don't feel it fixes this bug. --[[Joey]]

po: Add html_lang_code and html_lang_dir template variables for the language code and direction of text. Thanks, Mesar Hameed
diff --git a/debian/changelog b/debian/changelog
index 208da2a..a6ef93e 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -2,6 +2,9 @@ ikiwiki (3.20140126) UNRELEASED; urgency=medium
 
   * Added useragent config setting. Closes: #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
 
  -- Joey Hess <joeyh@debian.org>  Sat, 01 Feb 2014 16:53:35 -0400
 
diff --git a/doc/todo/expose_html_language_and_direction.mdwn b/doc/todo/expose_html_language_and_direction.mdwn
index 6eed967..f321e4f 100644
--- a/doc/todo/expose_html_language_and_direction.mdwn
+++ b/doc/todo/expose_html_language_and_direction.mdwn
@@ -11,3 +11,5 @@ The [[patch]] is currently being used on http://addons.nvda-project.org and seem
 
 > I don't have commit access, but it [[seems reasonable|/users/smcv/yesplease]].
 > --[[smcv]]
+
+>> [[done]]] --[[Joey]]

performance problem
diff --git a/doc/bugs/editing_gitbranch_template_is_really_slow.mdwn b/doc/bugs/editing_gitbranch_template_is_really_slow.mdwn
new file mode 100644
index 0000000..028a5b2
--- /dev/null
+++ b/doc/bugs/editing_gitbranch_template_is_really_slow.mdwn
@@ -0,0 +1,17 @@
+On this wiki, editing `templates/gitbranch.mdwn` causes a really slow
+refresh, orders of magnitude slower than a full rebuild: a large number of
+pages depend on that template, or link to a page that embeds that template,
+and so on.
+
+I suspect that, as with my optimization pass for `album`'s benefit, the
+costly thing is evaluating lots of pagespecs. I'm profiling it to see
+whether the problem is there are any low-hanging fruit.
+
+Easy to reproduce offline:
+
+* comment out the `exclude` option in `docwiki.setup`
+* `/usr/bin/perl -Iblib/lib ikiwiki.in -setup docwiki.setup -rebuild`
+* `touch templates/gitbranch.mdwn`
+* `/usr/bin/perl -Iblib/lib ikiwiki.in -setup docwiki.setup -refresh`
+
+--[[smcv]]

new version of the branch; thanks to chrysn for early feedback
diff --git a/doc/bugs/template_creation_error.mdwn b/doc/bugs/template_creation_error.mdwn
index 5d27c34..2468e3c 100644
--- a/doc/bugs/template_creation_error.mdwn
+++ b/doc/bugs/template_creation_error.mdwn
@@ -110,8 +110,6 @@ Please, let me know what to do to avoid this kind of error.
 >
 > --[[smcv]]
 
->> [[!template id=gitbranch author="[[smcv]]" branch=smcv/definetemplate]]
->> [[!tag patch]]
 >> OK, here is a branch implementing what I said. It adds the `definetemplate`
 >> directive to [[plugins/goodstuff]] as its last commit.
 >>
@@ -195,3 +193,14 @@ Please, let me know what to do to avoid this kind of error.
 >>>>> the right thing to do in this situation.
 >>>>>
 >>>>> --[[chrysn]]
+
+>>>>>> [[!template id=gitbranch author="[[smcv]]" branch=smcv/ready/templatebody
+         browse=http://git.pseudorandom.co.uk/smcv/ikiwiki.git/shortlog/refs/heads/ready/templatebody]]
+>>>>>> [[!tag patch]]
+>>>>>> Branch and directive renamed to `ready/templatebody` as chrysn suggested.
+>>>>>> It's on-by-default now (or will be if that branch is merged).
+>>>>>> Joey, any chance you could review this?
+>>>>>>
+>>>>>> There is one known buglet: `template_syntax.t` asserts that the entire
+>>>>>> file is a valid HTML::Template, whereas it would ideally be doing the
+>>>>>> same logic as IkiWiki itself. I don't think that's serious. --[[smcv]]

duplicate
diff --git a/doc/bugs/pages_under_templates_are_invalid.mdwn b/doc/bugs/pages_under_templates_are_invalid.mdwn
index f7e115d..c031543 100644
--- a/doc/bugs/pages_under_templates_are_invalid.mdwn
+++ b/doc/bugs/pages_under_templates_are_invalid.mdwn
@@ -14,3 +14,6 @@ Maybe just encode all &lt; and &gt; when compling pages within the templates fol
 
 > I never noticed this bug, since it only happens if the htmlscrubber is
 > disabled. --[[Joey]]
+
+>> My `templatebody` branch on [[template creation error]] fixes this.
+>> --[[smcv]]

review
diff --git a/doc/todo/missingparents.pm.mdwn b/doc/todo/missingparents.pm.mdwn
index cecac7a..b257760 100644
--- a/doc/todo/missingparents.pm.mdwn
+++ b/doc/todo/missingparents.pm.mdwn
@@ -30,6 +30,12 @@ This patch, or one like it, would enable better blogging support, by adding
 the ability to hierarchically organize blog posts and automatically generate
 structural pages for year, month, or day. Please apply. --Ethan
 
+> This looks a lot like [[plugins/autoindex]], except limited to a subset
+> of pages, and with different templates according to the page it's used
+> on. Perhaps it could become several enhancements for autoindex? --[[smcv]]
+
+----
+
 <pre>
 Index: IkiWiki/Render.pm
 ===================================================================

add an inline
diff --git a/doc/users/smcv/yesplease.mdwn b/doc/users/smcv/yesplease.mdwn
index f908f4f..b100b37 100644
--- a/doc/users/smcv/yesplease.mdwn
+++ b/doc/users/smcv/yesplease.mdwn
@@ -1,3 +1,7 @@
 A tag for patches that I would merge if I had commit access to ikiwiki,
 in the hope that it's a useful shortlist for committers to look at.
 They're mirrored in my git repository under the `ready/*` namespace.
+
+[[!inline pages="(todo/* or bugs/*) and link(patch) and !link(bugs/done) and
+   !link(todo/done) and link(users/smcv/yesplease) and !*/Discussion"
+   archive="yes"]]

diff --git a/doc/users/smcv.mdwn b/doc/users/smcv.mdwn
index 59d1aff..a4eb564 100644
--- a/doc/users/smcv.mdwn
+++ b/doc/users/smcv.mdwn
@@ -7,4 +7,4 @@ My repository containing ikiwiki branches:
 * gitweb: http://git.pseudorandom.co.uk/smcv/ikiwiki.git
 * anongit: git://git.pseudorandom.co.uk/git/smcv/ikiwiki.git
 
-Currently thinking about a [[users/smcv/gallery]] plugin.
+Recently tried to [[help with the review backlog|yesplease]].

update for rename of users/smcv/approved.mdwn to users/smcv/yesplease.mdwn
diff --git a/doc/todo/expose_html_language_and_direction.mdwn b/doc/todo/expose_html_language_and_direction.mdwn
index f9d419d..6eed967 100644
--- a/doc/todo/expose_html_language_and_direction.mdwn
+++ b/doc/todo/expose_html_language_and_direction.mdwn
@@ -9,5 +9,5 @@ This means:
 
 The [[patch]] is currently being used on http://addons.nvda-project.org and seems to work well. --[[mhameed]]
 
-> I don't have commit access, but it [[seems reasonable|/users/smcv/approved]].
+> I don't have commit access, but it [[seems reasonable|/users/smcv/yesplease]].
 > --[[smcv]]

update for rename of users/smcv/approved.mdwn to users/smcv/yesplease.mdwn
diff --git a/doc/bugs/syslog_fails_with_non-ASCII_wikinames.mdwn b/doc/bugs/syslog_fails_with_non-ASCII_wikinames.mdwn
index f48d852..8ee7db0 100644
--- a/doc/bugs/syslog_fails_with_non-ASCII_wikinames.mdwn
+++ b/doc/bugs/syslog_fails_with_non-ASCII_wikinames.mdwn
@@ -22,4 +22,4 @@ Yet I am not sure how to fix that kind of problem in Perl... --[[anarcat]]
 > 
 > > One last note: I noticed that this problem also happens elsewhere in ikiwiki. For example, the [[plugins/notifyemail]] plugin will silently fail to send notifications if the pages contain unicode. The [[plugins/notifychanges]] plugin I am working on (in [[todo/option to send only the diff in notifyemail]]) seems to be working around the issue so far, but there's no telling which similar problem are out there.
 
->> [[I'd merge it|/users/smcv/approved]]. --[[smcv]]
+>> [[I'd merge it|/users/smcv/yesplease]]. --[[smcv]]

update for rename of users/smcv/approved.mdwn to users/smcv/yesplease.mdwn
diff --git a/doc/todo/support_linking_to_cgit.mdwn b/doc/todo/support_linking_to_cgit.mdwn
index 4710495..c48edbd 100644
--- a/doc/todo/support_linking_to_cgit.mdwn
+++ b/doc/todo/support_linking_to_cgit.mdwn
@@ -36,7 +36,7 @@ the substitution of `\[[file]]` in `diffurl` and `historyurl`?
 >>>> \[[file_less_escaped]], and I can't think of one.
 >>>>
 >>>> I don't have commit access to ikiwiki.info, but if I did,
->>>> [[I'd merge this|/users/smcv/approved]]. --[[smcv]]
+>>>> [[I'd merge this|/users/smcv/yesplease]]. --[[smcv]]
 
 [[wishlist]]
 

update for rename of users/smcv/approved.mdwn to users/smcv/yesplease.mdwn
diff --git a/doc/bugs/preprocessing_loop_control_too_tight.mdwn b/doc/bugs/preprocessing_loop_control_too_tight.mdwn
index 109a692..ba8534b 100644
--- a/doc/bugs/preprocessing_loop_control_too_tight.mdwn
+++ b/doc/bugs/preprocessing_loop_control_too_tight.mdwn
@@ -18,4 +18,4 @@ index 75c9579..ad0f8b0 100644
 
 [[!tag patch]]
 
-> [[Seems reasonable|users/smcv/approved]] --smcv
+> [[Seems reasonable|users/smcv/yesplease]] --smcv

rename users/smcv/approved.mdwn to users/smcv/yesplease.mdwn
diff --git a/doc/users/smcv/approved.mdwn b/doc/users/smcv/approved.mdwn
deleted file mode 100644
index f908f4f..0000000
--- a/doc/users/smcv/approved.mdwn
+++ /dev/null
@@ -1,3 +0,0 @@
-A tag for patches that I would merge if I had commit access to ikiwiki,
-in the hope that it's a useful shortlist for committers to look at.
-They're mirrored in my git repository under the `ready/*` namespace.
diff --git a/doc/users/smcv/yesplease.mdwn b/doc/users/smcv/yesplease.mdwn
new file mode 100644
index 0000000..f908f4f
--- /dev/null
+++ b/doc/users/smcv/yesplease.mdwn
@@ -0,0 +1,3 @@
+A tag for patches that I would merge if I had commit access to ikiwiki,
+in the hope that it's a useful shortlist for committers to look at.
+They're mirrored in my git repository under the `ready/*` namespace.

review: I would suggest cherry-picking part of the branch
diff --git a/doc/todo/edittemplate_should_support_uuid__44___date_variables.mdwn b/doc/todo/edittemplate_should_support_uuid__44___date_variables.mdwn
index 7ec95b5..4f83c8b 100644
--- a/doc/todo/edittemplate_should_support_uuid__44___date_variables.mdwn
+++ b/doc/todo/edittemplate_should_support_uuid__44___date_variables.mdwn
@@ -1,3 +1,4 @@
+[[!template id=gitbranch branch=anderbubble/edittemplate author="Jonathon Anderson"]]
 [[!tag wishlist patch]]
 
 I use a default template for all new pages:
@@ -17,3 +18,31 @@ I've already made these changes in my installation, and have made my patches ava
 Changes to the structure of `$pagestate{$registering_page}{edittemplate}{$pagespec}` mean that a `cgi` rebuild is necessary (for reasons I don't entirely understand); but I think that's preferable to creating an entirely separate `$pagestate` namespace for storing parameters.  That said, I'm not really a perl programmer, so corrections are welcome.
 
 > I like this patch. I hate seeing things I've already read get marked as unread in my rss feed. -- [[JoshBBall]]
+
+>> (I don't have commit access so take this with a pinch of salt -
+>> I'm just trying to help deal with the code-review backlog.)
+>>
+>> I mostly like the first and third patches in the branch (adding v4
+>> (random) UUIDs, and adding the timestamps). I'd be tempted to rename
+>> `time` and `formatted_time` to `iso_time` and `time`, but that's
+>> a matter of taste, and perhaps people with commit access have
+>> stronger opinions one way or another. I haven't researched
+>> whether there's precendent for any particular naming style
+>> elsewhere in ikiwiki.
+>>
+>> The UUID bit would require adding some reference to libuuid-tiny-perl
+>> to the Debian packaging - I think a `Recommends` is too strong
+>> but a `Suggests` seems OK.
+>>
+>> I don't like the second patch (adding URL-namespaced UUID support).
+>> I'm having a hard time thinking of any situation in which a v4 UUID
+>> would be unsuitable, which means it's unnecessary complexity.
+>> FYI, the reason that it makes a rebuild is necessary is that
+>> you've restructured `$pagestate`, which is carried over from one
+>> refresh to the next (that's its purpose), and you haven't
+>> built in any migration or backwards-compatibility code that will
+>> cope with it being in the old format. My inclination would be to
+>> drop that patch. If there's a really good reason to prefer
+>> v3/v5 UUIDs, please describe it and I'll try to suggest some
+>> better way based on that, maybe global configuration in `$config`.
+>> --[[smcv]]

looks good to me
diff --git a/doc/bugs/preprocessing_loop_control_too_tight.mdwn b/doc/bugs/preprocessing_loop_control_too_tight.mdwn
index f1a9bc9..109a692 100644
--- a/doc/bugs/preprocessing_loop_control_too_tight.mdwn
+++ b/doc/bugs/preprocessing_loop_control_too_tight.mdwn
@@ -17,3 +17,5 @@ index 75c9579..ad0f8b0 100644
 </pre></code>
 
 [[!tag patch]]
+
+> [[Seems reasonable|users/smcv/approved]] --smcv