Recent changes to this wiki:

single-indent (not sure why I doubled it)
diff --git a/doc/todo/merge_tina-osm_branch.mdwn b/doc/todo/merge_tina-osm_branch.mdwn
index 325139407..3cdbca662 100644
--- a/doc/todo/merge_tina-osm_branch.mdwn
+++ b/doc/todo/merge_tina-osm_branch.mdwn
@@ -16,23 +16,23 @@ Any chances of it being merged into master? At this point I am considering if it
 
 --[[Tina]]
 
->> Hi, I can understand your frustration with having outstanding patches for
->> review/merge. You aren't alone. It's clear that the IkiWiki maintainers are
->> overloaded at the moment. IkiWiki maintainers, is there anything that we can
->> do to help?
->> 
->> In my case I started [collecting together stuff that I was requesting be merged](https://github.com/jmtd/ikiwiki/compare/3.20200202.3...jmtd:opinionated?expand=1)
->> into IkiWiki, by myself and others, in a branch that I use for the *Opinionated
->> Ikiwiki* [[container|containers]].
->> 
->> The *Opinionated IkiWiki* container was not intended to be a "clearing house"
->> for patches, as such, but it could potentially be a way for pending stuff to
->> get some exposure, which might increase the overburdened maintainers confidence
->> in the patches. (Would it)? Supposing that anyone is using the container of
->> course.
->> 
->> I've personally not used the OSM plugin at all, but I took a quick look after
->> you posted the above message. It looks cool! I would probably accept a PR
->> against the "opinionated" branch in my fork, above, if that was of any interest.
->> 
->> -- *[[Jon]], 2021-08-18*
+> Hi, I can understand your frustration with having outstanding patches for
+> review/merge. You aren't alone. It's clear that the IkiWiki maintainers are
+> overloaded at the moment. IkiWiki maintainers, is there anything that we can
+> do to help?
+> 
+> In my case I started [collecting together stuff that I was requesting be merged](https://github.com/jmtd/ikiwiki/compare/3.20200202.3...jmtd:opinionated?expand=1)
+> into IkiWiki, by myself and others, in a branch that I use for the *Opinionated
+> Ikiwiki* [[container|containers]].
+> 
+> The *Opinionated IkiWiki* container was not intended to be a "clearing house"
+> for patches, as such, but it could potentially be a way for pending stuff to
+> get some exposure, which might increase the overburdened maintainers confidence
+> in the patches. (Would it)? Supposing that anyone is using the container of
+> course.
+> 
+> I've personally not used the OSM plugin at all, but I took a quick look after
+> you posted the above message. It looks cool! I would probably accept a PR
+> against the "opinionated" branch in my fork, above, if that was of any interest.
+> 
+> -- *[[Jon]], 2021-08-18*

Reply to Tina and busy maintainers: is there anything we can do?
diff --git a/doc/todo/merge_tina-osm_branch.mdwn b/doc/todo/merge_tina-osm_branch.mdwn
index c20fd18ec..325139407 100644
--- a/doc/todo/merge_tina-osm_branch.mdwn
+++ b/doc/todo/merge_tina-osm_branch.mdwn
@@ -15,3 +15,24 @@ It has been over 2 years since I created this patch... I have even changed my na
 Any chances of it being merged into master? At this point I am considering if it makes sense to keep using ikiwiki if I have to keep maintaining local patches for years.
 
 --[[Tina]]
+
+>> Hi, I can understand your frustration with having outstanding patches for
+>> review/merge. You aren't alone. It's clear that the IkiWiki maintainers are
+>> overloaded at the moment. IkiWiki maintainers, is there anything that we can
+>> do to help?
+>> 
+>> In my case I started [collecting together stuff that I was requesting be merged](https://github.com/jmtd/ikiwiki/compare/3.20200202.3...jmtd:opinionated?expand=1)
+>> into IkiWiki, by myself and others, in a branch that I use for the *Opinionated
+>> Ikiwiki* [[container|containers]].
+>> 
+>> The *Opinionated IkiWiki* container was not intended to be a "clearing house"
+>> for patches, as such, but it could potentially be a way for pending stuff to
+>> get some exposure, which might increase the overburdened maintainers confidence
+>> in the patches. (Would it)? Supposing that anyone is using the container of
+>> course.
+>> 
+>> I've personally not used the OSM plugin at all, but I took a quick look after
+>> you posted the above message. It looks cool! I would probably accept a PR
+>> against the "opinionated" branch in my fork, above, if that was of any interest.
+>> 
+>> -- *[[Jon]], 2021-08-18*

diff --git a/doc/users/Tina.mdwn b/doc/users/Tina.mdwn
index c3c7ad4c3..910b6711c 100644
--- a/doc/users/Tina.mdwn
+++ b/doc/users/Tina.mdwn
@@ -1,3 +1,5 @@
 [Martina Ferrari](https://tina.pm/blog/)
 
+Also Tina @debian, and OFTC and Libera IRC networks. NightTsarina in Github, Twitter, and other places.
+
 Long time user of ikiwiki. Made a [rewrite](https://tina.pm/blog/posts/OSM_in_IkiWiki/) of the OSM plugin, still pending merge.

diff --git a/doc/todo/merge_tina-osm_branch.mdwn b/doc/todo/merge_tina-osm_branch.mdwn
index a0e4878af..c20fd18ec 100644
--- a/doc/todo/merge_tina-osm_branch.mdwn
+++ b/doc/todo/merge_tina-osm_branch.mdwn
@@ -10,3 +10,8 @@ I'd appreciate additional careful review from another maintainer,
 including about the points raised at [[plugins/osm/discussion]].
 
 --[[schmonz]]
+
+It has been over 2 years since I created this patch... I have even changed my name and gender in the meantime :)
+Any chances of it being merged into master? At this point I am considering if it makes sense to keep using ikiwiki if I have to keep maintaining local patches for years.
+
+--[[Tina]]

Update user name
diff --git a/doc/git.mdwn b/doc/git.mdwn
index df26b2ad3..17a44d2c8 100644
--- a/doc/git.mdwn
+++ b/doc/git.mdwn
@@ -61,7 +61,7 @@ think about merging them. This is recommended. :-)
 * bfree `git://github.com/bfree/ikiwiki.git`
 * [[users/leg]] `git://at.magma-soft.at/ikiwiki.info`
 * [[thcipriani]] `https://github.com/thcipriani/ikiwiki.git` ([[browse|https://github.com/thcipriani/ikiwiki]])
-* [[tincho]] `git@github.com:TheTincho/ikiwiki.git` ([[browse|https://github.com/TheTincho/ikiwiki]])
+* [[Tina]] `git@github.com:NightTsarina/ikiwiki.git` ([[browse|https://github.com/NightTsarina/ikiwiki]])
 * [[hefee]] `https://salsa.debian.org/hefee/ikiwiki.git/` ([[browse|https://salsa.debian.org/hefee/ikiwiki]])
 * bsv `https://bico.media/1EZF5WfG6t35iwFpyVVptxT1MB4DKt6G2U`
   bsv blockchain repo using ([[git-remote-bsv|https://github.com/xloem/git-remote-bsv]])

rename todo/merge_tincho-osm_branch.mdwn to todo/merge_tina-osm_branch.mdwn
diff --git a/doc/todo/merge_tincho-osm_branch.mdwn b/doc/todo/merge_tina-osm_branch.mdwn
similarity index 100%
rename from doc/todo/merge_tincho-osm_branch.mdwn
rename to doc/todo/merge_tina-osm_branch.mdwn

Update user name
diff --git a/doc/todo/merge_tincho-osm_branch.mdwn b/doc/todo/merge_tincho-osm_branch.mdwn
index 26d6bf0eb..a0e4878af 100644
--- a/doc/todo/merge_tincho-osm_branch.mdwn
+++ b/doc/todo/merge_tincho-osm_branch.mdwn
@@ -1,4 +1,4 @@
-[[Tincho]] has an updated [[plugins/osm]] that fixes some basic usages,
+[[Tina]] has an updated [[plugins/osm]] that fixes some basic usages,
 greatly simplifies the code, and would let us close
 [[replace openlayers with leaflet]]
 and

Update user name and pronouns, sorry for modifying other people's writing, hope it is OK.
diff --git a/doc/plugins/osm/discussion.mdwn b/doc/plugins/osm/discussion.mdwn
index ff3cb8d36..43ea3a089 100644
--- a/doc/plugins/osm/discussion.mdwn
+++ b/doc/plugins/osm/discussion.mdwn
@@ -28,9 +28,9 @@ For usability it would be great if it was possible to display the active waypoin
 
 ## Updated plugin needs review and merge
 
-[[!template id=gitbranch branch=tincho-osm author="[[users/Tincho]]"]]
+[[!template id=gitbranch branch=tina-osm author="[[users/Tina]]"]]
 
-[[schmonz]] here. I recently tried to use this plugin, had some trouble, and discovered on IRC that [[users/Tincho]] has a largely [rewritten version](https://blog.tincho.org/posts/OSM_in_IkiWiki/) that looks good [on his site](https://blog.tincho.org/Mingle/), but hadn't gotten around to submitting for merge. So we remote-paired on it today, improved a few things, and wrote down what we noticed:
+[[schmonz]] here. I recently tried to use this plugin, had some trouble, and discovered on IRC that [[users/Tina]] has a largely [rewritten version](https://tina.pm/blog/posts/OSM_in_IkiWiki/) that looks good [on her site](https://tina.pm/blog/Mingle/), but hadn't gotten around to submitting for merge. So we remote-paired on it today, improved a few things, and wrote down what we noticed:
 
 ### Features removed
 
@@ -64,10 +64,10 @@ For usability it would be great if it was possible to display the active waypoin
 - Given this is backward-incompatible, dhould we call it something other than "osm"?
 - What needs scrubbing? Have we covered all the bases? Too many bases?
 - Should we vendor Leaflet into an underlay, instead of needing a URL to load it from a CDN? [[schmonz]] somewhat prefers this, so we avoid needing external resources by default, avoid breaking when the Leaflet CDN is down, etc.
-- Should we write some tests before merging? `osm.pm` hadn't had any, FWIW -- [[users/Tincho]] Done
+- Should we write some tests before merging? `osm.pm` hadn't had any, FWIW -- [[users/Tina]] Done
 
-Bump! Tincho would like to see us merge his effort, and FWIW I'd also
-rather not have to carry around a local copy of his work to get a map
+Bump! Tina would like to see us merge her effort, and FWIW I'd also
+rather not have to carry around a local copy of her work to get a map
 with waypoints on my HTTPS site. [[smcv]], can you spare some round
 tuits to give us your thoughts? --[[schmonz]]
 
@@ -108,17 +108,17 @@ Looks like good changes to me!
 
 --[[kjs]]
 
-> The issue about not getting all the waipoints until you rebuild has been solved, the current plugin had issues with keeping track of updated and deleted waypoints which is now fixed in my branch. --[[users/Tincho]]
+> The issue about not getting all the waipoints until you rebuild has been solved, the current plugin had issues with keeping track of updated and deleted waypoints which is now fixed in my branch. --[[users/Tina]]
 
 ----
 
 I've done some initial testing now and I'm wondering if behaviour has changed with regards to the waypoint link. With the old plugin I get a map marker and link to the main map from each waypoint. See <http://img.kalleswork.net/Peter_Celsing-Filmhuset/IMGP7104/> for example, the marker is below the image. My initial tests with your plugin doesn't create this link as far as I can tell. Have I misconfigured something or is it indeed missing? --[[users/kjs]]
 
-> It is not there any more (I should document this, thanks for pointing it out). I thought that it was not good to have that marker inserted unconditionally; also, there is no full-page map any more with this plugin (which required a cgi mode). The alternative will be to have a page with the map, and adding a link to it. --[[users/Tincho]]
+> It is not there any more (I should document this, thanks for pointing it out). I thought that it was not good to have that marker inserted unconditionally; also, there is no full-page map any more with this plugin (which required a cgi mode). The alternative will be to have a page with the map, and adding a link to it. --[[users/Tina]]
 
 >> That's unfortunate for me as embedding a map on each page with a waypoint is a bit to expensive bandwidth wise. It will slow down the browsing to much. Are there any means of creating maps with subsets of waypoints. Perhaps tags somehow? Can a waypoint appear on multiple maps? I'm thinking having the waypoint appear on a central mega-map and on a sub map, In my case a per building map. Currently all my map info is automatically generated from the exif data. So I just upload the images to an underlay dir and git push my 'building' page which then generates an image gallery and a map of all my photos. I'm trying to avoid typing to much! ;) --[[users/kjs]]
 
 >>> What I meant was that you could add a wiki link (to a page with a map) next to each waypoint to simulate the old behaviour. 
->>> Maps with subsets of waypoints, waypoint in multiple maps: no, because a single GeoJSON file is created for each "map". But something that could be added is the ability to merge multiple maps into one view, as separate layers. --[[users/tincho]]
+>>> Maps with subsets of waypoints, waypoint in multiple maps: no, because a single GeoJSON file is created for each "map". But something that could be added is the ability to merge multiple maps into one view, as separate layers. --[[users/Tina]]
 
 >>>> A wiki link to a map page will show the whole map zoomed out I presume so that won't be helful when I have pois across the globe and you want to know which side of a building the photo is taken from :( Merging maps would be a very good feature! If it could be done with a pagespec type thing it would be awesome. For my use case I could then have a map at each building page showing the locations of all the photos under that page. The map file would be reasonably small. If these maps could then be merged via a directive with globbing of some sort into a mega-map that would be a very flexibly solution that automatically updates when I add new maps (buildings). I just need to use my non-existent programming skills to force my hack plugins into automatically creating per album maps.  -[[users/kjs]]

removed
diff --git a/doc/users/Tincho.mdwn b/doc/users/Tincho.mdwn
deleted file mode 100644
index 25ee1a1cc..000000000
--- a/doc/users/Tincho.mdwn
+++ /dev/null
@@ -1,3 +0,0 @@
-[Martín Ferrari](https://blog.tincho.org/)
-
-Long time user of ikiwiki. Made a [rewrite](https://blog.tincho.org/posts/OSM_in_IkiWiki/) of the OSM plugin, still pending merge.

diff --git a/doc/users/Tina.mdwn b/doc/users/Tina.mdwn
new file mode 100644
index 000000000..c3c7ad4c3
--- /dev/null
+++ b/doc/users/Tina.mdwn
@@ -0,0 +1,3 @@
+[Martina Ferrari](https://tina.pm/blog/)
+
+Long time user of ikiwiki. Made a [rewrite](https://tina.pm/blog/posts/OSM_in_IkiWiki/) of the OSM plugin, still pending merge.

fix-up wikilink
diff --git a/doc/users/jon.mdwn b/doc/users/jon.mdwn
index 35a541455..06368154d 100644
--- a/doc/users/jon.mdwn
+++ b/doc/users/jon.mdwn
@@ -8,7 +8,7 @@ since 2008, as well as a number of private instances.
 I've worked on a few different issues and bugs over the years (they
 are probably linked in "Backlinks", below) but these days my main
 effort is the [Opinionated Ikiwiki](https://github.com/jmtd/opinionated-ikiwiki/)
-[[containers|container]].
+[[container|containers]].
 
 ## historic
 

Refresh my user page
diff --git a/doc/users/jon.mdwn b/doc/users/jon.mdwn
index 3d5304365..35a541455 100644
--- a/doc/users/jon.mdwn
+++ b/doc/users/jon.mdwn
@@ -1,16 +1,16 @@
-[[!meta title="Jon Dowland"]][[!toc levels=2]]
+[[!meta title="Jonathan Dowland"]][[!toc levels=2]]
 
-## intro
+I've been using IkiWiki for [my personal site](https://jmtd.net/)
+since 2008, as well as a number of private instances.
 
-I'm looking at ikiwiki both for my personal site but also as a
-team-documentation management system for a small-sized group of UNIX
-sysadmins.
+## contributions
 
-* my edits should appear either as 'Jon' (if I've used
-  [[tips/untrusted_git_push]]); 'jmtd.net', 'jmtd.livejournal.com', 
-  'jmtd' if I've forgotten to set my local git config properly,
-  or once upon a time 'alcopop.org/me/openid/' or 'jondowland'.
-* My [homepage](http://jmtd.net/) is powered by ikiwiki
+I've worked on a few different issues and bugs over the years (they
+are probably linked in "Backlinks", below) but these days my main
+effort is the [Opinionated Ikiwiki](https://github.com/jmtd/opinionated-ikiwiki/)
+[[containers|container]].
+
+## historic
 
 I gave a talk at the [UK UNIX User's Group](http://www.ukuug.org/) annual
 [Linux conference](http://www.ukuug.org/events/linux2008/) in 2008 about
@@ -19,47 +19,3 @@ was discussing IkiWiki in some technical detail and suggesting it as a good
 piece of software for this task.
 
  * slides at <http://www.staff.ncl.ac.uk/jon.dowland/unix/docs/>.
-
-I am also working on some ikiwiki hacks:
-
-* [[todo/allow site-wide meta definitions]]
-* Improving the means by which you can migrate from mediawiki to
-  IkiWiki. See [[tips/convert mediawiki to ikiwiki]] and the
-  [[plugins/contrib/mediawiki]] plugin.
-
-I am mostly interested in ikiwiki usability issues:
-
- * [[bugs/the login page is unclear when multiple methods exist]]
- * [[bugs/backlinks onhover thing can go weird]]
- * [[todo/CSS classes for links]]
- * [[todo/adjust commit message for rename, remove]]
-
-The following I have been looking at, but are on the back-burner:
-
-* an alternative approach to [[plugins/comments]] (see
-  [[todo/more flexible inline postform]] for one piece of the puzzle;
-  <http://dev.jmtd.net/comments/> for some investigation into making the post
-  form more integrated); possibly also [[todo/pagespec to disable ikiwiki directives]]
-* a system for [[forum/managing_todo_lists]] (see also
-  [[todo/interactive todo lists]] and <http://dev.jmtd.net/outliner/> for the
-  current WIP).
-* a `tag2` plugin, which does the same thing as [[plugins/tag]], but
-  does not sit on top of [[ikiwiki/wikilink]]s, so does not result in
-  bugs such as [[bugs/tagged() matching wikilinks]]. Code for this lives
-  in my github `tag2` branch: <http://github.com/jmtd/ikiwiki>
-
-Penultimately, the following are merely half-formed thoughts:
-
- * adding and removing tags to pages via the edit form by ticking and
-   unticking checkboxes next to a tag name (rather than entering the 
-   directive into the text of the page directly)
- * perhaps the same for meta
- * I'd like to make profiling ikiwiki in action very easy for newcomers.
-   Perhaps even a plugin that created a file /profile or similar on build.
-
-## backlinks
-
-Finally, backlinks (since I have issues with the current backlinks
-implementation, see [[bugs/backlinks onhover thing can go weird]]):
-
-[[!map pages="link(users/Jon)"]]

split Docker container content out from Setup
The setup page has periodically listed one or more of the unofficial
containers of IkiWiki. Now there are at least three, move their
description out to a separate page.
diff --git a/doc/containers.mdwn b/doc/containers.mdwn
new file mode 100644
index 000000000..4ed39feae
--- /dev/null
+++ b/doc/containers.mdwn
@@ -0,0 +1,18 @@
+There are at least three unofficial container distributions of IkiWiki:
+
+ * [dgsb/ikiwiki](https://hub.docker.com/r/dgsb/ikiwiki/)
+   ([source on GitHub](https://github.com/dgsb/docker-ikiwiki)),
+   based on Debian Stretch, lighttpd and an internal ssh server
+
+ * [ankitrgadiya/ikiwiki](https://hub.docker.com/r/ankitrgadiya/ikiwiki)
+   ([source on GitHub](https://github.com/ankitrgadiya/docker-ikiwiki/)),
+   based on Debian stable and nginx,
+   by [[users/ankit]],
+   last updated 2018
+
+ * [opinionated-ikiwiki](https://quay.io/repository/jdowland/opinionated-ikiwiki)
+   ([source on GitHub](https://github.com/jmtd/opinionated-ikiwiki/)),
+   based on Debian 10, and lighttpd,
+   by [[users/Jon]]
+
+These can be used with a container runtime such as [Docker](https://www.docker.com/).
diff --git a/doc/setup.mdwn b/doc/setup.mdwn
index 0adcb1a97..8b2334508 100644
--- a/doc/setup.mdwn
+++ b/doc/setup.mdwn
@@ -7,9 +7,7 @@ This tutorial will walk you through setting up a wiki with ikiwiki.
 If you're using Debian or Ubuntu, ikiwiki is an <code><a href="http://www.debian.org/doc/manuals/debian-reference/ch02.en.html#_basic_package_management_operations">apt-get</a> install ikiwiki</code> away.
 If you're not, see the [[download]] and [[install]] pages.
 
-You may also want to try out a sandboxed [[Docker image|https://github.com/dgsb/docker-ikiwiki]]
-with ikiwiki pre-installed which will use a volume to access a local git repository
-for the wiki content.
+You may also want to try out IkiWiki in a [[container|containers]].
 
 ## Create your wiki
 

diff --git a/doc/todo/auto-generate_named_anchors_for_all_sections.mdwn b/doc/todo/auto-generate_named_anchors_for_all_sections.mdwn
index 657fcf8f9..83ec49ad4 100644
--- a/doc/todo/auto-generate_named_anchors_for_all_sections.mdwn
+++ b/doc/todo/auto-generate_named_anchors_for_all_sections.mdwn
@@ -1 +1,3 @@
 To enable linking to specific parts of long ikiwiki pages, like the git-annex man page, auto-generate named anchors for all sections, based e.g. on section names (`<a name="My_section">`).  Maybe also do this for list items.
+
+> The [[plugins/toc]] plugin does this. Is that not sufficient? There is also [[todo/toc-with-human-readable-anchors]]. -- [[anarcat]]

added suggestion to auto-generated named anchors for all sections
diff --git a/doc/todo/auto-generate_named_anchors_for_all_sections.mdwn b/doc/todo/auto-generate_named_anchors_for_all_sections.mdwn
new file mode 100644
index 000000000..657fcf8f9
--- /dev/null
+++ b/doc/todo/auto-generate_named_anchors_for_all_sections.mdwn
@@ -0,0 +1 @@
+To enable linking to specific parts of long ikiwiki pages, like the git-annex man page, auto-generate named anchors for all sections, based e.g. on section names (`<a name="My_section">`).  Maybe also do this for list items.

+1 the feature request
diff --git a/doc/todo/svg.mdwn b/doc/todo/svg.mdwn
index 274ebf3e3..586df4eae 100644
--- a/doc/todo/svg.mdwn
+++ b/doc/todo/svg.mdwn
@@ -75,3 +75,7 @@ Of course, this way to display an image one needs to click a link, but it may be
 > then this is a security hole, and the htmlscrubber
 > needs to lock it down more. Darn, now I have to spend my afternoon making
 > security releases! --[[Joey]] 
+
+* * * 
+
+This would be really neat, including the svg with an img tag limits the functionality because then any text in the svg is not parsed for [[WikiLinks|ikiwiki/wikilink]] or similar.  You could do some neat things like a timeline or a family tree where you would want mixed text and graphic elements by mixing markdown and svg on the same page. 

diff --git a/doc/forum/How_can_i_specify_an_altermate_smtp_for_email_auth__63_____40__with_credentials__41__.mdwn b/doc/forum/How_can_i_specify_an_altermate_smtp_for_email_auth__63_____40__with_credentials__41__.mdwn
new file mode 100644
index 000000000..2243faaad
--- /dev/null
+++ b/doc/forum/How_can_i_specify_an_altermate_smtp_for_email_auth__63_____40__with_credentials__41__.mdwn
@@ -0,0 +1,3 @@
+There does not seem to be any variable in setup to choose which smtp server to use for email auth.
+
+Is there an alternate way to do this, e.g. in global config?

diff --git a/doc/bugs/newer_email_tokens_don__39__t_replace_older_ones.mdwn b/doc/bugs/newer_email_tokens_don__39__t_replace_older_ones.mdwn
index 7c8cc0b96..83efb5aa0 100644
--- a/doc/bugs/newer_email_tokens_don__39__t_replace_older_ones.mdwn
+++ b/doc/bugs/newer_email_tokens_don__39__t_replace_older_ones.mdwn
@@ -1 +1,3 @@
 if I request more than one email login link, the first token received still has to be used. Using a later one triggers "bad token" error
+
+ikiwiki version 3.20200202.3

diff --git a/doc/bugs/newer_email_tokens_don__39__t_replace_older_ones.mdwn b/doc/bugs/newer_email_tokens_don__39__t_replace_older_ones.mdwn
new file mode 100644
index 000000000..7c8cc0b96
--- /dev/null
+++ b/doc/bugs/newer_email_tokens_don__39__t_replace_older_ones.mdwn
@@ -0,0 +1 @@
+if I request more than one email login link, the first token received still has to be used. Using a later one triggers "bad token" error

Added a comment: Solution
diff --git a/doc/forum/Non-interactive_setup/comment_1_e3b9539939a8b0dd3f912a3410dd27b2._comment b/doc/forum/Non-interactive_setup/comment_1_e3b9539939a8b0dd3f912a3410dd27b2._comment
new file mode 100644
index 000000000..6e8b67c05
--- /dev/null
+++ b/doc/forum/Non-interactive_setup/comment_1_e3b9539939a8b0dd3f912a3410dd27b2._comment
@@ -0,0 +1,14 @@
+[[!comment format=mdwn
+ username="ac_w"
+ avatar="http://cdn.libravatar.org/avatar/a76f89f70fffde5fbdacaa2a0438d8d9"
+ subject="Solution"
+ date="2021-05-11T14:00:34Z"
+ content="""
+I didn't fully understand it at first, but when you do `ikiwiki --setup /etc/ikiwiki/auto.setup`, the user `foo.setup` that is generated is enough to rebuild the wiki from scratch. So from a fresh reinstall the auto.setup step can be avoided if you already have the previous `foo.setup` backed up.
+
+So on my ansible usecase I just have to keep `foo.setup` as a template, copy it and build the wiki.
+
+I don't know if this creates a wiki administrator though. I guess it doesn't, since the foo.setup contains no info about it.
+
+If I really wanted to create an admin and choose its password, I guess I would have to run the `ikiwiki --setup /etc/ikiwiki/auto.setup`, and in this case the `expect` module from ansible would allow me to send the password to fill the prompt automatically (not tested). Seems kinda hacky though.
+"""]]

diff --git a/doc/forum/Globally_reverse_sort_order.mdwn b/doc/forum/Globally_reverse_sort_order.mdwn
new file mode 100644
index 000000000..17b598cf2
--- /dev/null
+++ b/doc/forum/Globally_reverse_sort_order.mdwn
@@ -0,0 +1 @@
+Is it possible to globally reverse sort order? I'd like oldest posts to appear first across the board, eg, in tags, posts, blog.

diff --git a/doc/ikiwiki/directive/pagestats/discussion.mdwn b/doc/ikiwiki/directive/pagestats/discussion.mdwn
index 9e30cb6ef..159cbb82b 100644
--- a/doc/ikiwiki/directive/pagestats/discussion.mdwn
+++ b/doc/ikiwiki/directive/pagestats/discussion.mdwn
@@ -2,7 +2,9 @@ Hey,
 using the "ikistrap" theme, and just trying to generate a tagcloud in the index/home page of the site nothiing will show - as a table, it works though! the tag pages are created, but not found by pagestats it seems to me...
 Does someone have an idea why that is?
 Thanks, Flo
----
+
+----
+
 I am trying to create a tag cloud using:  
            
      \[[!pagestats  pages="tags/*"]]

tagcloud problems
diff --git a/doc/ikiwiki/directive/pagestats/discussion.mdwn b/doc/ikiwiki/directive/pagestats/discussion.mdwn
index 99029e88e..9e30cb6ef 100644
--- a/doc/ikiwiki/directive/pagestats/discussion.mdwn
+++ b/doc/ikiwiki/directive/pagestats/discussion.mdwn
@@ -1,3 +1,8 @@
+Hey,
+using the "ikistrap" theme, and just trying to generate a tagcloud in the index/home page of the site nothiing will show - as a table, it works though! the tag pages are created, but not found by pagestats it seems to me...
+Does someone have an idea why that is?
+Thanks, Flo
+---
 I am trying to create a tag cloud using:  
            
      \[[!pagestats  pages="tags/*"]]

Added a comment: gitlab post-receive hook
diff --git a/doc/forum/Best_way_to_setup_LDAP_authentication___63__/comment_2_adcd5b2ca8e443a58a29d1a39e99a9fe._comment b/doc/forum/Best_way_to_setup_LDAP_authentication___63__/comment_2_adcd5b2ca8e443a58a29d1a39e99a9fe._comment
new file mode 100644
index 000000000..3602056fd
--- /dev/null
+++ b/doc/forum/Best_way_to_setup_LDAP_authentication___63__/comment_2_adcd5b2ca8e443a58a29d1a39e99a9fe._comment
@@ -0,0 +1,26 @@
+[[!comment format=mdwn
+ username="ac_w"
+ avatar="http://cdn.libravatar.org/avatar/a76f89f70fffde5fbdacaa2a0438d8d9"
+ subject="gitlab post-receive hook"
+ date="2021-05-06T15:38:16Z"
+ content="""
+Concerning the post-receive hook that I mentioned in the previous comment, it turned out I didn't have to bother with webhooks. Even though it's a bit out of the scope of this topic, here is how to do it:
+
+- Find the hashed name of the repository in the Admin Area of gitlab. ([see details](https://docs.gitlab.com/ee/administration/repository_storage_types.html#from-project-name-to-hashed-path))
+
+- `mkdir /var/opt/gitlab/git-data/repositories/@hashed/<group_hash>/<repo_hash>.git/custom_hooks` ([see details](https://github.com/gitlabhq/gitlabhq/blob/667c0a909bde1cf71f21d8ec9768e98b1c489030/doc/hooks/custom_hooks.md))
+
+- create `/var/opt/gitlab/git-data/repositories/@hashed/<group_hash>/<repo_hash>.git/custom_hooks/post-receive` with the following content :
+
+```bash
+#!/bin/sh
+git log -1 --format=format:%ae HEAD | grep -e '@web$' -e 'ikiwiki' ||  wget \"https://<wiki_url>/ikiwiki.cgi?do=ping\" -O -
+```
+
+(without the shebang it doesn't work, also I had to remove the `/dev/stdout` part otherwise the shell complains git can't write to it)
+
+- `chown -R git:root /var/opt/gitlab/git-data/repositories/@hashed/<group_hash>/<repo_hash>.git/custom_hooks`
+
+- `chmod +x /var/opt/gitlab/git-data/repositories/@hashed/<group_hash>/<repo_hash>.git/custom_hooks/post-receive`
+
+"""]]

Added a comment: Solution
diff --git a/doc/forum/Best_way_to_setup_LDAP_authentication___63__/comment_1_f071bea899389d805dbac0703a7612d4._comment b/doc/forum/Best_way_to_setup_LDAP_authentication___63__/comment_1_f071bea899389d805dbac0703a7612d4._comment
new file mode 100644
index 000000000..10e587a02
--- /dev/null
+++ b/doc/forum/Best_way_to_setup_LDAP_authentication___63__/comment_1_f071bea899389d805dbac0703a7612d4._comment
@@ -0,0 +1,27 @@
+[[!comment format=mdwn
+ username="ac_w"
+ avatar="http://cdn.libravatar.org/avatar/a76f89f70fffde5fbdacaa2a0438d8d9"
+ subject="Solution"
+ date="2021-05-06T13:31:21Z"
+ content="""
+I've managed to make it work with the method described [here](https://ikiwiki.info/plugins/httpauth/).
+
+I did not understand at first that an LDAP authentication on the webserver was enough and that ikiwiki would just trust what the webserver returns. Anyway, I replaced nginx with apache2, loaded the modules `authnz_ldap` and `ldap`, and used a configuration like this one :
+
+```
+<Location /~ikiwiki/wiki_name/auth>
+        order allow,deny 
+        allow from all 
+        AuthName \"AuthRequired\" 
+        AuthType Basic 
+        AuthBasicProvider ldap 
+
+        AuthLDAPURL \"ldap://<ldap_fqdn>:389/<searchbase>?uid?sub?<searchfilter>\" 
+        AuthLDAPBindDN  \"<binddn>\" 
+        AuthLDAPBindPassword \"<password>\" 
+        require valid-user 
+</Location>
+```
+
+As you can see I chose the second option of [the documentation](https://ikiwiki.info/plugins/httpauth/) (separate cgiauthurl), as gitlab must be able to ping the wiki without authentication (as mentioned at the end of [this doc](https://ikiwiki.info/tips/Hosting_Ikiwiki_and_master_git_repository_on_different_machines/)). Unfortunately gitlab doesn't seem to provide a way to set complex post-receive hook (the interface just provides something called \"webhooks\" which just takes an url and not a complete shell command), so I need to investigate further.
+"""]]

diff --git a/doc/forum/Non-interactive_setup.mdwn b/doc/forum/Non-interactive_setup.mdwn
new file mode 100644
index 000000000..102e0d3a6
--- /dev/null
+++ b/doc/forum/Non-interactive_setup.mdwn
@@ -0,0 +1,9 @@
+Hello,
+
+I'm trying to install and setup an ikiwiki in a fully automated way (using ansible, for info), and I'd like to know if it's possible to have an automated [setup](https://ikiwiki.info/setup/) step ( `ikiwiki --setup /etc/ikiwiki/auto.setup` ).
+
+Apparently I can reassign all variables in the .setup file or even on the command line, but if I set `$admin` to a certain value it keeps prompting me for a password. So :
+
+- can I set the admin password somewhere in the .setup file or on the command line ?
+
+- if I can't, can I avoid setting any (and re-define one maybe later) ?

diff --git a/doc/forum/Best_way_to_setup_LDAP_authentication___63__.mdwn b/doc/forum/Best_way_to_setup_LDAP_authentication___63__.mdwn
new file mode 100644
index 000000000..eb539389f
--- /dev/null
+++ b/doc/forum/Best_way_to_setup_LDAP_authentication___63__.mdwn
@@ -0,0 +1,7 @@
+Hello,
+
+I'm trying to set up an internal wiki at work using the git repos we already have, and I'd like to set up LDAP authentication to connect to ikiwiki.
+
+I see that ikiwiki [can use the unix accounts of the underlying system](https://ikiwiki.info/plugins/contrib/unixauth/), so I should be able to have LDAP authentication via NSS or PAM, but those only work if the LDAP user entries have the attribute 'objectClass: posixAccount' (unless I'm doing it wrong). My  LDAP entries have the 'uid', 'userPassword' and 'mail' attributes and I guess this should theoretically be enough since other applications can use it (like gitlab).
+
+What are my options ?

one of those two docker images has disappeared, link to just the remaining one
diff --git a/doc/setup.mdwn b/doc/setup.mdwn
index 9fc37c0b1..0adcb1a97 100644
--- a/doc/setup.mdwn
+++ b/doc/setup.mdwn
@@ -7,8 +7,8 @@ This tutorial will walk you through setting up a wiki with ikiwiki.
 If you're using Debian or Ubuntu, ikiwiki is an <code><a href="http://www.debian.org/doc/manuals/debian-reference/ch02.en.html#_basic_package_management_operations">apt-get</a> install ikiwiki</code> away.
 If you're not, see the [[download]] and [[install]] pages.
 
-You may also want to try out a sandboxed [[Docker image|https://github.com/elecnix/ikiwiki-docker]]
-with ikiwiki pre-installed or this other [[one|https://github.com/dgsb/docker-ikiwiki]] which will use a volume to access a local git repository
+You may also want to try out a sandboxed [[Docker image|https://github.com/dgsb/docker-ikiwiki]]
+with ikiwiki pre-installed which will use a volume to access a local git repository
 for the wiki content.
 
 ## Create your wiki

fixed
diff --git a/doc/bugs/anonymous_git_push_broken_again.mdwn b/doc/bugs/anonymous_git_push_broken_again.mdwn
index 4b15fd2d5..3e34b553a 100644
--- a/doc/bugs/anonymous_git_push_broken_again.mdwn
+++ b/doc/bugs/anonymous_git_push_broken_again.mdwn
@@ -25,3 +25,41 @@ Anon git push is broken again
 >> you decide to drop it from `ikiwiki.info`, would you leave the code as-is,
 >> or drop it as broken? Any further clues what went wrong this time?
 >> *—[[Jon]], 2021-01-13*
+
+----
+
+The HEAD.lock permissions error does not come from the post-receive hook or
+from ikiwiki when it runs it. Instead, stracing git-daemon shows that it
+happens after ikiwiki has checked the push and accepted it, and exited
+successfully. 
+
+So the problem is that git-daemon is unable to write to the git repo.
+
+	drwxr-sr-x+ 8 b-git-annex b-git-annex 4096 Mar 29 17:07 /home/b-git-annex/source.git/
+
+ikiwiki-hosting's ikisite is supposed to arrange for git-daemon
+to be able to write there by using an ACL, so something about that
+must be what is broken now. --[[Joey]]
+
+Ok, found the problem. ikisite runs setfacl, and that does the right thing.
+Then ikisite runs chmod on the source.git directory (to make it suid as seen
+above). That seems to mess up the ACLs that were set earlier.
+
+The diff from good to bad ACLs, as shown by getfacl is:
+
+	-group::rwx
+	-group:ikiwiki-anon:rwx
+	-group:b-ikiwiki:rwx
+	-group:b-git-annex:rwx
+	-mask::rwx
+	+group::rwx	#effective:r-x
+	+group:ikiwiki-anon:rwx	#effective:r-x
+	+group:b-ikiwiki:rwx	#effective:r-x
+	+group:b-git-annex:rwx	#effective:r-x
+	+mask::r-x
+
+I don't understand ACLs or how a chmod could clear them but ok, ikisite needs
+to chmod before setting the ACLS.
+
+This is not an ikiwiki bug and I'll fix it in ikisite-hosting then. [[done]]
+--[[Joey]]

diff --git a/doc/forum/Does_anyone_have_the_latest_version_of_the_AsciiDoc_plugin__63__.mdwn b/doc/forum/Does_anyone_have_the_latest_version_of_the_AsciiDoc_plugin__63__.mdwn
new file mode 100644
index 000000000..f51f7a020
--- /dev/null
+++ b/doc/forum/Does_anyone_have_the_latest_version_of_the_AsciiDoc_plugin__63__.mdwn
@@ -0,0 +1,5 @@
+The [[/plugins/contrib/asciidoc]] page describes an enhanced version of the AsciiDoc plugin, but the link to it isn't live anymore.
+
+Would anyone happen to have a copy of the enhanced plugin?
+
+Thanks

cherry-picked, tx
diff --git a/doc/todo/admonitions.mdwn b/doc/todo/admonitions.mdwn
index 5406365a5..16f0b00ee 100644
--- a/doc/todo/admonitions.mdwn
+++ b/doc/todo/admonitions.mdwn
@@ -166,3 +166,5 @@ the actiontab theme enabled:
 > I had kind of given up on this guy here, to be honest, but if you want to see a working version, you can look at [my sandbox](https://anarc.at/sandbox/). Obviously, the CSS does need more tweaking, but it seems it's not my specialty. ;) -- [[anarcat]]
 
 >> It turned out to be a simple fix, a missing semicolon. [patch here](https://github.com/jmtd/ikiwiki/commit/3e31200ed258ba1f7ab1652d6bc2d035a9e5c990). The rest of that branch is just your admonitions branch rebased onto `3.20200202.3`. *—[[Jon]], 2021-02-18*
+
+>>> Interesting. That was of course, a missing semicolon, not sure how I missed that. I cherry-picked your patch, but I wonder why I wasn't seeing the problem on my end... Maybe I had other padding that was covering for this... Thanks, in any case! :) -- [[anarcat]]

simple fix: a missing semi colon
diff --git a/doc/todo/admonitions.mdwn b/doc/todo/admonitions.mdwn
index d1109986b..5406365a5 100644
--- a/doc/todo/admonitions.mdwn
+++ b/doc/todo/admonitions.mdwn
@@ -164,3 +164,5 @@ the actiontab theme enabled:
 *— [[Jon]], 2021-02-15*
 
 > I had kind of given up on this guy here, to be honest, but if you want to see a working version, you can look at [my sandbox](https://anarc.at/sandbox/). Obviously, the CSS does need more tweaking, but it seems it's not my specialty. ;) -- [[anarcat]]
+
+>> It turned out to be a simple fix, a missing semicolon. [patch here](https://github.com/jmtd/ikiwiki/commit/3e31200ed258ba1f7ab1652d6bc2d035a9e5c990). The rest of that branch is just your admonitions branch rebased onto `3.20200202.3`. *—[[Jon]], 2021-02-18*

response
diff --git a/doc/todo/admonitions.mdwn b/doc/todo/admonitions.mdwn
index 20ad6fc5b..d1109986b 100644
--- a/doc/todo/admonitions.mdwn
+++ b/doc/todo/admonitions.mdwn
@@ -150,6 +150,8 @@ in either case (which will at least mean there'll be another avenue for people t
 >>> `admonitions` was rebased on top of whatever your `master` was, then GitLab's "Compare" would be useful. As it is, I cloned locally and did the necessary
 >>> `git` incantation. *— [[Jon]], 2020-08-12*
 
+>>>> I have rebased all my current branches onto `debian/3.20190228-1` because that's what I'm patching in production, and I have updated my `master` branch on GitLab to follow that. The branches are admonitions, [bootstrap-plugin](https://ikiwiki.info/plugins/contrib/bootstrap), [toc-skip](https://ikiwiki.info/todo/allow_toc_to_skip_entries), [page-template-variable](https://ikiwiki.info/todo/include_page_variable_in_base_templates), [js-newline](https://ikiwiki.info/bugs/javascript_resources_placed_after_html_tag/), [i18n-headinganchors](https://ikiwiki.info/plugins/contrib/i18nheadinganchors), [dev/git-annex-support](https://ikiwiki.info/todo/git-annex_support/), and [geo-scheme](https://ikiwiki.info/todo/add_geo_uri_scheme/). Phew. Is that what you needed? It's still kind of a mess, but it should make it easier for you to review... --[[anarcat]]
+
 ----
 
 I've finally started playing around with this plugin. I think the default CSS needs
@@ -160,3 +162,5 @@ the actiontab theme enabled:
 
 <img src=https://jmtd.net/tmp/admonition.png alt="pic demoing admonitions" />
 *— [[Jon]], 2021-02-15*
+
+> I had kind of given up on this guy here, to be honest, but if you want to see a working version, you can look at [my sandbox](https://anarc.at/sandbox/). Obviously, the CSS does need more tweaking, but it seems it's not my specialty. ;) -- [[anarcat]]

admonition css may need some tweaking
diff --git a/doc/todo/admonitions.mdwn b/doc/todo/admonitions.mdwn
index c68ce11f8..20ad6fc5b 100644
--- a/doc/todo/admonitions.mdwn
+++ b/doc/todo/admonitions.mdwn
@@ -149,3 +149,14 @@ in either case (which will at least mean there'll be another avenue for people t
 >>> was a much earlier commit than `d0099568`, so "Compare" would include all the unrelated upstream changes. If instead either `master` was `d0099568`, or
 >>> `admonitions` was rebased on top of whatever your `master` was, then GitLab's "Compare" would be useful. As it is, I cloned locally and did the necessary
 >>> `git` incantation. *— [[Jon]], 2020-08-12*
+
+----
+
+I've finally started playing around with this plugin. I think the default CSS needs
+tweaking. I see "warning" has `padding` to try to account for the icon size, but 
+the other admonitions do not. Perhaps they need to inherit some style from a common
+class? Either way, the padding does not seem to work. This is a fresh ikiwiki with
+the actiontab theme enabled:
+
+<img src=https://jmtd.net/tmp/admonition.png alt="pic demoing admonitions" />
+*— [[Jon]], 2021-02-15*

a clean-up plugin, to keep dest dir synced only to ikiwiki generates files
diff --git a/doc/todo/plugin_to_clean_up_files_in_destdir.mdwn b/doc/todo/plugin_to_clean_up_files_in_destdir.mdwn
new file mode 100644
index 000000000..0a7e131bc
--- /dev/null
+++ b/doc/todo/plugin_to_clean_up_files_in_destdir.mdwn
@@ -0,0 +1,6 @@
+By default, IkiWiki will leave any existing files in the destination directory alone.
+
+In some circumstances (a force push being one), files that IkiWiki did once generate can be left behind in the destination directory if it no longer does.
+
+Since IkiWiki generates a list of all destination file paths that it is responsible for, a plugin (armed with that knowledge) could identify the files it *isn't* responsible for, too, and clean them up. This would be useful if the user wishes to keep a 1:1 correspondence between source and destination directories.
+ *—[[Jon]], 2021-02-07*

initial patch was 2019
diff --git a/doc/todo/Change_the_ikiwiki.info_search_box_to_not_using_Google.mdwn b/doc/todo/Change_the_ikiwiki.info_search_box_to_not_using_Google.mdwn
index f48396f5f..84e83cea7 100644
--- a/doc/todo/Change_the_ikiwiki.info_search_box_to_not_using_Google.mdwn
+++ b/doc/todo/Change_the_ikiwiki.info_search_box_to_not_using_Google.mdwn
@@ -9,7 +9,7 @@ With both engines adding the "site:ikiwiki.info" string to the search terms limi
 > I've had a first stab at implementing this. It's in [my fork on
 > GitHub](https://github.com/jmtd/ikiwiki/tree/duckduckgo), specifically [branch
 > duckduckgo](https://github.com/jmtd/ikiwiki/tree/duckduckgo).
-> It's also live on <https://jmtd.net/>. — [[Jon]] [[!tag patch]]
+> It's also live on <https://jmtd.net/>. — [[Jon]] (2019) [[!tag patch]]
 
 >> I've just updated this branch to not require JavaScript (I learned about a hidden parameter to
 >> the search form for specifying the URLs to search under). In case this wasn't clear already, I

clarify: ikiwiki plugin, ikiwiki.info site configuration request, separate
diff --git a/doc/todo/Change_the_ikiwiki.info_search_box_to_not_using_Google.mdwn b/doc/todo/Change_the_ikiwiki.info_search_box_to_not_using_Google.mdwn
index 94face4c9..f48396f5f 100644
--- a/doc/todo/Change_the_ikiwiki.info_search_box_to_not_using_Google.mdwn
+++ b/doc/todo/Change_the_ikiwiki.info_search_box_to_not_using_Google.mdwn
@@ -14,3 +14,12 @@ With both engines adding the "site:ikiwiki.info" string to the search terms limi
 >> I've just updated this branch to not require JavaScript (I learned about a hidden parameter to
 >> the search form for specifying the URLs to search under). In case this wasn't clear already, I
 >> think this is ready for review and to consider merging to IkIWiki proper. *— [[Jon]], 2020-12-11*
+
+>>> To clarify: What I've done is write a self-contained ikiwiki plugin that can be used as a drop-in
+>>> replacement for google on any Ikiwiki. Naturally I would like that included in IkiWiki. (1)
+>>> 
+>>> However this bug is actually about <https://ikiwiki.info/> — every time I search the site I am
+>>> reminded that IW defaults to Google, because I'm prompted by some pop-over to accept some T&Cs
+>>> every time (I don't let it save the cookie). (2)
+>>> 
+>>> (1) is no doubt a pre-requisite for (2). Are either under consideration? *—[[Jon]], 2021-02-07*

diff --git a/doc/users/commagray.mdwn b/doc/users/commagray.mdwn
new file mode 100644
index 000000000..52255115f
--- /dev/null
+++ b/doc/users/commagray.mdwn
@@ -0,0 +1 @@
+ponk

Added a comment: wiki_file_chars
diff --git a/doc/forum/Is_the_Chinese_quotation_marks_for_book_titles_bad_for_source_file_names__63__/comment_1_f26ad7f88a35ecac838da50655806449._comment b/doc/forum/Is_the_Chinese_quotation_marks_for_book_titles_bad_for_source_file_names__63__/comment_1_f26ad7f88a35ecac838da50655806449._comment
new file mode 100644
index 000000000..14d647d8d
--- /dev/null
+++ b/doc/forum/Is_the_Chinese_quotation_marks_for_book_titles_bad_for_source_file_names__63__/comment_1_f26ad7f88a35ecac838da50655806449._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="jmtd"
+ avatar="http://cdn.libravatar.org/avatar/2a3bcb34947fceef61560bd8a2931957"
+ subject="wiki_file_chars"
+ date="2021-01-14T10:28:48Z"
+ content="""
+Check the `wiki_file_chars` value in your setup file. You can add characters to it in order to allow them in filenames.
+"""]]

diff --git a/doc/forum/Is_the_Chinese_quotation_marks_for_book_titles_bad_for_source_file_names__63__.mdwn b/doc/forum/Is_the_Chinese_quotation_marks_for_book_titles_bad_for_source_file_names__63__.mdwn
index a592b7ebe..e0ad464c4 100644
--- a/doc/forum/Is_the_Chinese_quotation_marks_for_book_titles_bad_for_source_file_names__63__.mdwn
+++ b/doc/forum/Is_the_Chinese_quotation_marks_for_book_titles_bad_for_source_file_names__63__.mdwn
@@ -1,7 +1,9 @@
-I have some markdown source files that have Chinese quotation marks for book titles (i.e. 《<some book title>》). These files do not get build. When I rebuild the site, it complains
+I have some markdown source files that have Chinese quotation marks for book titles (i.e. `《<some book title>》`). These files do not get build. When I rebuild the site, it complains
 
+```
 ...
 skipping bad filename 《<some book title>》.md
 ...
+```
 
 Any idea?

diff --git a/doc/forum/Is_the_Chinese_quotation_marks_for_book_titles_bad_for_source_file_names__63__.mdwn b/doc/forum/Is_the_Chinese_quotation_marks_for_book_titles_bad_for_source_file_names__63__.mdwn
new file mode 100644
index 000000000..a592b7ebe
--- /dev/null
+++ b/doc/forum/Is_the_Chinese_quotation_marks_for_book_titles_bad_for_source_file_names__63__.mdwn
@@ -0,0 +1,7 @@
+I have some markdown source files that have Chinese quotation marks for book titles (i.e. 《<some book title>》). These files do not get build. When I rebuild the site, it complains
+
+...
+skipping bad filename 《<some book title>》.md
+...
+
+Any idea?

what went wrong this time? whether it's useful
diff --git a/doc/bugs/anonymous_git_push_broken_again.mdwn b/doc/bugs/anonymous_git_push_broken_again.mdwn
index 6f40bf771..4b15fd2d5 100644
--- a/doc/bugs/anonymous_git_push_broken_again.mdwn
+++ b/doc/bugs/anonymous_git_push_broken_again.mdwn
@@ -17,3 +17,11 @@ Anon git push is broken again
 > Since this is now seeming so fragile -- after working for about a decade,
 > it's broken twice in a matter of months -- I'm questioning whether it's
 > worth trying to keep the feature working. --[[Joey]]
+
+>> Of course, that's got to be your call. I haven't made a great deal of use
+>> of it, but it *does* seem more convenient if one is working on an IkiWiki
+>> patch, as I can write the website notes about it in the same tree (although
+>> I then have to cherry-pick to push that to the live site, of course.). If
+>> you decide to drop it from `ikiwiki.info`, would you leave the code as-is,
+>> or drop it as broken? Any further clues what went wrong this time?
+>> *—[[Jon]], 2021-01-13*

correct some dates
diff --git a/doc/todo/pagespec_aliases.mdwn b/doc/todo/pagespec_aliases.mdwn
index 0d97a1b1e..54e252956 100644
--- a/doc/todo/pagespec_aliases.mdwn
+++ b/doc/todo/pagespec_aliases.mdwn
@@ -236,8 +236,8 @@ I will (after writing this) rebase my branch. Please take another look!
 with IkiWiki's auto-mirror-pull, the branch is here:
 <https://github.com/jmtd/ikiwiki/tree/pagespec-alias>)
 
-*— [[Jon]], 2020-01-10*
+*— [[Jon]], 2021-01-10*
 
-> Scratch that, more work needed ☹ *— [[Jon]], 2020-01-11*
+> Scratch that, more work needed ☹ *— [[Jon]], 2021-01-11*
 
->> This is really ready now. *— [[Jon]], 2020-01-13*
+>> This is really ready now. *— [[Jon]], 2021-01-13*

This is really ready now.
diff --git a/doc/todo/pagespec_aliases.mdwn b/doc/todo/pagespec_aliases.mdwn
index dfbec8aa5..0d97a1b1e 100644
--- a/doc/todo/pagespec_aliases.mdwn
+++ b/doc/todo/pagespec_aliases.mdwn
@@ -239,3 +239,5 @@ with IkiWiki's auto-mirror-pull, the branch is here:
 *— [[Jon]], 2020-01-10*
 
 > Scratch that, more work needed ☹ *— [[Jon]], 2020-01-11*
+
+>> This is really ready now. *— [[Jon]], 2020-01-13*

Scratch that, more work needed ☹
diff --git a/doc/todo/pagespec_aliases.mdwn b/doc/todo/pagespec_aliases.mdwn
index 2a6ce55b4..dfbec8aa5 100644
--- a/doc/todo/pagespec_aliases.mdwn
+++ b/doc/todo/pagespec_aliases.mdwn
@@ -237,3 +237,5 @@ with IkiWiki's auto-mirror-pull, the branch is here:
 <https://github.com/jmtd/ikiwiki/tree/pagespec-alias>)
 
 *— [[Jon]], 2020-01-10*
+
+> Scratch that, more work needed ☹ *— [[Jon]], 2020-01-11*

link to branch URI just in case the mirrorer breaks
diff --git a/doc/todo/pagespec_aliases.mdwn b/doc/todo/pagespec_aliases.mdwn
index 114ca3bef..2a6ce55b4 100644
--- a/doc/todo/pagespec_aliases.mdwn
+++ b/doc/todo/pagespec_aliases.mdwn
@@ -232,5 +232,8 @@ you have disabled a plugin that defined a PageSpec name and you want to substitu
 what it would have expanded to with something else, for example.
 
 I will (after writing this) rebase my branch. Please take another look!
+(just in case the rebase and/or the "-" in the branchnames causes problems
+with IkiWiki's auto-mirror-pull, the branch is here:
+<https://github.com/jmtd/ikiwiki/tree/pagespec-alias>)
 
 *— [[Jon]], 2020-01-10*

addressing review comments; please take another look!
diff --git a/doc/todo/pagespec_aliases.mdwn b/doc/todo/pagespec_aliases.mdwn
index bd64a5040..114ca3bef 100644
--- a/doc/todo/pagespec_aliases.mdwn
+++ b/doc/todo/pagespec_aliases.mdwn
@@ -211,3 +211,26 @@ or [[smcv]]?) or otherwise feed back on this? Thanks! — [[Jon]] (2018-09-25)
 > this works.)
 >
 > --[[smcv]]
+
+----
+
+Thank you for the review (nearly a year ago, I've just noticed!). I've
+added checks for the issues you outline above, and test coverage for all
+those issues.
+I've also decided to rename the plugin (back) to just "alias":
+I mooted that right back when I started this but I was worried about
+potential ambiguity. That was ten years ago and I think the concern has
+prove unfounded. I've left the config key as `pagespec_aliases` though,
+as that's one area I think its clearer.
+
+With regards `aliasname()` versus `alias(aliasname)`:
+I've given this some thought. Pros and cons of that approach: it would be
+a little uglier; you would not inadvertently clash with a PageSpec defined
+elsewhere. However, I wonder if someone might actually *want* to define a
+PageSpec this way that was the same as that defined by something else: Perhaps,
+you have disabled a plugin that defined a PageSpec name and you want to substitute
+what it would have expanded to with something else, for example.
+
+I will (after writing this) rebase my branch. Please take another look!
+
+*— [[Jon]], 2020-01-10*

I just hit this, thank you for the fix
diff --git a/doc/bugs/ikiwiki_explodes_when_git_rewrites_history.mdwn b/doc/bugs/ikiwiki_explodes_when_git_rewrites_history.mdwn
index fa839928f..b57ad9b46 100644
--- a/doc/bugs/ikiwiki_explodes_when_git_rewrites_history.mdwn
+++ b/doc/bugs/ikiwiki_explodes_when_git_rewrites_history.mdwn
@@ -17,3 +17,6 @@ Notice how the error message from git isn't present. It's in the `error.log`:
 The workaround I have found was to remove the `indexdb` file, because that's [[apparently legit|tips/inside_dot_ikiwiki/]]. But it would be nice to have (1) a proper error message (it had to dig around the error.log to understand what's going on), (2) to have a proper fallback if the `git log` fails and (3) to recover with the newer commit ID when we fallback. --[[anarcat]]
 
 > FWIW, I had a `500 Internal Server Error` while submitting this bug at first. :)
+
+>> I've just hit this, and fixed it thanks to you reporting what you did. Thanks!
+>> ([fix in opinionated ikiwiki](https://github.com/jmtd/opinionated-ikiwiki/commit/0dd1bb3e91503713a36e8f9e6144b56db0fd8f37)) *— [[Jon]], 2021-01-08*

situation where rebuild needed
diff --git a/doc/bugs/disabling_theme_plugin_should_trigger_site_rebuild.mdwn b/doc/bugs/disabling_theme_plugin_should_trigger_site_rebuild.mdwn
new file mode 100644
index 000000000..4250ca521
--- /dev/null
+++ b/doc/bugs/disabling_theme_plugin_should_trigger_site_rebuild.mdwn
@@ -0,0 +1,2 @@
+Disabling [[plugins/theme]] should trigger a site rebuild, just as enabling it does.
+In particular when performing the operation via the [[plugins/websetup]] front-end. *— [[Jon]], 2021-01-05*

Lightweight comments
diff --git a/doc/plugins/comments/discussion.mdwn b/doc/plugins/comments/discussion.mdwn
index 0641ddcc9..e7457cbac 100644
--- a/doc/plugins/comments/discussion.mdwn
+++ b/doc/plugins/comments/discussion.mdwn
@@ -255,3 +255,10 @@ imported blog comments with full fidelity. OK to commit?
 > Ship it. --[[smcv]]
 
 >> Thanks, have done. --[[schmonz]]
+
+
+## Keeping comments separate from content to avoid triggering rebuilds
+
+Is there a way of preventing comments from triggering long chains of rebuilds? Currently comments trigger the same chain of events as if the page itself had been modified (at least this seems to be the case). A way of keeping comments lightweight and out of ikiwiki would be great. This has obvious consequences but currently comments are to slow for my users. My site is complex with tags and trails (albums) so commenting the wrong page leads to several minutes of rebuild (being conservative here...). For my use case comments don't need wikilinks or any wiki features. 
+
+To my thinking it could be useful to have comments as a very lightweight type of data that enables interactivity but not the full force of ikiwiki. Any thoughts?

really generate HTML5 by default
diff --git a/doc/todo/really_generate_HTML5_by_default.mdwn b/doc/todo/really_generate_HTML5_by_default.mdwn
new file mode 100644
index 000000000..48c09457d
--- /dev/null
+++ b/doc/todo/really_generate_HTML5_by_default.mdwn
@@ -0,0 +1,5 @@
+[[generate HTML5 by default]] exists and is marked *done* because we are now in a halfway-house where some HTML5 stuff (including the DTD) are emitted by default but most of the structural elements are not used and we have div soup. This page is a bug to request that we *really* move to HTML5 by default, specifically as a precursor to removing all the branching around this parameter that exists in the templates. Once the HTML5-by-default situation is settled, we could remove all that branching and then address generating HTML4.1 (or whatever) via a post-process DOM transformation plugin.
+
+It's been 10 years since the HTML5 option was added. At the time there was some concern about legacy support for IE8. I rather suspect that the number of IE8 ikiwiki users (or ikiwiki users concerned about IE8) approximates zero, today. But if not, perhaps we should [[todo/clarify what browser support is important for IkiWiki]].
+
+*— [[Jon]], 2020-12-30*

comment
diff --git a/doc/bugs/anonymous_git_push_broken_again.mdwn b/doc/bugs/anonymous_git_push_broken_again.mdwn
index 9ef21d66a..6f40bf771 100644
--- a/doc/bugs/anonymous_git_push_broken_again.mdwn
+++ b/doc/bugs/anonymous_git_push_broken_again.mdwn
@@ -8,3 +8,12 @@ Anon git push is broken again
      ! [remote rejected]     master -> master (failed to update ref)
 
 *—[[Jon]], 2020-10-06*
+
+> It does not seem related to the other problem. I don't understand how it
+> could have broken in a new way since I fixed it before. git has not been
+> upgraded in the meantime. This is affecting more than one site, and the
+> permissions do not seem obviously broken.
+> 
+> Since this is now seeming so fragile -- after working for about a decade,
+> it's broken twice in a matter of months -- I'm questioning whether it's
+> worth trying to keep the feature working. --[[Joey]]

updated branch; this is ready for review for inclusion in IkIWiki
diff --git a/doc/todo/Change_the_ikiwiki.info_search_box_to_not_using_Google.mdwn b/doc/todo/Change_the_ikiwiki.info_search_box_to_not_using_Google.mdwn
index 688b3cb85..94face4c9 100644
--- a/doc/todo/Change_the_ikiwiki.info_search_box_to_not_using_Google.mdwn
+++ b/doc/todo/Change_the_ikiwiki.info_search_box_to_not_using_Google.mdwn
@@ -11,3 +11,6 @@ With both engines adding the "site:ikiwiki.info" string to the search terms limi
 > duckduckgo](https://github.com/jmtd/ikiwiki/tree/duckduckgo).
 > It's also live on <https://jmtd.net/>. — [[Jon]] [[!tag patch]]
 
+>> I've just updated this branch to not require JavaScript (I learned about a hidden parameter to
+>> the search form for specifying the URLs to search under). In case this wasn't clear already, I
+>> think this is ready for review and to consider merging to IkIWiki proper. *— [[Jon]], 2020-12-11*

new
diff --git a/doc/examples/blog/posts/A_new_title:_The_US_and_the_global_economic_developement___40__by_Stanley_Fisher__41__.mdwn b/doc/examples/blog/posts/A_new_title:_The_US_and_the_global_economic_developement___40__by_Stanley_Fisher__41__.mdwn
new file mode 100644
index 000000000..1efb8f575
--- /dev/null
+++ b/doc/examples/blog/posts/A_new_title:_The_US_and_the_global_economic_developement___40__by_Stanley_Fisher__41__.mdwn
@@ -0,0 +1 @@
+I have had this sheet of paper be put on everybody's chair, and I will refer back to it from time to time.

diff --git a/doc/todo/more_flexibility_in_the_date_parameter_for_the_meta_plugin.mdwn b/doc/todo/more_flexibility_in_the_date_parameter_for_the_meta_plugin.mdwn
index 0ec1bdb63..643e2ff1a 100644
--- a/doc/todo/more_flexibility_in_the_date_parameter_for_the_meta_plugin.mdwn
+++ b/doc/todo/more_flexibility_in_the_date_parameter_for_the_meta_plugin.mdwn
@@ -33,3 +33,5 @@ index cd367da70..dbcf99aea 100644
 luke@schierer@opus001:~/src/ikiwiki/ikiwiki$ 
 ```
 
+[[!tag patch]]
+

diff --git a/doc/todo/more_flexibility_in_the_date_parameter_for_the_meta_plugin.mdwn b/doc/todo/more_flexibility_in_the_date_parameter_for_the_meta_plugin.mdwn
index a4ed2d849..0ec1bdb63 100644
--- a/doc/todo/more_flexibility_in_the_date_parameter_for_the_meta_plugin.mdwn
+++ b/doc/todo/more_flexibility_in_the_date_parameter_for_the_meta_plugin.mdwn
@@ -1 +1,35 @@
 Changing from perl Date::Parse to Date::Manip causes it to accept some strings that it otherwise could not.  This is mostly dealing with situations where it has to infer values from partial date strings, but sometimes that is useful. 
+
+```
+luke@schierer@opus001:~/src/ikiwiki/ikiwiki$ cat meta_date_manip.patch
+diff --git a/IkiWiki/Plugin/meta.pm b/IkiWiki/Plugin/meta.pm
+index cd367da70..dbcf99aea 100644
+--- a/IkiWiki/Plugin/meta.pm
++++ b/IkiWiki/Plugin/meta.pm
+@@ -152,9 +152,9 @@ sub preprocess (@) {
+                # fallthrough
+        }
+        elsif ($key eq 'date') {
+-               eval q{use Date::Parse};
++               eval q{use Date::Manip};
+                if (! $@) {
+-                       my $time = str2time($value);
++                       my $time = UnixDate( ParseDate($value), "%s");
+                        if (defined $time) {
+                                $IkiWiki::pagectime{$page}=$time;
+                        }
+@@ -167,9 +167,9 @@ sub preprocess (@) {
+                }
+        }
+        elsif ($key eq 'updated') {
+-               eval q{use Date::Parse};
++               eval q{use Date::Manip};
+                if (! $@) {
+-                       my $time = str2time($value);
++                       my $time = UnixDate ( ParseDate($value), "%s");
+                        if (defined $time) {
+                                $pagestate{$page}{meta}{updated}=$time;
+                        }
+luke@schierer@opus001:~/src/ikiwiki/ikiwiki$ 
+```
+

diff --git a/doc/todo/more_flexibility_in_the_date_parameter_for_the_meta_plugin.mdwn b/doc/todo/more_flexibility_in_the_date_parameter_for_the_meta_plugin.mdwn
new file mode 100644
index 000000000..a4ed2d849
--- /dev/null
+++ b/doc/todo/more_flexibility_in_the_date_parameter_for_the_meta_plugin.mdwn
@@ -0,0 +1 @@
+Changing from perl Date::Parse to Date::Manip causes it to accept some strings that it otherwise could not.  This is mostly dealing with situations where it has to infer values from partial date strings, but sometimes that is useful. 

reminds me of bugs/ table can not deal with Chinese
diff --git a/doc/bugs/graphviz_wide_characters.mdwn b/doc/bugs/graphviz_wide_characters.mdwn
index 9e0844857..ed273a698 100644
--- a/doc/bugs/graphviz_wide_characters.mdwn
+++ b/doc/bugs/graphviz_wide_characters.mdwn
@@ -8,3 +8,5 @@ Note, this is what renders on the resulting wiki page, not something that you se
 Since dot supports UTF-8, I would expect this to work.  
 
 I'm unsure if this is a bug in the graphviz plugin, or in the perl module it depends upon, but figured I would start here. 
+
+> This reminds me of [[bugs/table can not deal with Chinese ]] *—[[Jon]], 2020-11-02*

feedback
diff --git a/doc/todo/commandline_comment_moderation.mdwn b/doc/todo/commandline_comment_moderation.mdwn
index a72fb31b2..9cf233151 100644
--- a/doc/todo/commandline_comment_moderation.mdwn
+++ b/doc/todo/commandline_comment_moderation.mdwn
@@ -103,3 +103,12 @@ the comment. The default (`i`) is to ignore the comment.
 I find that this is generally faster than going through a web browser, although to be as fast as the CGI interface, there would need to be a final dialog that says "delete all ignored comments" like in the CGI. Exercise for the reader or, I guess, myself when I got too many junk comments to process...
 
 Feedback, as usual, welcome. -- [[anarcat]]
+
+> great stuff, thanks! I've got a similar-ish script that sends me an email summary, but I don't
+> have the CLI stuff myself. What I'd like to see on the web form is: display the IP (or user)
+> responsible for each comment and enable banning them at the same time as moderating the comment.
+> However I'd also like to expand the data attached to the banlist, so it's clear *why* an entry
+> was added (e.g. blog spam), and when — because I would prefer all such bans to be time limited.
+> (implementation wise, this might be easiest achieved if one of the comment plugins was responsible
+> for maintaining a separate data structure with this info which was processed into a ban list to
+> append to the main one.) *—[[Jon]], 2020-11-02*

diff --git a/doc/bugs/meta_directive_with_multiple_authors/discussion.mdwn b/doc/bugs/meta_directive_with_multiple_authors/discussion.mdwn
new file mode 100644
index 000000000..b9bc0cffb
--- /dev/null
+++ b/doc/bugs/meta_directive_with_multiple_authors/discussion.mdwn
@@ -0,0 +1 @@
+Interestingly it does seem to generate the correct HTML, it is just internal uses of the flags like pagespecs that seem not to work. 

diff --git a/doc/bugs/graphviz_wide_characters.mdwn b/doc/bugs/graphviz_wide_characters.mdwn
index 905d5ca6a..9e0844857 100644
--- a/doc/bugs/graphviz_wide_characters.mdwn
+++ b/doc/bugs/graphviz_wide_characters.mdwn
@@ -7,4 +7,4 @@ If you include a wide character, such as a fancy quote, in a [[graphviz|plugins/
 Note, this is what renders on the resulting wiki page, not something that you see on the command line. 
 Since dot supports UTF-8, I would expect this to work.  
 
-I'm unsure if this is a bug in the graphviz plugin, or in the perl module it depends upon, but since the graphviz pugin seems to be perl5‽ I figured I would start by reporting the problem here, on the assumption that the older perl was less likely to handle UTF-8. 
+I'm unsure if this is a bug in the graphviz plugin, or in the perl module it depends upon, but figured I would start here. 

diff --git a/doc/bugs/meta_directive_with_multiple_authors.mdwn b/doc/bugs/meta_directive_with_multiple_authors.mdwn
new file mode 100644
index 000000000..c79f94b51
--- /dev/null
+++ b/doc/bugs/meta_directive_with_multiple_authors.mdwn
@@ -0,0 +1,20 @@
+Some wiki pages have multiple authors.  It seems logical that you would use multiple meta directives to mark this,
+
+```
+\[[!meta author="author one"]]
+\[[!meta author="other author"]]
+```
+
+however, when you do this, it appears that things that key off of the author tag only pick up on the last instance of the directive. for example a page spec looking for 
+
+```
+author(author one)
+```
+
+will not match while one looking for
+
+```
+author(other author)
+```
+
+will match.  I would expect that both would match. 

diff --git a/doc/bugs/graphviz_wide_characters.mdwn b/doc/bugs/graphviz_wide_characters.mdwn
new file mode 100644
index 000000000..905d5ca6a
--- /dev/null
+++ b/doc/bugs/graphviz_wide_characters.mdwn
@@ -0,0 +1,10 @@
+If you include a wide character, such as a fancy quote, in a [[graphviz|plugins/graphviz]] source file for use with the file parameter to the graph directive, you get the following error:
+
+```
+[[!graph Error: Wide character in subroutine entry at /usr/share/perl5/IkiWiki/Plugin/graphviz.pm line 57.]]
+```
+
+Note, this is what renders on the resulting wiki page, not something that you see on the command line. 
+Since dot supports UTF-8, I would expect this to work.  
+
+I'm unsure if this is a bug in the graphviz plugin, or in the perl module it depends upon, but since the graphviz pugin seems to be perl5‽ I figured I would start by reporting the problem here, on the assumption that the older perl was less likely to handle UTF-8. 

reply, request patch, remove patch tag
diff --git a/doc/todo/support_Twitter_cards.mdwn b/doc/todo/support_Twitter_cards.mdwn
index 886cb1abd..c02ed6d38 100644
--- a/doc/todo/support_Twitter_cards.mdwn
+++ b/doc/todo/support_Twitter_cards.mdwn
@@ -10,4 +10,11 @@ Twitter is not really picky about HTML and actually parses `<meta>` tags outside
 
 That's what I did on the [donation page of Tails](https://gitlab.tails.boum.org/tails/tails/-/commit/6dbde9fa926e574b3bab4170caf65fe3c394fe48) for now.
 
-[[!tag patch]]
+> Hi! Thanks for looking at this. Correct me if I misunderstand your message. I think you are saying
+> that this bug with colons remains in IkiWiki's parser, and you have not fixed that, but you have a
+> a workaround, namely putting the meta tags as HTML into the body of the page? That's a useful
+> workaround and worthy of documenting, but it's not a "patch" so I have removed the patch tag.
+> 
+> If, instead, you have actually got a patch for the IkiWiki parser, please post it and I can take a
+> look: I'm not an IkiWiki maintainer but I can review it and give my opinion at least. If that's the
+> case, please share it, and re-add `\[[!tag patch]]`. Thanks! *—[[Jon]], 2020-10-13*

link to patch
diff --git a/doc/bugs/backlinks_onhover_thing_can_go_weird.mdwn b/doc/bugs/backlinks_onhover_thing_can_go_weird.mdwn
index 327b8136b..171714b3f 100644
--- a/doc/bugs/backlinks_onhover_thing_can_go_weird.mdwn
+++ b/doc/bugs/backlinks_onhover_thing_can_go_weird.mdwn
@@ -47,3 +47,7 @@ further down the list, but of course then you are outside the hover region.
 >> <details><summary>example</summary>here's an example</details>
 >> The above works for me on ikiwiki.info which does not have `html5:1`
 >> so far as I can tell *— [[Jon]], 2020-04-21*
+
+>>> [[!tag patch]]Patch in my repo, commit f051f84f632c3eaf86c5cff172692ce71ad5375d.
+>>> [[!template id=gitbranch branch=jon/more-backlinks-html5-use-details-tag author="[[Jon]]"]]
+>>> (I must say this looks *much* nicer, IMHO) *—[[Jon]], 2020-10-07*

link to sparate bug page and patch
diff --git a/doc/bugs/html5_time_element__39__s_pubdate_wrong_when_using_xhtml5___34__mode__34__.mdwn b/doc/bugs/html5_time_element__39__s_pubdate_wrong_when_using_xhtml5___34__mode__34__.mdwn
index 1bda7e5f4..c451ac4a5 100644
--- a/doc/bugs/html5_time_element__39__s_pubdate_wrong_when_using_xhtml5___34__mode__34__.mdwn
+++ b/doc/bugs/html5_time_element__39__s_pubdate_wrong_when_using_xhtml5___34__mode__34__.mdwn
@@ -22,7 +22,9 @@ The pubdate REQUIRES a date, so e.g. `pubdate="2009-03-24T18:02:14Z"`
 >>>>> `Error: Attribute pubdate not allowed on element time at this point.`
 >>>> *— [[Jon]], 2020-10-05*
 
-
+>>>>> I've filed a separate bug page for this, since this one is already
+>>>>> marked *done*: [[bugs/pubdate_not_valid_for_html5]]. I've filed a
+>>>>> patch.  *—[[Jon]], 2020-10-06*
 
 Otherwise the XML parser chokes.
 

anonymous git push broken again
diff --git a/doc/bugs/anonymous_git_push_broken_again.mdwn b/doc/bugs/anonymous_git_push_broken_again.mdwn
new file mode 100644
index 000000000..9ef21d66a
--- /dev/null
+++ b/doc/bugs/anonymous_git_push_broken_again.mdwn
@@ -0,0 +1,10 @@
+This might not be the same cause or solution as [[git_test_receive_wrapper_fails]] so filing
+it separately.
+
+Anon git push is broken again
+
+    remote: error: cannot lock ref 'HEAD': Unable to create '/home/b-ikiwiki/source.git/./HEAD.lock': Permission denied
+    To git://git.ikiwiki.info/
+     ! [remote rejected]     master -> master (failed to update ref)
+
+*—[[Jon]], 2020-10-06*

pubdate not valid for html5
diff --git a/doc/bugs/pubdate_not_valid_for_html5.mdwn b/doc/bugs/pubdate_not_valid_for_html5.mdwn
new file mode 100644
index 000000000..4b55cc928
--- /dev/null
+++ b/doc/bugs/pubdate_not_valid_for_html5.mdwn
@@ -0,0 +1,9 @@
+The `pubdate` attribute is not valid for modern HTML(5).
+
+The [h-entry microformat](http://microformats.org/wiki/h-entry) describes
+an alternative way to achieve the same thing: a `dt-published` class name.
+
+Patch: <https://github.com/jmtd/ikiwiki/commit/a137103d3004cc8cec42459205684ec48af0ca11>
+[[!tag patch]]
+[[!template id=gitbranch branch=jon/html5-no-pubdate-attribute author="[[Jon]]"]]
+*—[[Jon]], 2020-10-06*

a call to arms wrt HTML4, 5 and templates
diff --git a/doc/bugs/flip_html5_default_to_1__44___and_clean_up_templates.mdwn b/doc/bugs/flip_html5_default_to_1__44___and_clean_up_templates.mdwn
new file mode 100644
index 000000000..15bd0c605
--- /dev/null
+++ b/doc/bugs/flip_html5_default_to_1__44___and_clean_up_templates.mdwn
@@ -0,0 +1,10 @@
+Is it perhaps time to flip the default for the `html5` to `1`? What criteria should be used to answer that question?
+With [[smcv]]'s last major change in this area, back in 2014, the market share of IE8 and earlier was a concern at
+5%. What is the equivalent market share today?
+
+The templates are still a real complex mess of branches around this configuration option. I'd love to see all that
+branching removed. Would anyone else? A hypothetical future html4 option/plugin could work by post-processing the
+generated output and replacing the troublesome tag names (via XSLT perhaps, depending on tooling). Is there any
+appetite for this?
+
+*—[[Jon]], 2020-10-05*

respond re pubdate attribute
diff --git a/doc/bugs/html5_time_element__39__s_pubdate_wrong_when_using_xhtml5___34__mode__34__.mdwn b/doc/bugs/html5_time_element__39__s_pubdate_wrong_when_using_xhtml5___34__mode__34__.mdwn
index 228847b4a..1bda7e5f4 100644
--- a/doc/bugs/html5_time_element__39__s_pubdate_wrong_when_using_xhtml5___34__mode__34__.mdwn
+++ b/doc/bugs/html5_time_element__39__s_pubdate_wrong_when_using_xhtml5___34__mode__34__.mdwn
@@ -13,8 +13,16 @@ The pubdate REQUIRES a date, so e.g. `pubdate="2009-03-24T18:02:14Z"`
 >>>
 >>> Posted &lt;time datetime="2007-12-06T05:00:00Z" pubdate="pubdate"&gt;Thu 06 Dec 2007 12:00:00 AM EST&lt;/time&gt;
 >>>
->>> which shows up as an error on https://validator.w3.org/ --Luke Schierer
- 
+>>> which shows up as an error on https://validator.w3.org/ --Luke Schierer 
+
+>>>> My reading of Joey's response, above, was that (according to the spec at the time), `pubdate="pubdate"` is what
+>>>> should be generated, *not* `pubdate="timestamp"`, and so what you are seeing is expected. However, looking at
+>>>> the *current* Spec (linked elsewhere in this page), `pubdate` is not actually a valid attribute any more at
+>>>> all. And indeed, running my own blog through the Validator, I see:
+>>>>> `Error: Attribute pubdate not allowed on element time at this point.`
+>>>> *— [[Jon]], 2020-10-05*
+
+
 
 Otherwise the XML parser chokes.
 

Testing. Added a link to the Wikipedia article of ikiwiki :)
diff --git a/doc/sandbox.mdwn b/doc/sandbox.mdwn
index 34d4c2c06..acf53e6a8 100644
--- a/doc/sandbox.mdwn
+++ b/doc/sandbox.mdwn
@@ -24,7 +24,8 @@ List:
 [[!meta date="Thu Jun 16 22:04:33 2005" updated="Thu Dec 22 01:23:20 2011"]]
 
 This is the [[SandBox]], a page anyone can edit to try out ikiwiki
-(version [[!version  ]]).
+(version [[!version  ]]). Ikiwiki described on Wikipedia: [[!wikipedia Ikiwiki]].
+
 vvvv
 CamelCase ?
 

diff --git a/doc/bugs/html5_time_element__39__s_pubdate_wrong_when_using_xhtml5___34__mode__34__.mdwn b/doc/bugs/html5_time_element__39__s_pubdate_wrong_when_using_xhtml5___34__mode__34__.mdwn
index 16be643cf..228847b4a 100644
--- a/doc/bugs/html5_time_element__39__s_pubdate_wrong_when_using_xhtml5___34__mode__34__.mdwn
+++ b/doc/bugs/html5_time_element__39__s_pubdate_wrong_when_using_xhtml5___34__mode__34__.mdwn
@@ -10,8 +10,10 @@ The pubdate REQUIRES a date, so e.g. `pubdate="2009-03-24T18:02:14Z"`
 > --[[Joey]] 
 >> awesome, thanks for fixing my fix ;) --[[simonraven]]
 >>> This seems to be happening either still or again with version 3.20200202.3-1. I'm getting strings generated like
->>> Posted <time datetime="2007-12-06T05:00:00Z" pubdate="pubdate">Thu 06 Dec 2007 12:00:00 AM EST</time>
->>> which shows up as an error on https://validator.w3.org/
+>>>
+>>> Posted &lt;time datetime="2007-12-06T05:00:00Z" pubdate="pubdate"&gt;Thu 06 Dec 2007 12:00:00 AM EST&lt;/time&gt;
+>>>
+>>> which shows up as an error on https://validator.w3.org/ --Luke Schierer
  
 
 Otherwise the XML parser chokes.

diff --git a/doc/bugs/html5_time_element__39__s_pubdate_wrong_when_using_xhtml5___34__mode__34__.mdwn b/doc/bugs/html5_time_element__39__s_pubdate_wrong_when_using_xhtml5___34__mode__34__.mdwn
index def5bcc2a..16be643cf 100644
--- a/doc/bugs/html5_time_element__39__s_pubdate_wrong_when_using_xhtml5___34__mode__34__.mdwn
+++ b/doc/bugs/html5_time_element__39__s_pubdate_wrong_when_using_xhtml5___34__mode__34__.mdwn
@@ -9,6 +9,10 @@ The pubdate REQUIRES a date, so e.g. `pubdate="2009-03-24T18:02:14Z"`
 > No, `pubdate="pubdate"`. It's a boolean attribute. applied && [[done]]
 > --[[Joey]] 
 >> awesome, thanks for fixing my fix ;) --[[simonraven]]
+>>> This seems to be happening either still or again with version 3.20200202.3-1. I'm getting strings generated like
+>>> Posted <time datetime="2007-12-06T05:00:00Z" pubdate="pubdate">Thu 06 Dec 2007 12:00:00 AM EST</time>
+>>> which shows up as an error on https://validator.w3.org/
+ 
 
 Otherwise the XML parser chokes.
 

diff --git a/doc/ikiwiki/directive/linkmap/discussion.mdwn b/doc/ikiwiki/directive/linkmap/discussion.mdwn
new file mode 100644
index 000000000..47a182e07
--- /dev/null
+++ b/doc/ikiwiki/directive/linkmap/discussion.mdwn
@@ -0,0 +1 @@
+I would [[like|wishlist]] to be able to create a link map of a PageSpec defined in another directive without having to manually keep the two PageSpecs in sync.  Having a way to name a PageSpec and then a parameter on the linkmap directive to pull in that named PageSpec. 

diff --git a/doc/todo/support_Twitter_cards.mdwn b/doc/todo/support_Twitter_cards.mdwn
index 4b14c97a9..886cb1abd 100644
--- a/doc/todo/support_Twitter_cards.mdwn
+++ b/doc/todo/support_Twitter_cards.mdwn
@@ -9,3 +9,5 @@ Disclaimer: I don't know anything about Perl or the internals of ikiwiki but I m
 Twitter is not really picky about HTML and actually parses `<meta>` tags outside of the `<head>` section, so there's currently a workaround.
 
 That's what I did on the [donation page of Tails](https://gitlab.tails.boum.org/tails/tails/-/commit/6dbde9fa926e574b3bab4170caf65fe3c394fe48) for now.
+
+[[!tag patch]]

diff --git a/doc/todo/support_Twitter_cards.mdwn b/doc/todo/support_Twitter_cards.mdwn
new file mode 100644
index 000000000..4b14c97a9
--- /dev/null
+++ b/doc/todo/support_Twitter_cards.mdwn
@@ -0,0 +1,11 @@
+[Twitter cards](https://developer.twitter.com/en/docs/twitter-for-websites/cards/overview/summary-card-with-large-image) work by using `<meta>` tags with names that include a colon: `twitter:card`, `twitter:site`, `twitter:creator`, etc.
+
+The current parsing of ikiwiki's directive doesn't support using colons in names.
+
+This patch fixes it.
+
+Disclaimer: I don't know anything about Perl or the internals of ikiwiki but I managed to "make it work". It might still be flawed in many ways.
+
+Twitter is not really picky about HTML and actually parses `<meta>` tags outside of the `<head>` section, so there's currently a workaround.
+
+That's what I did on the [donation page of Tails](https://gitlab.tails.boum.org/tails/tails/-/commit/6dbde9fa926e574b3bab4170caf65fe3c394fe48) for now.

diff --git a/doc/recentchanges.mdwn b/doc/recentchanges.mdwn
new file mode 100644
index 000000000..3383fc703
--- /dev/null
+++ b/doc/recentchanges.mdwn
@@ -0,0 +1,7 @@
+[[!if test="enabled(meta)" then="""
+[[!meta title="RecentChanges"]]
+"""]]
+Recent changes to this wiki:
+
+[[!inline pages="internal(recentchanges/change_*) and !*/Discussion" 
+template=recentchanges show=0]]

Added a comment: A thousand pardons
diff --git a/doc/forum/Tried_to_change_Title_of_my_blog/comment_2_0dcd34762cbc939efe2c6b8a31049dd7._comment b/doc/forum/Tried_to_change_Title_of_my_blog/comment_2_0dcd34762cbc939efe2c6b8a31049dd7._comment
new file mode 100644
index 000000000..b24d2c1e6
--- /dev/null
+++ b/doc/forum/Tried_to_change_Title_of_my_blog/comment_2_0dcd34762cbc939efe2c6b8a31049dd7._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="bob@62bd4985e23588dbe194f982ff54f0326f98fd4a"
+ nickname="bob"
+ avatar="http://cdn.libravatar.org/avatar/b1caeabc4608b4fab2f47295d60127b7"
+ subject="A thousand pardons"
+ date="2020-09-07T02:10:37Z"
+ content="""
+Sorry for any inconvenience my confusion may have spawned, but the dogs may be called off as I have decided to Move On from this patch of bad road and create a new blog from scratch. The longer I worked on the one so resistant to title-change the more I seemed to recall that I had changed its title at least once in the past, and may not have used the The Marquess of Queensberry Rules for ikiwiki title changes on those occasions. Happy Labor Day Everyone!
+"""]]

Added a comment: Oops!
diff --git a/doc/forum/Tried_to_change_Title_of_my_blog/comment_1_e55a8547c743a43e487c7e77ff52bf03._comment b/doc/forum/Tried_to_change_Title_of_my_blog/comment_1_e55a8547c743a43e487c7e77ff52bf03._comment
new file mode 100644
index 000000000..de73ac499
--- /dev/null
+++ b/doc/forum/Tried_to_change_Title_of_my_blog/comment_1_e55a8547c743a43e487c7e77ff52bf03._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="bob@62bd4985e23588dbe194f982ff54f0326f98fd4a"
+ nickname="bob"
+ avatar="http://cdn.libravatar.org/avatar/b1caeabc4608b4fab2f47295d60127b7"
+ subject="Oops!"
+ date="2020-09-06T20:31:07Z"
+ content="""
+Should read: \"not changed were any FILES named index.html...\"
+"""]]

diff --git a/doc/forum/Tried_to_change_Title_of_my_blog.mdwn b/doc/forum/Tried_to_change_Title_of_my_blog.mdwn
new file mode 100644
index 000000000..f737a516a
--- /dev/null
+++ b/doc/forum/Tried_to_change_Title_of_my_blog.mdwn
@@ -0,0 +1,7 @@
+Changed the title in Preferences and followed Setup's suggestion that I rebuild blog.
+
+Not changed were any pages titled 'index.html' either in top level directory, or individual Posts' directories.
+
+Signed,
+
+Puzzled in New England

diff --git a/doc/install.mdwn b/doc/install.mdwn
index 7b768a61e..48c11272b 100644
--- a/doc/install.mdwn
+++ b/doc/install.mdwn
@@ -34,7 +34,7 @@ CPAN to install modules from your local machine after you extract the ikiwiki ta
 
 Then to build and install ikiwiki:
 
-	perl Makefile.PL # PREFIX=/dir to install elsewhere
+	perl Makefile.PL # INSTALL_BASE= PREFIX=/dir to install elsewhere
 	make
 	make test # optional
 	make install

diff --git a/doc/setup/discussion.mdwn b/doc/setup/discussion.mdwn
index bdb76513c..dbcf204e9 100644
--- a/doc/setup/discussion.mdwn
+++ b/doc/setup/discussion.mdwn
@@ -5,6 +5,7 @@ Apache log doesn't say anything more than the html reply:
 "Error message:
 End of script output before headers: ikiwiki.cgi"
 
+---
 
 
 I have copied over the ikiwiki.setup file from /usr/share/doc/ikiwiki/ to /etc/ikiwiki/ and run it after editing. My site gets built but when I click on the 'edit' button, firefox and google chrome download the cgi file instead of creating a way to edit it. The permissions on my ikiwiki.cgi script look like this: -rwsr-sr-x  1 root root 13359 2009-10-13 19:21 ikiwiki.cgi. Is there something I should do, i.e. change permissions, so I can get it to run correctly? (jeremiah)

diff --git a/doc/setup/discussion.mdwn b/doc/setup/discussion.mdwn
index 645656b24..bdb76513c 100644
--- a/doc/setup/discussion.mdwn
+++ b/doc/setup/discussion.mdwn
@@ -1,3 +1,12 @@
+Getting 500 error after new install in localhost/~home dir. Have ExecCGI/mod_cgi, setuid exec and owner is apache user, apache is running.
+
+Apache log doesn't say anything more than the html reply:
+
+"Error message:
+End of script output before headers: ikiwiki.cgi"
+
+
+
 I have copied over the ikiwiki.setup file from /usr/share/doc/ikiwiki/ to /etc/ikiwiki/ and run it after editing. My site gets built but when I click on the 'edit' button, firefox and google chrome download the cgi file instead of creating a way to edit it. The permissions on my ikiwiki.cgi script look like this: -rwsr-sr-x  1 root root 13359 2009-10-13 19:21 ikiwiki.cgi. Is there something I should do, i.e. change permissions, so I can get it to run correctly? (jeremiah)
 
 > Have a look [[here|tips/dot_cgi]]. --[[Jogo]]

tag properly
diff --git a/doc/bugs/javascript_resources_placed_after_html_tag.mdwn b/doc/bugs/javascript_resources_placed_after_html_tag.mdwn
index 23f832fdb..71dcac710 100644
--- a/doc/bugs/javascript_resources_placed_after_html_tag.mdwn
+++ b/doc/bugs/javascript_resources_placed_after_html_tag.mdwn
@@ -65,3 +65,6 @@ I think the simplest solution is to add a newline when we add the javascript blo
 Sorry for the trouble, HTH! :)
 
 PS: Note that it seems like browsers are happy to ignore the spec and load stuff outside of the `<html>` tag, thankfully. So this is mostly a cosmetic/conformity thing...
+
+
+[[!tag patch]]

diff --git a/doc/todo/add_geo_uri_scheme.mdwn b/doc/todo/add_geo_uri_scheme.mdwn
index 3144d943a..5491dbb6e 100644
--- a/doc/todo/add_geo_uri_scheme.mdwn
+++ b/doc/todo/add_geo_uri_scheme.mdwn
@@ -1,6 +1,6 @@
 [[!template  id=gitbranch branch=anarcat/geo-scheme author="[[anarcat]]"]]
 
-Trivial patch to add the `geo:` URI scheme:
+Trivial [[!taglink patch]] to add the `geo:` URI scheme:
 
 [[!format diff """
 modified   IkiWiki/Plugin/htmlscrubber.pm

diff --git a/doc/todo/add_geo_uri_scheme.mdwn b/doc/todo/add_geo_uri_scheme.mdwn
new file mode 100644
index 000000000..3144d943a
--- /dev/null
+++ b/doc/todo/add_geo_uri_scheme.mdwn
@@ -0,0 +1,20 @@
+[[!template  id=gitbranch branch=anarcat/geo-scheme author="[[anarcat]]"]]
+
+Trivial patch to add the `geo:` URI scheme:
+
+[[!format diff """
+modified   IkiWiki/Plugin/htmlscrubber.pm
+@@ -25,8 +25,8 @@ sub import {
+ 		"sip", "sips", "snmp", "tel", "urn", "wais", "xmpp",
+ 		"z39.50r", "z39.50s",
+ 		# Selected unofficial schemes
+-		"aim", "callto", "cvs", "ed2k", "feed", "fish", "gg",
+-		"irc", "ircs", "lastfm", "ldaps", "magnet", "mms",
++		"aim", "callto", "cvs", "ed2k", "feed", "fish", "geo",
++		"gg", "irc", "ircs", "lastfm", "ldaps", "magnet", "mms",
+ 		"msnim", "notes", "rsync", "secondlife", "skype", "ssh",
+ 		"sftp", "smb", "sms", "snews", "webcal", "ymsgr",
+ 		"bitcoin", "git", "svn", "bzr", "darcs", "hg"
+"""]]
+
+-- [[anarcat]]

what I meant
diff --git a/doc/todo/admonitions.mdwn b/doc/todo/admonitions.mdwn
index 63894002a..c68ce11f8 100644
--- a/doc/todo/admonitions.mdwn
+++ b/doc/todo/admonitions.mdwn
@@ -142,3 +142,10 @@ in either case (which will at least mean there'll be another avenue for people t
 > > Thanks for your support and comments! :) I don't have the time to manage another extra branch on top of the stack I already have unfortunately. but it might be simpler for me in the future... I keep on hoping all patches get merged and that i don't need to (more officially) fork `master`, but it seems that's where I need to go myself... In the meantime you can see the list of patches I maintain in [[users/anarcat]] and [my maintenance log](https://anarc.at/services/wiki/). I hope that helps! -- [[anarcat]]
 
 > > Turns out I found the time. I merged all my active branches in the `master` branch on gitlab. not sure what you'd compare it against, but there, it's done. :) [[anarcat]]
+
+>>> Thanks for that! I'll try to explain what I meant in terms of an example. your `admonitions` is  a series of commits that ultimately sit on top of
+>>> upstream's `d0099568` ("Prepare release for unstable"). If I want to see a quick combined diff of all the changes made in that branch, I can try to
+>>> use GitLab's "Compare" feature, but it does not let me specify a SHA to compare against, only a ref-name such as (your) `master`, which (at the time)
+>>> was a much earlier commit than `d0099568`, so "Compare" would include all the unrelated upstream changes. If instead either `master` was `d0099568`, or
+>>> `admonitions` was rebased on top of whatever your `master` was, then GitLab's "Compare" would be useful. As it is, I cloned locally and did the necessary
+>>> `git` incantation. *— [[Jon]], 2020-08-12*

diff --git a/doc/todo/admonitions.mdwn b/doc/todo/admonitions.mdwn
index af52f8aad..63894002a 100644
--- a/doc/todo/admonitions.mdwn
+++ b/doc/todo/admonitions.mdwn
@@ -140,3 +140,5 @@ in either case (which will at least mean there'll be another avenue for people t
 > feature in-browser to see a combined diff of your changes.  *— [[Jon]], 2020-08-07*
 
 > > Thanks for your support and comments! :) I don't have the time to manage another extra branch on top of the stack I already have unfortunately. but it might be simpler for me in the future... I keep on hoping all patches get merged and that i don't need to (more officially) fork `master`, but it seems that's where I need to go myself... In the meantime you can see the list of patches I maintain in [[users/anarcat]] and [my maintenance log](https://anarc.at/services/wiki/). I hope that helps! -- [[anarcat]]
+
+> > Turns out I found the time. I merged all my active branches in the `master` branch on gitlab. not sure what you'd compare it against, but there, it's done. :) [[anarcat]]

no time to do maser for now, but some pointers and thanks
diff --git a/doc/todo/admonitions.mdwn b/doc/todo/admonitions.mdwn
index ef1c53dad..af52f8aad 100644
--- a/doc/todo/admonitions.mdwn
+++ b/doc/todo/admonitions.mdwn
@@ -138,3 +138,5 @@ in either case (which will at least mean there'll be another avenue for people t
 > One quick tip/request, [[anarcat]]: If you could update the "master" branch in your IkiWiki
 > fork to match the merge base for your branches, it would be easy to use Gitlab's "compare"
 > feature in-browser to see a combined diff of your changes.  *— [[Jon]], 2020-08-07*
+
+> > Thanks for your support and comments! :) I don't have the time to manage another extra branch on top of the stack I already have unfortunately. but it might be simpler for me in the future... I keep on hoping all patches get merged and that i don't need to (more officially) fork `master`, but it seems that's where I need to go myself... In the meantime you can see the list of patches I maintain in [[users/anarcat]] and [my maintenance log](https://anarc.at/services/wiki/). I hope that helps! -- [[anarcat]]

suggestion for anarcat :)
diff --git a/doc/todo/admonitions.mdwn b/doc/todo/admonitions.mdwn
index 65bb530e7..ef1c53dad 100644
--- a/doc/todo/admonitions.mdwn
+++ b/doc/todo/admonitions.mdwn
@@ -134,3 +134,7 @@ admonition styles in either `style.css` or in every shipped theme. But I'm more
 and your current plugin actually exists and IkiWiki is starving for contributors (IMHO)
 so I encourage maintainers to merge it. I will probably merge it into [opinionated ikiwiki](https://jmtd.net/log/opinionated_ikiwiki/)
 in either case (which will at least mean there'll be another avenue for people to check it out)  *— [[Jon]], 2020-08-07*
+
+> One quick tip/request, [[anarcat]]: If you could update the "master" branch in your IkiWiki
+> fork to match the merge base for your branches, it would be easy to use Gitlab's "compare"
+> feature in-browser to see a combined diff of your changes.  *— [[Jon]], 2020-08-07*

I like it, I encourage it to be merged.
diff --git a/doc/todo/admonitions.mdwn b/doc/todo/admonitions.mdwn
index 50f62bf3d..65bb530e7 100644
--- a/doc/todo/admonitions.mdwn
+++ b/doc/todo/admonitions.mdwn
@@ -123,3 +123,14 @@ screenshot of what the help page would look like, to give you an idea
 of the results:
 
 <img src="http://paste.anarc.at/snaps/snap-2016.04.15-18.07.39.png" />
+
+---
+
+I like the idea of admonitions. I've done something vaguely similar on my own site ([e.g.](https://jmtd.net/film/blade_runner/)), but I just
+use `\[[!template` and put up with the verbosity.I like that `\[[!tip` is shorter than `\[[!template id=…`. If
+I was being a total purist I'd argue that the correct change would be to make a syntax shortcut
+for the template syntax, since functionally that's what `tip` is doing, and include the
+admonition styles in either `style.css` or in every shipped theme. But I'm more of a pragmatist
+and your current plugin actually exists and IkiWiki is starving for contributors (IMHO)
+so I encourage maintainers to merge it. I will probably merge it into [opinionated ikiwiki](https://jmtd.net/log/opinionated_ikiwiki/)
+in either case (which will at least mean there'll be another avenue for people to check it out)  *— [[Jon]], 2020-08-07*

me too
diff --git a/doc/todo/include_page_variable_in_base_templates.mdwn b/doc/todo/include_page_variable_in_base_templates.mdwn
index 9e4a6dc36..1aed79683 100644
--- a/doc/todo/include_page_variable_in_base_templates.mdwn
+++ b/doc/todo/include_page_variable_in_base_templates.mdwn
@@ -36,3 +36,12 @@ Thanks!
 PS: I think it would be great if we had a way to figure out which variables are available in a template... I couldn't find out how to do that in HTML::Template, and wonder if we could have some way to do that, to ease such diagnostics in the future...
 
 [[!tag patch]]
+
+---
+
+you're not alone: I think this is very similar to [[forum/how_to_put_a_permalink_on_each_post]].
+
+> PS: I think it would be great if we had a way to figure out which variables are available in a template
+
+I agree! Perhaps a subroutine that enumerated them all and a plugin to expose it or something.
+I definitely wold find that useful too. *­— [[Jon]], 2020-07-21*

describe simplified solution for simplified scenario.
diff --git a/doc/todo/git-annex_support.mdwn b/doc/todo/git-annex_support.mdwn
index f1a4e787c..992c5a294 100644
--- a/doc/todo/git-annex_support.mdwn
+++ b/doc/todo/git-annex_support.mdwn
@@ -242,3 +242,8 @@ This [[!taglink patch]] still applies - anything else I should be doing here to
 > > No problem at all, glad that you still have that in the queue, and I hope
 > > my work was somewhat useful in pushing this forward! Thanks for taking
 > > care of the Imagetragick situation... :/ --[[anarcat]]
+
+Yet another option
+==================
+
+If you happen to use rsync to deploy, instead of git, this is [much easier](https://www.cs.unb.ca/~bremner/blog/posts/big-files).

seems like i screwed up javascript loading
diff --git a/doc/bugs/javascript_resources_placed_after_html_tag.mdwn b/doc/bugs/javascript_resources_placed_after_html_tag.mdwn
new file mode 100644
index 000000000..23f832fdb
--- /dev/null
+++ b/doc/bugs/javascript_resources_placed_after_html_tag.mdwn
@@ -0,0 +1,67 @@
+[[!template  id=gitbranch branch=anarcat/js-newline author="[[anarcat]]"]]
+
+I am not sure why -- it may be [[my fault|todo/fix_javascript_load_ordering]] -- but it seems like plugins loads there Javascript resources *after* the `<body>` and `<html>` tags are closed. Here's an example from [my sandbox](https://anarc.at/sandbox/):
+
+    <script src="../ikiwiki/ikiwiki.js" type="text/javascript" charset="utf-8"></script>
+    <script src="../ikiwiki/relativedate.js" type="text/javascript" charset="utf-8"></script>  </body>
+    </html>
+    <script src="/ikiwiki/ikiwiki.js" type="text/javascript" charset="utf-8"></script>
+    <script src="/ikiwiki/toggle.js" type="text/javascript" charset="utf-8"></script>
+
+Here, `toggle.js` appaars after the `<html>` tag! Interestingly, this is not specific to that one plugin: the same thing happens, in reverse, in my [recent changes page](https://anarc.at/recentchanges/):
+
+    <script src="../ikiwiki/ikiwiki.js" type="text/javascript" charset="utf-8"></script>
+    <script src="../ikiwiki/toggle.js" type="text/javascript" charset="utf-8"></script>  </body>
+    </html>
+    <script src="/ikiwiki/ikiwiki.js" type="text/javascript" charset="utf-8"></script>
+    <script src="/ikiwiki/relativedate.js" type="text/javascript" charset="utf-8"></script>
+
+I am not sure what determines the order in the end.
+
+I'm not sure what's going on, but it seems like the second time a `include_javascript`-like pattern is used, it fails to detect the `</body>` tag and appends the resources at the end instead. That could be because the `</body>` tag is not alone on its own line, which is actually fine in terms of comformity but confuses the regex...
+
+I think the simplest solution is to add a newline when we add the javascript blob, to keep the assertion that body is on its own line. I have done so in the aforementioned patch, which is reproduced here for simplicty:
+
+    diff --git a/IkiWiki/Plugin/recentchangesdiff.pm b/IkiWiki/Plugin/recentchangesdiff.pm
+    index 0093c655e..ac8a61895 100644
+    --- a/IkiWiki/Plugin/recentchangesdiff.pm
+    +++ b/IkiWiki/Plugin/recentchangesdiff.pm
+    @@ -60,7 +60,7 @@ sub pagetemplate (@) {
+     sub format (@) {
+             my %params=@_;
+     
+    -	if (! ($params{content}=~s!^(\s*</body[^>]*>)!include_javascript($params{page}).$1!em)) {
+    +	if (! ($params{content}=~s!^(\s*</body[^>]*>)!include_javascript($params{page})."\n".$1!em)) {
+     		# no <body> tag, probably in preview mode
+     		$params{content}=$params{content}.include_javascript(undef);
+     	}
+    diff --git a/IkiWiki/Plugin/relativedate.pm b/IkiWiki/Plugin/relativedate.pm
+    index 083966ad2..1ef6b2e2a 100644
+    --- a/IkiWiki/Plugin/relativedate.pm
+    +++ b/IkiWiki/Plugin/relativedate.pm
+    @@ -26,7 +26,7 @@ sub getsetup () {
+     sub format (@) {
+             my %params=@_;
+     
+    -	if (! ($params{content}=~s!^(\s*</body[^>]*>)!include_javascript($params{page}).$1!em)) {
+    +	if (! ($params{content}=~s!^(\s*</body[^>]*>)!include_javascript($params{page})."\n".$1!em)) {
+     		# no <body> tag, probably in preview mode
+     		$params{content}=$params{content}.include_javascript(undef);
+     	}
+    diff --git a/IkiWiki/Plugin/toggle.pm b/IkiWiki/Plugin/toggle.pm
+    index eea6e8861..9f74f6029 100644
+    --- a/IkiWiki/Plugin/toggle.pm
+    +++ b/IkiWiki/Plugin/toggle.pm
+    @@ -68,7 +68,7 @@ sub format (@) {
+     
+     	if ($params{content}=~s!(<div class="toggleable(?:-open)?" id="[^"]+">\s*)</div>!$1!g) {
+     		$params{content}=~s/<div class="toggleableend">//g;
+    -		if (! ($params{content}=~s!^(\s*</body[^>]*>)!include_javascript($params{page}).$1!em)) {
+    +		if (! ($params{content}=~s!^(\s*</body[^>]*>)!include_javascript($params{page})."\n".$1!em)) {
+     			# no <body> tag, probably in preview mode
+     			$params{content}=$params{content}.include_javascript(undef);
+     		}
+
+Sorry for the trouble, HTH! :)
+
+PS: Note that it seems like browsers are happy to ignore the spec and load stuff outside of the `<html>` tag, thankfully. So this is mostly a cosmetic/conformity thing...

why do not we have the page path in the template variables?
diff --git a/doc/todo/include_page_variable_in_base_templates.mdwn b/doc/todo/include_page_variable_in_base_templates.mdwn
new file mode 100644
index 000000000..9e4a6dc36
--- /dev/null
+++ b/doc/todo/include_page_variable_in_base_templates.mdwn
@@ -0,0 +1,38 @@
+[[!template  id=gitbranch branch=anarcat/page-template-variable author="[[anarcat]]"]]
+
+I do not understand why, but it seems like base templates included in the theme do not have access to the current page path. All sorts of plugins give all sorts of information about the page including its title, modification time, related pages (trail and parentlinks), tags, fields and so on... But *nothing* on just that: the page path.
+
+It's a one-line patch to fix:
+
+    modified   IkiWiki/Render.pm
+    @@ -123,6 +123,7 @@ sub genpage ($$) {
+     	}
+     
+     	$template->param(
+    +		page => $page,
+     		title => $page eq 'index' 
+     			? $config{wikiname} 
+     			: pagetitle(basename($page)),
+
+
+The patch is available in my git repo, and also directly visible here:
+
+https://gitlab.com/anarcat/ikiwiki/-/commit/9b471a6adcdf47e98dbe3a3aae68f3da4ab63fbb
+
+I use this to include the page name in a tracking URL for (privacy-friendly) web analytics, thanks to Goatcounter. But it seems like a useful thing in general: for example, I remember a friend struggling to figure out how to theme the frontpage of his wiki differently, and he spent a long trying to figure out this very problem. I have myself spent about an hour scouring the source code before deciding the variable just did not exist. 
+
+The friend ended up using this construction instead:
+
+    <TMPL_UNLESS PARENTLINKS>
+      <link rel="stylesheet" href="css/style-frontpage.css" />
+    </TMPL_UNLESS>
+
+... which might actually be more elegant, but way less flexible: what if you want to theme another page that way? In other words, the above only works for the frontpage, but maybe you want `/sales` to be themed differently than `/sandbox`...
+
+In general, I think this is a minor change that can have a huge impact on the themability of ikiwiki, if we care about that at all. ;)
+
+Thanks!
+
+PS: I think it would be great if we had a way to figure out which variables are available in a template... I couldn't find out how to do that in HTML::Template, and wonder if we could have some way to do that, to ease such diagnostics in the future...
+
+[[!tag patch]]

wikilink table directive and plugin
diff --git a/doc/bugs/the_data_argument_for_the_table_directive_should_follow_linking_rules.mdwn b/doc/bugs/the_data_argument_for_the_table_directive_should_follow_linking_rules.mdwn
index 7463dbf19..a97a592b2 100644
--- a/doc/bugs/the_data_argument_for_the_table_directive_should_follow_linking_rules.mdwn
+++ b/doc/bugs/the_data_argument_for_the_table_directive_should_follow_linking_rules.mdwn
@@ -1 +1 @@
-when using the table directive with the table plugin, if I use the data argument to specify a file as a source of the data, I currently have to give a full path from the root of the wiki to the file.  I should be able to give just the file name and have the file located using the same rules that are followed when creating wiki links.  
+when using the [[table directive|ikiwiki/directive/table]] with the [[table plugin|plugins/table]], if I use the data argument to specify a file as a source of the data, I currently have to give a full path from the root of the wiki to the file.  I should be able to give just the file name and have the file located using the same rules that are followed when creating wiki links.  

diff --git a/doc/bugs/the_data_argument_for_the_table_directive_should_follow_linking_rules.mdwn b/doc/bugs/the_data_argument_for_the_table_directive_should_follow_linking_rules.mdwn
new file mode 100644
index 000000000..7463dbf19
--- /dev/null
+++ b/doc/bugs/the_data_argument_for_the_table_directive_should_follow_linking_rules.mdwn
@@ -0,0 +1 @@
+when using the table directive with the table plugin, if I use the data argument to specify a file as a source of the data, I currently have to give a full path from the root of the wiki to the file.  I should be able to give just the file name and have the file located using the same rules that are followed when creating wiki links.  

still an issue
diff --git a/doc/bugs/table_can_not_deal_with_Chinese_.mdwn b/doc/bugs/table_can_not_deal_with_Chinese_.mdwn
index f115fbebb..e57bd3c05 100644
--- a/doc/bugs/table_can_not_deal_with_Chinese_.mdwn
+++ b/doc/bugs/table_can_not_deal_with_Chinese_.mdwn
@@ -137,3 +137,8 @@ I'm going to attempt to work around it by moving to an external CSV. ­— [[Jon
 >> libtext-csv-xs-perl	1.38-1. Further fiddling will commence.
 >> (removing libtext-csv-xs-perl does not help.)
 — [[Jon]]
+
+>>> Still hitting this [[plugins/table]] bug, using ikiwiki=3.20200202.3, buster system, no libtext-csv-perl installed,
+>>> libperl5.28:amd64       5.28.1-6, no libtext-csv-xs-perl. Workaround is to set format=tsv,
+>>> even though I'm overriding the delimiter to \t. This reproduces easily in the  quay.io/jdowland/opinionated-ikiwiki
+>>> container FWIW. *— [[Jon]], 2020-06-26*

how to use dumpsetup
diff --git a/doc/usage/discussion.mdwn b/doc/usage/discussion.mdwn
index c96059683..9fd6ab36e 100644
--- a/doc/usage/discussion.mdwn
+++ b/doc/usage/discussion.mdwn
@@ -1,3 +1,5 @@
 Man page does not document "account\_creation\_password". I started to add it, then noticed other configurations are not documented in the manual page either. --[[JeremyReed]]
 
 The description of "--dumpsetup" says that it dumps the current configuration. For me, it always dumps the same blank/initial/default configuration. For example, "wikiname" is always "wiki". This is after changing my setup file and running ikiwiki --setup. FWIW ...--[[KarlBerry]]
+
+> You need to use `--dumpsetup` at the same time as specifying your setup, i.e. `ikiwiki --setup input-setup-file --dumpsetup output-setup-file`, or `ikiwiki [ configuration flags on command line instead of setup file ] --dumpsetup output-setup` *— [[Jon]] 2020-06-23*

diff --git a/doc/forum/backslash_and_other_unusual_characters_in_page_names.mdwn b/doc/forum/backslash_and_other_unusual_characters_in_page_names.mdwn
new file mode 100644
index 000000000..4984d63e5
--- /dev/null
+++ b/doc/forum/backslash_and_other_unusual_characters_in_page_names.mdwn
@@ -0,0 +1,20 @@
+Is there a way to support backslash or other "unusual" characters in
+the output .html names?
+
+I added `\\` to wiki_file_chars (not just `\` since this value is
+the contents of a Perl [...] regexp, per
+IkiWiki.pm). But doing this and then creating a file \foo.mdwn on the
+source side is not enough, because the backslash is autotranslated to /
+(for the sake of Windows I suppose), resulting in
+http://example.org//foo/.
+
+I'm looking to make a TeX-related wiki. Hence having backslash as a
+normal character is desirable. I know there would be plenty more complications,
+but, just exploring the options ...
+
+Generalizing from backslashes, is there a way to control the mapping
+from .mdwn names to the output .html names (and directories I guess),
+apart from the specific usedirs and indexpages settings?
+
+I've glanced through plugins and done a bunch of web searches without
+any success. Any help appreciated. Thanks. --[[KarlBerry]]