Recent changes to this wiki:

diff --git a/doc/sandbox.mdwn b/doc/sandbox.mdwn
index 732bda2e0..7a755ee02 100644
--- a/doc/sandbox.mdwn
+++ b/doc/sandbox.mdwn
@@ -79,11 +79,11 @@ testing markdown
     b. bar
 
 | table | here |
-|----|.----.|
+|----| ---- |
 | test adfasdfasdfa | 2 |
 | subtest | adfad|
 
-ok no formating.
+Sort of formatted.. No borders, though.
 
 
 > This is a blockquote.

link to the ordering patch
diff --git a/doc/todo/css_and_javascript_aggregation.mdwn b/doc/todo/css_and_javascript_aggregation.mdwn
index 2a8e54ded..4b3e5f766 100644
--- a/doc/todo/css_and_javascript_aggregation.mdwn
+++ b/doc/todo/css_and_javascript_aggregation.mdwn
@@ -11,12 +11,12 @@ I'd love to do that. Since latency here is high, it would drastically cut down o
 
 Another recommendation of the test is to "Inline small JavaScript", saying that `toggle.js`  have a "small response bodies". "Inlining the response in HTML can reduce blocking of page rendering." And indeed, toggle.js is pretty small... It could easily be included in the page instead of added as a link.
 
-Finally, another problem that occurs in my case, but somehow not on ikiwiki.info, is that the Javascript show up completely on top of the page. I looked at how the plugins include the javascript code, and it looks like the `<body>` regex simply doesn't match, something I'll need to look into. But it would be better if those would be appended to the document instead of prefix'd, as a fallback. I'll file that as a separate patch.
+Finally, another problem that occurs in my case, but somehow not on ikiwiki.info, is that the Javascript show up completely on top of the page. I looked at how the plugins include the javascript code, and it looks like the `<body>` regex simply doesn't match, something I'll need to look into. But it would be better if those would be appended to the document instead of prefix'd, as a fallback. I filed that as a [[separate patch|todo/fix_javascript_load_ordering]].
 
 In general, I feel it would be useful for plugins to have a hook to register CSS files, and make ikiwiki aggregate those! It would allow for deduplication between resources (e.g. ikiwiki.js gets inclued twice now, even on ikiwiki.info) and (optionally) aggregation in a single file.
 
-Since this is core functionality, it can hardly be done without touching the core. I think this would need a new hook and could be kept opt-in, to keep smaller sites simple... But I would like to know if this is a possibility that was considered before hacking at this problem further.
+Since this is core functionality, it can hardly be done without touching the core. I think this would need a new hook and could be kept opt-in, to keep smaller sites simple... But I would like to know if this is a possibility that was considered before hacking at this problem further. I'd be happy to give it a shot, but I am worried about other patches I have sitting in the queue and don't want to waste too much energy to pile another one on top. :)
 
-Alternatively, I guess it *could* be possible to have a format plugin that would *parse* the HTML page, extract CSS and JS resources and replace them with an aggregated copy, but that seems like a really crude hack.
+Alternatively, I guess it *could* be possible to have a format plugin that would *parse* the HTML page, extract CSS and JS resources and replace them with an aggregated copy, but that seems like a really crude hack. Furthermore, there are many different ways Javascript is included into the page right now, and it is not done consistently. For example, [[plugins/osm]] includes it near the end of the page while [[plugins/toggle]] includes it on top, with different regexes that do not match the same way and break differently. Refactoring this would help in making the code more maintainable...
 
 Thanks! --[[anarcat]]

propose a javascript optimization
diff --git a/doc/todo/fix_javascript_load_ordering.mdwn b/doc/todo/fix_javascript_load_ordering.mdwn
new file mode 100644
index 000000000..6a4e15ff2
--- /dev/null
+++ b/doc/todo/fix_javascript_load_ordering.mdwn
@@ -0,0 +1,20 @@
+[[!tag patch]]
+[[!template  id=gitbranch branch=anarcat/reverse-js-includes author="[[users/anarcat]]"]]
+
+As mentioned in [[todo/css_and_javascript_aggregation]] the current
+ordering of Javascript files in [[plugins/toggle]],
+[[plugins/relativedate]] and [[plugins/recentchangesdiff]] is
+incorrect: Javascript files get loaded before the main content and may
+even be loaded before the `<html>` tag for templates that indent the
+`<body>` tag with whitespace.
+
+According to the [best practices](https://developers.google.com/speed/docs/insights/mobile#PutStylesBeforeScripts) Javascript resources should be
+presented to browsers after CSS, and "after the fold" (ATF) according
+to the best practices. This allows the browser to download Javascript
+files in parallel.
+
+I have pushed a [simple patch](https://gitlab.com/anarcat/ikiwiki/commit/5caf6e1f87530dda74ec23eb1fa7120309607cc8) which fixes this issue by including
+Javascript on the *closing* `</body>` tag instead of the *opening* tag.
+
+It also improves the regex to tolerate spaces before the `</body>` tag,
+as some templates have (proper) indentation for the tag.

optimization proposal
diff --git a/doc/todo/css_and_javascript_aggregation.mdwn b/doc/todo/css_and_javascript_aggregation.mdwn
new file mode 100644
index 000000000..2a8e54ded
--- /dev/null
+++ b/doc/todo/css_and_javascript_aggregation.mdwn
@@ -0,0 +1,22 @@
+One of the goals of using a static site generator like ikiwiki, for me, is not only future-proofing and portability, but also performance. By having a small set of HTML pages with a minimal theme, we can deliver raw content much faster than a traditional CMS. This does not, however, keep us from doing optimizations that those same CMS must do in order to deliver good page performance.
+
+Take, for example, this [performance report of the main ikiwiki site](https://gtmetrix.com/reports/ikiwiki.info/rwUIfK6d). For a very minimal site, it is still making 8 requests and taking ~700ms to load. That's quite fast, but it could probably be cut down to 400ms if CSS and JS were aggregated. If you look at [my homepage](https://gtmetrix.com/reports/anarc.at/uAkMmZaT) the results are worse, because I have larger JS and CSS files: the impact is therefore much bigger and we're looking at 2000ms load times. (Obviously, part of the problem here is the slowness of the uplink here, but one could argue the same problem would occur for downstream users that have a slower connexion.)
+
+One of the recommendations "YSlow" is giving is "Make fewer HTTP requests":
+
+ * This page has 5 external Javascript scripts. Try combining them into one.
+ * This page has 4 external stylesheets. Try combining them into one.
+
+I'd love to do that. Since latency here is high, it would drastically cut down on the load time of the page. But I can't: Ikiwiki decides how those resources get included...
+
+Another recommendation of the test is to "Inline small JavaScript", saying that `toggle.js`  have a "small response bodies". "Inlining the response in HTML can reduce blocking of page rendering." And indeed, toggle.js is pretty small... It could easily be included in the page instead of added as a link.
+
+Finally, another problem that occurs in my case, but somehow not on ikiwiki.info, is that the Javascript show up completely on top of the page. I looked at how the plugins include the javascript code, and it looks like the `<body>` regex simply doesn't match, something I'll need to look into. But it would be better if those would be appended to the document instead of prefix'd, as a fallback. I'll file that as a separate patch.
+
+In general, I feel it would be useful for plugins to have a hook to register CSS files, and make ikiwiki aggregate those! It would allow for deduplication between resources (e.g. ikiwiki.js gets inclued twice now, even on ikiwiki.info) and (optionally) aggregation in a single file.
+
+Since this is core functionality, it can hardly be done without touching the core. I think this would need a new hook and could be kept opt-in, to keep smaller sites simple... But I would like to know if this is a possibility that was considered before hacking at this problem further.
+
+Alternatively, I guess it *could* be possible to have a format plugin that would *parse* the HTML page, extract CSS and JS resources and replace them with an aggregated copy, but that seems like a really crude hack.
+
+Thanks! --[[anarcat]]

diff --git a/doc/users/111.html b/doc/users/111.html
new file mode 100644
index 000000000..6fcc215b1
--- /dev/null
+++ b/doc/users/111.html
@@ -0,0 +1,2 @@
+# 22222222222222222222222222222
+<b>xxx</b>

diff --git a/doc/users/111.mdwn b/doc/users/111.mdwn
new file mode 100644
index 000000000..58c9bdf9d
--- /dev/null
+++ b/doc/users/111.mdwn
@@ -0,0 +1 @@
+111

file bug
diff --git a/doc/bugs/Broken_links_in_e-mail_notifications_when_using_RSS_syndication.mdwn b/doc/bugs/Broken_links_in_e-mail_notifications_when_using_RSS_syndication.mdwn
new file mode 100644
index 000000000..016874744
--- /dev/null
+++ b/doc/bugs/Broken_links_in_e-mail_notifications_when_using_RSS_syndication.mdwn
@@ -0,0 +1,9 @@
+Ikiwki sends me page change notifications like this:
+
+> A change has been made to <http://joeyh.name/devblog/git-annex_devblog/day_423__ssh_fun/>
+
+This links to a page that says: "The page ?day 423 ssh fun does not exist."
+
+The problem is caused because Joey's devblog includes posts syndicated from his git-annex devblog.
+
+Either the notification e-mails should use the URL of the syndicated post, like <http://git-annex.branchable.com/devblog/day_423__ssh_fun/> or the URL for the post on joey.name should redirect to the git-annex devblog post.

formatting
diff --git a/doc/bugs/Unable_to_access_pagespec_preferences_on_https:__47____47__joeyh.name__47__.mdwn b/doc/bugs/Unable_to_access_pagespec_preferences_on_https:__47____47__joeyh.name__47__.mdwn
index 86bbd5121..28535845a 100644
--- a/doc/bugs/Unable_to_access_pagespec_preferences_on_https:__47____47__joeyh.name__47__.mdwn
+++ b/doc/bugs/Unable_to_access_pagespec_preferences_on_https:__47____47__joeyh.name__47__.mdwn
@@ -1,5 +1,5 @@
-On the https://joeyh.name/ ikiwiki preference page I added an e-mail subscription PageSpec. Now when I view the preference page the PageSpec is empty, but I'm still getting e-mails.
+On the <https://joeyh.name/> ikiwiki preference page I added an e-mail subscription [[PageSpec|ikiwiki/pagespec]]. Now when I view the preference page the PageSpec field is empty, but I'm still getting e-mails.
 
 My guess at the cause of the problem is that I created an account using the e-mail login, then registered another account with a username. I think now when I login via either method I'm accessing the account with a username, while the e-mail only account has the PageSpec for the subscription.
 
-The e-mail notifications including a link to http://joeyh.name/ikiwiki.cgi?do=prefs but they could include a login token so I can access the page and edit the PageSpec.
+The e-mail notifications including a link to <http://joeyh.name/ikiwiki.cgi?do=prefs> but they could include a login token so I can access the page and edit the PageSpec.

file bug
diff --git a/doc/bugs/Unable_to_access_pagespec_preferences_on_https:__47____47__joeyh.name__47__.mdwn b/doc/bugs/Unable_to_access_pagespec_preferences_on_https:__47____47__joeyh.name__47__.mdwn
new file mode 100644
index 000000000..86bbd5121
--- /dev/null
+++ b/doc/bugs/Unable_to_access_pagespec_preferences_on_https:__47____47__joeyh.name__47__.mdwn
@@ -0,0 +1,5 @@
+On the https://joeyh.name/ ikiwiki preference page I added an e-mail subscription PageSpec. Now when I view the preference page the PageSpec is empty, but I'm still getting e-mails.
+
+My guess at the cause of the problem is that I created an account using the e-mail login, then registered another account with a username. I think now when I login via either method I'm accessing the account with a username, while the e-mail only account has the PageSpec for the subscription.
+
+The e-mail notifications including a link to http://joeyh.name/ikiwiki.cgi?do=prefs but they could include a login token so I can access the page and edit the PageSpec.

file bug
diff --git a/doc/bugs/Login_should_redirect_to_secure_version_of_site.mdwn b/doc/bugs/Login_should_redirect_to_secure_version_of_site.mdwn
new file mode 100644
index 000000000..7c2c501b7
--- /dev/null
+++ b/doc/bugs/Login_should_redirect_to_secure_version_of_site.mdwn
@@ -0,0 +1,9 @@
+Steps to reproduce:
+
+1. visit an ikiwki site like <http://ikiwiki.info/> or <http://git-annex.branchable.com/>
+2. trigger the login page by accessing preferences or trying to edit something
+3. login page is served without encryption
+
+Firefox gives all kinds of warnings for unencrypted login pages.
+
+The fix is for the login page to redirect to the https version of the wiki before showing the login form.

Revert spam edits.
diff --git a/doc/index.mdwn b/doc/index.mdwn
index de411c74b..0122e489c 100644
--- a/doc/index.mdwn
+++ b/doc/index.mdwn
@@ -1,5 +1,3 @@
-Hello,
-
 Ikiwiki is a **wiki compiler**. It converts wiki pages into HTML pages
 suitable for publishing on a website. Ikiwiki stores pages and history in a
 [[revision_control_system|rcs]] such as [[Subversion|rcs/svn]] or [[rcs/Git]].

diff --git a/doc/index.mdwn b/doc/index.mdwn
index 84816d376..de411c74b 100644
--- a/doc/index.mdwn
+++ b/doc/index.mdwn
@@ -1,4 +1,4 @@
-
+Hello,
 
 Ikiwiki is a **wiki compiler**. It converts wiki pages into HTML pages
 suitable for publishing on a website. Ikiwiki stores pages and history in a

diff --git a/doc/index.mdwn b/doc/index.mdwn
index 6ba6f5057..84816d376 100644
--- a/doc/index.mdwn
+++ b/doc/index.mdwn
@@ -1,4 +1,4 @@
-Hello TwCbe,
+
 
 Ikiwiki is a **wiki compiler**. It converts wiki pages into HTML pages
 suitable for publishing on a website. Ikiwiki stores pages and history in a

diff --git a/doc/index.mdwn b/doc/index.mdwn
index e0e401656..6ba6f5057 100644
--- a/doc/index.mdwn
+++ b/doc/index.mdwn
@@ -1,4 +1,4 @@
-[[!template id=links]]
+Hello TwCbe,
 
 Ikiwiki is a **wiki compiler**. It converts wiki pages into HTML pages
 suitable for publishing on a website. Ikiwiki stores pages and history in a

Announce version 3.20171001
diff --git a/doc/news/version_3.20161229.mdwn b/doc/news/version_3.20161229.mdwn
deleted file mode 100644
index 365cb69d1..000000000
--- a/doc/news/version_3.20161229.mdwn
+++ /dev/null
@@ -1,23 +0,0 @@
-ikiwiki 3.20161229 released with [[!toggle text="these changes"]]
-[[!toggleable text="""
-   * Security: force CGI::FormBuilder-&gt;field to scalar context where
-     necessary, avoiding unintended function argument injection
-     analogous to [[!debcve CVE-2014-1572]]. In ikiwiki this could be used to
-     forge commit metadata, but thankfully nothing more serious.
-     ([[!debcve CVE-2016-9646]])
-   * Security: try revert operations in a temporary working tree before
-     approving them. Previously, automatic rename detection could result in
-     a revert writing outside the wiki srcdir or altering a file that the
-     reverting user should not be able to alter, an authorization bypass.
-     ([[!debcve CVE-2016-10026]] represents the original vulnerability.)
-     The incomplete fix released in 3.20161219 was not effective for git
-     versions prior to 2.8.0rc0.
-     ([[!debcve CVE-2016-9645]] represents that incomplete solution.)
-   * Add CVE references for CVE-2016-10026
-   * Add automated test for using the CGI with git, including
-     CVE-2016-10026
-     - Build-depend on libipc-run-perl for better build-time test coverage
-   * Add missing ikiwiki.setup for the manual test for CVE-2016-10026
-   * git: don't issue a warning if the rcsinfo CGI parameter is undefined
-   * git: do not fail to commit changes with a recent git version
-     and an anonymous committer"""]]
diff --git a/doc/news/version_3.20171001.mdwn b/doc/news/version_3.20171001.mdwn
new file mode 100644
index 000000000..3d51b8776
--- /dev/null
+++ b/doc/news/version_3.20171001.mdwn
@@ -0,0 +1,23 @@
+ikiwiki 3.20171001 released with [[!toggle text="these changes"]]
+[[!toggleable text="""
+ * [ [[Joey Hess|joey]] ]
+   * htmlscrubber: Add support for the video tag's `loop` and `muted`
+     attributes. Those were not in the original html5 spec, but have been
+     added in the whatwg html living standard and have wide browser support.
+   * emailauth, passwordauth: Avoid leaving `cgisess_*` files in the
+     system temp directory.
+ * [ [[Simon McVittie|smcv]] ]
+   * core: Don't decode the result of `strftime` if it is already tagged as
+     UTF-8, as it might be since Perl &gt;= 5.21.1. (Closes: #[869240](http://bugs.debian.org/869240))
+   * img: Strip metadata from resized images when the deterministic config
+     option is set. Thanks, [[intrigeri]]
+   * receive: Avoid `asprintf()` in `IkiWiki::Receive`, to avoid implicit
+     declaration, potential misbehaviour on 64-bit platforms, and lack
+     of portability to non-GNU platforms
+   * t: Add a regression test for untrusted git push
+   * receive: Fix untrusted git push with git (&gt;= 2.11) by passing through
+     the necessary environment variables to make the quarantine area work
+   * debian: Declare compliance with Debian Policy 4.1.1
+ * [ [[Amitai Schleier|schmonz]] ]
+   * l10n: Fix the build with po4a 0.52, by ensuring that `msgstr` ends
+     with a newline if and only if `msgid` does"""]]

Update changelog and close bug
diff --git a/debian/changelog b/debian/changelog
index f8ee1827d..eb2b2cefb 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -10,6 +10,8 @@ ikiwiki (3.20170623) UNRELEASED; urgency=medium
   [ Simon McVittie ]
   * core: Don't decode the result of strftime if it is already tagged as
     UTF-8, as it might be since Perl >= 5.21.1. (Closes: #869240)
+  * Strip metadata from resized images when the deterministic config
+    option is set. Thanks, intrigeri
 
   [ Amitai Schleier ]
   * Fix the build with po4a 0.52
diff --git a/doc/bugs/images_resizing_is_not_deterministic.mdwn b/doc/bugs/images_resizing_is_not_deterministic.mdwn
index d17679eaa..1f964f4bf 100644
--- a/doc/bugs/images_resizing_is_not_deterministic.mdwn
+++ b/doc/bugs/images_resizing_is_not_deterministic.mdwn
@@ -11,4 +11,6 @@ succeeds with the branch merged).
 
 --[[intrigeri]]
 
+> Thanks, [[merged|done]] --[[smcv]]
+
 [[!tag patch]]

diff --git a/doc/sandbox.mdwn b/doc/sandbox.mdwn
index a9065ffc9..732bda2e0 100644
--- a/doc/sandbox.mdwn
+++ b/doc/sandbox.mdwn
@@ -216,6 +216,10 @@ Räksmörgås.
 `pre?`
 
 Testing. Test. 試験として書き込みします。
+ℜ𝔢𝔞𝔩𝔩𝔶 𝔠𝔬𝔬𝔩 𝔣𝔬𝔫𝔱, 𝔪𝔞𝔫. 
+𝕀𝕗 𝕥𝕙𝕒𝕥'𝕤 𝕨𝕙𝕒𝕥 𝕪𝕠𝕦'𝕣𝕖 𝕚𝕟𝕥𝕠,
+𝓟𝓮𝓻𝓼𝓸𝓷𝓪𝓵𝓵𝔂, 𝓘 𝓵𝓲𝓴𝓮 𝓪 𝓫𝓲𝓽 𝓸𝓯 𝓼𝓽𝔂𝓵𝓮. 𝓐𝓷𝓭 𝓬𝓵𝓪𝓼𝓼.
+𝕭𝖚𝖙 𝕴 𝖉𝖔𝖓'𝖙 𝖍𝖆𝖛𝖊 𝖆 𝖇𝖚𝖌 𝖆𝖇𝖔𝖚𝖙 𝖎𝖙.
 
 Καλημέρα!
 

diff --git a/doc/plugins/theme/discussion.mdwn b/doc/plugins/theme/discussion.mdwn
index e58fe47b5..0550e565b 100644
--- a/doc/plugins/theme/discussion.mdwn
+++ b/doc/plugins/theme/discussion.mdwn
@@ -31,3 +31,7 @@ Choose one of the [[themes]] which are bundled with ikiwiki and configure ikiwik
 So I added "theme" to my config file's "add_plugins" directive, and uncommented the "theme: actiontabs" line.  I then ran "ikwiki --setup wiki.setup" and...  no change on reload.
 
 I'm on Ubuntu 16.04.  Any idea what I'm doing wrong?  --[[STrRedWolf]]
+
+### my theming issue solved.
+
+take a look at [How to use themes?](http://ikiwiki.info/forum/How_to_use_themes__63__/) --[[azzamsa]]

diff --git a/doc/users/azzamsa.mdwn b/doc/users/azzamsa.mdwn
new file mode 100644
index 000000000..14bb34114
--- /dev/null
+++ b/doc/users/azzamsa.mdwn
@@ -0,0 +1 @@
+I am azzamsa

Added a comment: my issue solved
diff --git a/doc/forum/How_to_use_themes__63__/comment_4_842fa45466edbcdedf86a77422d05920._comment b/doc/forum/How_to_use_themes__63__/comment_4_842fa45466edbcdedf86a77422d05920._comment
new file mode 100644
index 000000000..7014c7076
--- /dev/null
+++ b/doc/forum/How_to_use_themes__63__/comment_4_842fa45466edbcdedf86a77422d05920._comment
@@ -0,0 +1,25 @@
+[[!comment format=mdwn
+ username="azzamsa"
+ avatar="http://cdn.libravatar.org/avatar/892d91822e06b494931e82a1ec0f1eb7"
+ subject="my issue solved"
+ date="2017-09-06T07:09:20Z"
+ content="""
+Hy. STrRedWolf, does your problem already solved ?
+
+- I can't change my themes too, I have uncommented #theme = value, but nothing change. 
+- I also have add --rebuild parameter, but nothing change too.
+
+this morning, after long holiday, I came to ikiwiki and solved it after reading [this](https://wiki.math.cmu.edu/iki/wiki/tips/20140720-ikiwiki-navbar.html), he said \"**(Be sure to also enable the theme plugin.)**\",  no one said this before in other tutorial, so I add `-theme` in plugin section and it solved :).
+
+```
+ #plugins to add to the default configuration
+add_plugins:
+- goodstuff
+- websetup
+- theme
+```
+
+now my wiki online using actiontabs theme.
+
+have nice day!. hope it help others.
+"""]]

Report bug + merge request: image resize is not deterministic.
diff --git a/doc/bugs/images_resizing_is_not_deterministic.mdwn b/doc/bugs/images_resizing_is_not_deterministic.mdwn
new file mode 100644
index 000000000..d17679eaa
--- /dev/null
+++ b/doc/bugs/images_resizing_is_not_deterministic.mdwn
@@ -0,0 +1,14 @@
+Hi!
+
+While working on Reproducible Builds for Tails, we noticed that
+the img plugin's output is not deterministic: PNG images embed
+timestamps.
+
+The `img-determinism` branch in the
+`https://git-tails.immerda.ch/ikiwiki.git` Git repository has a fix
+for this problem + a new test (that fails without this change, and
+succeeds with the branch merged).
+
+--[[intrigeri]]
+
+[[!tag patch]]

Added a comment: Reposted question on unix.sx
diff --git a/doc/forum/Using_ikiwiki_via_command_line:_Workflow_and_permission_problem/comment_1_e9ce22ec0157565d09add95b4ec280a0._comment b/doc/forum/Using_ikiwiki_via_command_line:_Workflow_and_permission_problem/comment_1_e9ce22ec0157565d09add95b4ec280a0._comment
new file mode 100644
index 000000000..8ddeaaba4
--- /dev/null
+++ b/doc/forum/Using_ikiwiki_via_command_line:_Workflow_and_permission_problem/comment_1_e9ce22ec0157565d09add95b4ec280a0._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="anna19"
+ avatar="http://cdn.libravatar.org/avatar/b3f002ce89e03b09a075c02dc511241f"
+ subject="Reposted question on unix.sx"
+ date="2017-08-28T15:49:15Z"
+ content="""
+Since there was no response on this for a year now and because I relly need help with this, I reposted (a part) of the question on https://unix.stackexchange.com/questions/388870/using-ikiwiki-via-command-line-workflow-and-permission-problem
+"""]]

removed
diff --git a/doc/bugs/Encoding_problems_in_ikiwiki_generated_content.mdwn b/doc/bugs/Encoding_problems_in_ikiwiki_generated_content.mdwn
deleted file mode 100644
index 1b15480..0000000
--- a/doc/bugs/Encoding_problems_in_ikiwiki_generated_content.mdwn
+++ /dev/null
@@ -1,8 +0,0 @@
-ikiwiki version 3.20170111 on  Debian 4.9.30-2+deb9u3 with locale fr_FR.UTF-8
-
-UTF-8 characters like û and é get turned into the unicode replacement character (xFFFD) in "Last edited" date, "published" date and in the calendar plugin content.
-User provided content (page title or content) isn't affected.
-
-Examples [here](https://blog.chat-porc.eu/archives/2017/)
-
-Having strftime_utf8 systematically return POSIX::strftime(@_) resolves the bug, but I'm pretty sure it's not a proper fix.

diff --git a/doc/bugs/Encoding_problems_in_ikiwiki_generated_content.mdwn b/doc/bugs/Encoding_problems_in_ikiwiki_generated_content.mdwn
index aa6b139..1b15480 100644
--- a/doc/bugs/Encoding_problems_in_ikiwiki_generated_content.mdwn
+++ b/doc/bugs/Encoding_problems_in_ikiwiki_generated_content.mdwn
@@ -3,6 +3,6 @@ ikiwiki version 3.20170111 on  Debian 4.9.30-2+deb9u3 with locale fr_FR.UTF-8
 UTF-8 characters like û and é get turned into the unicode replacement character (xFFFD) in "Last edited" date, "published" date and in the calendar plugin content.
 User provided content (page title or content) isn't affected.
 
-Examples here : https://blog.chat-porc.eu/archives/2017/
+Examples [here](https://blog.chat-porc.eu/archives/2017/)
 
 Having strftime_utf8 systematically return POSIX::strftime(@_) resolves the bug, but I'm pretty sure it's not a proper fix.

diff --git a/doc/bugs/Encoding_problems_in_ikiwiki_generated_content.mdwn b/doc/bugs/Encoding_problems_in_ikiwiki_generated_content.mdwn
new file mode 100644
index 0000000..aa6b139
--- /dev/null
+++ b/doc/bugs/Encoding_problems_in_ikiwiki_generated_content.mdwn
@@ -0,0 +1,8 @@
+ikiwiki version 3.20170111 on  Debian 4.9.30-2+deb9u3 with locale fr_FR.UTF-8
+
+UTF-8 characters like û and é get turned into the unicode replacement character (xFFFD) in "Last edited" date, "published" date and in the calendar plugin content.
+User provided content (page title or content) isn't affected.
+
+Examples here : https://blog.chat-porc.eu/archives/2017/
+
+Having strftime_utf8 systematically return POSIX::strftime(@_) resolves the bug, but I'm pretty sure it's not a proper fix.

Clarify how to use sorting
diff --git a/doc/ikiwiki/pagespec/sorting.mdwn b/doc/ikiwiki/pagespec/sorting.mdwn
index 0c6cc74..9173ab5 100644
--- a/doc/ikiwiki/pagespec/sorting.mdwn
+++ b/doc/ikiwiki/pagespec/sorting.mdwn
@@ -1,7 +1,7 @@
 Some [[directives|ikiwiki/directive]] that use
 [[PageSpecs|ikiwiki/pagespec]] allow
 specifying the order that matching pages are shown in. The following sort
-orders can be specified.
+orders can be specified using the `sort` parameter:
 
 * `age` - List pages from the most recently created to the oldest.
 

diff --git a/doc/setup.mdwn b/doc/setup.mdwn
index c6005fb..9fc37c0 100644
--- a/doc/setup.mdwn
+++ b/doc/setup.mdwn
@@ -7,7 +7,9 @@ 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 [[Docker image|https://github.com/elecnix/ikiwiki-docker]] with ikiwiki pre-installed.
+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
+for the wiki content.
 
 ## Create your wiki
 

diff --git a/doc/setup/discussion.mdwn b/doc/setup/discussion.mdwn
index 7ab9351..645656b 100644
--- a/doc/setup/discussion.mdwn
+++ b/doc/setup/discussion.mdwn
@@ -269,3 +269,6 @@ Well it should be similar to shared hosting [or a remote server in general](http
 
 ----
 Perhaps it's worth noting that when installing ikiwiki with apt on Debian stable, you need to use the backports version in order to follow the setup instructions.
+
+---
+The mentioned docker image does not seem to be supported anymore. For those interested I've setup another docker image here on [[github|https://github.com/dgsb/docker-ikiwiki]] and here on [[docker hub|https://hub.docker.com/r/dgsb/ikiwiki/]]. It has the advantage of not being sandboxed and using a local repository through a volume to setup the content of the wiki. A ssh server is also started in order to push/pull to/from the container -- David

diff --git a/doc/bugs/forced_description_in_ikiwiki.mdwn b/doc/bugs/forced_description_in_ikiwiki.mdwn
new file mode 100644
index 0000000..a44d926
--- /dev/null
+++ b/doc/bugs/forced_description_in_ikiwiki.mdwn
@@ -0,0 +1,9 @@
+Hello.
+
+I would like to be able to enable the description of the change to no longer being optional but forced instead simply, when enabled, change to ikiwiki cannot be approved without description (commit message).
+
+I was not able to find it or google it.
+
+Please add such option if it is not in ikiwiki already.
+
+Thank you very much.

Added a comment
diff --git a/doc/forum/An_assets_directory_for_my_wiki_with_git_lfs_or_annex__63__/comment_4_ea2c347eaeafe51736d64f28a426630c._comment b/doc/forum/An_assets_directory_for_my_wiki_with_git_lfs_or_annex__63__/comment_4_ea2c347eaeafe51736d64f28a426630c._comment
new file mode 100644
index 0000000..3ac6be2
--- /dev/null
+++ b/doc/forum/An_assets_directory_for_my_wiki_with_git_lfs_or_annex__63__/comment_4_ea2c347eaeafe51736d64f28a426630c._comment
@@ -0,0 +1,45 @@
+[[!comment format=mdwn
+ username="smcv"
+ avatar="http://cdn.libravatar.org/avatar/0ee943fe632ff995f6f0f25b7167d03b"
+ subject="comment 4"
+ date="2017-07-23T18:02:29Z"
+ content="""
+> Understand what actually is an underlay directory: As far as I can tell this is simply a directory which is 1. not in the git repo 2. added to the wiki before compilation.
+
+Yes. Almost every ikiwiki site is configured to use the basewiki underlay,
+`/usr/share/ikiwiki/basewiki` or similar, which contains things like
+the default `style.css` and `ikiwiki/formatting.mdwn`. You can add more
+underlays, and they behave a bit like a
+[union mount](https://en.wikipedia.org/wiki/Union_mount): every (non-excluded)
+page or attachment found in the `srcdir` or in any underlay is used, unless
+it is masked by a page or attachment of the same name in a \"higher-level\"
+underlay. The `srcdir` is the highest level, the `basewiki` is the lowest,
+and the other underlays are stacked in between. So you'd have something like
+this:
+
+* `srcdir`
+    * `index.mdwn` is rendered as `/index.html`
+    * `photos.mdwn` is rendered as `/photos/index.html`
+* your assets directory
+    * `photos/1234.jpg` is copied to `/photos/1234.jpg`
+* ... other underlays like `javascript` ...
+* `basewiki`
+    * `style.css` is copied to `style.css`
+    * `index.mdwn` is ignored because it is masked by the one in the `srcdir`
+
+> Remove the assets directory from my ikiwki-git-repo on my local computer and on my server: In theory removing it locally should cause to be removed from the server as well, if we mean \"remove\" here in the sense of delete. However this still leaves us with a) a bloated git repo because it retains the repos history b) we need to put the assets directory somewhere safe locally before removing it from git
+
+Yes, you'd need to rebase your git history with `git filter-branch` or similar, or
+discard the history completely and re-import.
+
+> Retain the current directory structure so links won't be broken: This probably means we have to put the assets directory into the gitignore of the ikiwiki-git-repo, since we don't want to move the repo somewhere else.
+
+No, the underlay would normally be *next to* the `srcdir` rather than *inside* it,
+so there would be no need to `.gitignore` it.
+
+> Init git lfs or git annex in the assets directory, etc.: I need to start tracking my files in the assets directory with the help of one of these tools in order to ensure easy movement between my local wiki and my server wiki
+
+ikiwiki does not currently have any automation for this. You can use git-annex
+(currently only in direct mode because of the symlink check) but ikiwiki will
+not help you to sync between the local copy and the server copy.
+"""]]

Added a comment
diff --git a/doc/forum/How_to_use_themes__63__/comment_3_a830545d48e23c92966f286ef6dfd110._comment b/doc/forum/How_to_use_themes__63__/comment_3_a830545d48e23c92966f286ef6dfd110._comment
new file mode 100644
index 0000000..6c893c2
--- /dev/null
+++ b/doc/forum/How_to_use_themes__63__/comment_3_a830545d48e23c92966f286ef6dfd110._comment
@@ -0,0 +1,20 @@
+[[!comment format=mdwn
+ username="smcv"
+ avatar="http://cdn.libravatar.org/avatar/0ee943fe632ff995f6f0f25b7167d03b"
+ subject="comment 3"
+ date="2017-07-23T17:52:11Z"
+ content="""
+azzamsa: It looks as though your `gitorigin_branch` and `gitmaster_branch` settings
+might be incorrect. Set `gitorigin_branch` to be an empty string (`''`) for now.
+When you have committed the wiki content at least once, push it to the `origin`
+repository with
+
+    git push origin master
+
+then change `gitorigin_branch` back to `origin`.
+
+It might be useful to look at how `ikiwiki-makeremote` does this. In particular,
+its first commit is done during setup, contains a `.gitignore` that ignores
+the `.ikiwiki` directory, and is pushed to `origin` before running `ikiwiki`
+for the first time.
+"""]]

Added a comment
diff --git a/doc/forum/How_to_use_themes__63__/comment_2_427d16a011069e10f71f6bc3ee21fac9._comment b/doc/forum/How_to_use_themes__63__/comment_2_427d16a011069e10f71f6bc3ee21fac9._comment
new file mode 100644
index 0000000..37663ea
--- /dev/null
+++ b/doc/forum/How_to_use_themes__63__/comment_2_427d16a011069e10f71f6bc3ee21fac9._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="smcv"
+ avatar="http://cdn.libravatar.org/avatar/0ee943fe632ff995f6f0f25b7167d03b"
+ subject="comment 2"
+ date="2017-07-23T17:47:55Z"
+ content="""
+STrRedWolf: I think you need to add the `--rebuild` command-line option.
+"""]]

Added a comment
diff --git a/doc/forum/How_to_truncate_blog_posts__63__/comment_1_99c991901a45748f09ed942e46bf372d._comment b/doc/forum/How_to_truncate_blog_posts__63__/comment_1_99c991901a45748f09ed942e46bf372d._comment
new file mode 100644
index 0000000..a1a2395
--- /dev/null
+++ b/doc/forum/How_to_truncate_blog_posts__63__/comment_1_99c991901a45748f09ed942e46bf372d._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="smcv"
+ avatar="http://cdn.libravatar.org/avatar/0ee943fe632ff995f6f0f25b7167d03b"
+ subject="comment 1"
+ date="2017-07-23T17:46:36Z"
+ content="""
+The [[ikiwiki/directive/more]] directive can be used to truncate the version that
+appears in feeds and the index of blog posts. There is currently no automatic way
+to truncate to *n* words of text.
+"""]]

Added a comment: I have the same issue
diff --git a/doc/forum/How_to_use_themes__63__/comment_1_2643a5ba5155b6f5a928d70e7acb2d6a._comment b/doc/forum/How_to_use_themes__63__/comment_1_2643a5ba5155b6f5a928d70e7acb2d6a._comment
new file mode 100644
index 0000000..e058ac5
--- /dev/null
+++ b/doc/forum/How_to_use_themes__63__/comment_1_2643a5ba5155b6f5a928d70e7acb2d6a._comment
@@ -0,0 +1,22 @@
+[[!comment format=mdwn
+ username="azzamsa"
+ avatar="http://cdn.libravatar.org/avatar/892d91822e06b494931e82a1ec0f1eb7"
+ subject="I have the same issue"
+ date="2017-07-21T08:07:36Z"
+ content="""
+**need help please**
+
+I build small wiki for my school, in gntrwiki.azzamsa.com, but I can't apply themes, I have uncomment the theme: value in gntrwiki.setup, but the css file still use anti-theme value, when I copy the css file from actionstabs file it works, but the css will change to anti-theme when we do \"ikiwiki --setup gntrwiki.setup\".
+
+I have follow some tutorial on how to change ikiwiki theme, all of them have the same step, but why I can't achive this ?
+
+*NB*: I have ask this issue in irc, but no one reply. I also get this massage everythime I do \"ikiwiki --setup\" 
+```
+There are no candidates for merging among the refs that you just fetched.
+Generally this means that you provided a wildcard refspec which had no
+matches on the remote end.
+'git pull --prune origin' failed:  at /usr/share/perl5/IkiWiki/Plugin/git.pm line 251.
+```
+
+thanks lot for help, we really need this wiki to be ready soon :)
+"""]]

Q. How to truncate blog posts?
diff --git a/doc/forum/How_to_truncate_blog_posts__63__.mdwn b/doc/forum/How_to_truncate_blog_posts__63__.mdwn
new file mode 100644
index 0000000..4ed5d8d
--- /dev/null
+++ b/doc/forum/How_to_truncate_blog_posts__63__.mdwn
@@ -0,0 +1,7 @@
+Hey,
+
+I'm porting my blog from Jekyll to Ikiwiki and I'm using the default template of Ikiwiki.
+
+As some of my posts are very long it looks weird on main page at the text overflows the box. Also I don't want to show complete blog post on the main page. So, is there a method to truncate  blog posts.
+
+If I'm not clear to you, I want ikiwiki version of [this](https://stackoverflow.com/a/11044301).

answer question, with reference.
diff --git a/doc/bugs/htmlscrubber_undoes_email_obfuscation_by_Text::Markdown.mdwn b/doc/bugs/htmlscrubber_undoes_email_obfuscation_by_Text::Markdown.mdwn
index 12018d5..99cc196 100644
--- a/doc/bugs/htmlscrubber_undoes_email_obfuscation_by_Text::Markdown.mdwn
+++ b/doc/bugs/htmlscrubber_undoes_email_obfuscation_by_Text::Markdown.mdwn
@@ -35,3 +35,11 @@ The relevant commits are on the master branch of [my "fork" of ikiwiki on Github
 > 
 > It would probably be best to add an option to [[!cpan Text::Markdown]] to
 > let the email address munging be disabled. --[[Joey]]
+
+
+Email obfuscation is very useful --
+in practice, spammers apparently don't use HTML parsers --
+according to the only published study I have read
+( a 2003 study by the Center for Democracy and Technology cited by
+https://en.wikipedia.org/wiki/Address_munging
+).

Added a comment
diff --git a/doc/forum/An_assets_directory_for_my_wiki_with_git_lfs_or_annex__63__/comment_3_e42301245fb3c224a03f197557cd14ac._comment b/doc/forum/An_assets_directory_for_my_wiki_with_git_lfs_or_annex__63__/comment_3_e42301245fb3c224a03f197557cd14ac._comment
new file mode 100644
index 0000000..e743b27
--- /dev/null
+++ b/doc/forum/An_assets_directory_for_my_wiki_with_git_lfs_or_annex__63__/comment_3_e42301245fb3c224a03f197557cd14ac._comment
@@ -0,0 +1,20 @@
+[[!comment format=mdwn
+ username="openmedi"
+ avatar="http://cdn.libravatar.org/avatar/563ffaff3b492c579bd8f094472e4506"
+ subject="comment 3"
+ date="2017-06-25T16:12:18Z"
+ content="""
+Thanks for you comments, I'll try to document my journey to get this to work. Right now the situation is this:
+
+I have a kinda big wiki which also includes a directory assets under which all pictures and anything else is found. this worked well in the past, however it makes for a pretty bloated git repository. I'm not completely sure how, but these are some tasks I have to accomplish:
+
+- Understand what actually is an underlay directory: As far as I can tell this is simply a directory which is 1. not in the git repo 2. added to the wiki before compilation.
+- Remove the assets directory from my ikiwki-git-repo on my local computer and on my server: In theory removing it locally should cause to be removed from the server as well, if we mean \"remove\" here in the sense of delete. However this still leaves us with a) a bloated git repo because it retains the repos history b) we need to put the assets directory somewhere safe locally before removing it from git
+- Retain the current directory structure so links won't be broken: This probably means we have to put the assets directory into the gitignore of the ikiwiki-git-repo, since we don't want to move the repo somewhere else.
+- Init git lfs or git annex in the assets directory, etc.: I need to start tracking my files in the assets directory with the help of one of these tools in order to ensure easy movement between my local wiki and my server wiki. I need to find out which of these tools is better suited for the job. RIght now it feels like that git annex is overkill for the simple job of having a slim git repo for the actual wiki and having one for the assets. Droping, decentralized backups, etc. etc. are not something I need, since my local wiki as well as my server wiki depends on the asset data being present. For the actual setup of this it might be easier to init it on the server first, make a local backup, clone the server repo into the correct directory locally at see of there are files missing.
+- Setting up the underlayer dir: Here I have to do it two times, one local one on the server since the absolute paths to the assets directories will be different.
+- Regenerate the local wiki and the server wiki: I'm not sure yet if regenerating the local wiki, then pushing to the server repo is the actual way to do this
+- Clean up bulky git repo: After confirming all of this works as intended, I will have to slim down my repo by removing the big files from my repo's history: the bfg-repo-cleaner looks like a promising solution for this problem.
+
+If I have imagined this correctly then I should be able to have an independently run assets directory which works basically the same as before, but the difference will be, that it doesn't bloat my repo's history anymore.
+"""]]

removed
diff --git a/doc/examples/softwaresite/bugs/hghg.mdwn b/doc/examples/softwaresite/bugs/hghg.mdwn
deleted file mode 100644
index e7cad45..0000000
--- a/doc/examples/softwaresite/bugs/hghg.mdwn
+++ /dev/null
@@ -1,2 +0,0 @@
-hghg
-test change

diff --git a/doc/examples/softwaresite/bugs/hghg.mdwn b/doc/examples/softwaresite/bugs/hghg.mdwn
index cece641..e7cad45 100644
--- a/doc/examples/softwaresite/bugs/hghg.mdwn
+++ b/doc/examples/softwaresite/bugs/hghg.mdwn
@@ -1 +1,2 @@
 hghg
+test change

request more information
diff --git a/doc/bugs/imagemagick_6.9.8_test_suite_failure.mdwn b/doc/bugs/imagemagick_6.9.8_test_suite_failure.mdwn
index 847ad58..c2ea4f2 100644
--- a/doc/bugs/imagemagick_6.9.8_test_suite_failure.mdwn
+++ b/doc/bugs/imagemagick_6.9.8_test_suite_failure.mdwn
@@ -44,3 +44,12 @@ t/img.t, like so:
 
 Is this is a known problem and is there maybe a fix for this issue?
 
+> This was not a known bug before your report. It looks as though every
+> time we use `Image::Magick->Read(":foo.png")`, which is (or was)
+> ImageMagick's syntax for opening a file of unknown type without
+> interpreting a prefix containing `:` as a special directive instead
+> of part of the filename, it fails.
+>
+> Please try re-running the test with better diagnostics using
+> [commit 4ace7dbb7](http://source.ikiwiki.branchable.com/?p=source.git;a=commitdiff;h=4ace7dbb7)
+> and report what it says. --[[smcv]]

add bug report originally emailed to me by Peter Simons
diff --git a/doc/bugs/imagemagick_6.9.8_test_suite_failure.mdwn b/doc/bugs/imagemagick_6.9.8_test_suite_failure.mdwn
new file mode 100644
index 0000000..847ad58
--- /dev/null
+++ b/doc/bugs/imagemagick_6.9.8_test_suite_failure.mdwn
@@ -0,0 +1,46 @@
+we've recently updated Imagemagick in NixOS from version 6.9.7-6 to
+6.9.8-4, and this change causes the Ikiwiki test suite to fail in
+t/img.t, like so:
+
+	#   Failed test at t/img.t line 119.
+	#          got: 'no image'
+	#     expected: '10x10'
+
+	#   Failed test at t/img.t line 129.
+	#          got: 'no image'
+	#     expected: '12x12'
+
+	#   Failed test at t/img.t line 130.
+	#          got: 'no image'
+	#     expected: '16x2'
+
+	#   Failed test at t/img.t line 134.
+	#          got: 'no image'
+	#     expected: '8x8'
+
+	#   Failed test at t/img.t line 135.
+	#          got: 'no image'
+	#     expected: '4x4'
+
+	#   Failed test at t/img.t line 136.
+	#          got: 'no image'
+	#     expected: '6x6'
+
+	#   Failed test at t/img.t line 138.
+	#          got: 'no image'
+	#     expected: '11x11'
+
+	#   Failed test at t/img.t line 139.
+	#          got: 'no image'
+	#     expected: '12x12'
+
+	#   Failed test at t/img.t line 140.
+	#          got: 'no image'
+	#     expected: '13x13'
+	# Looks like you failed 9 tests of 62.
+	t/img.t ........................
+	Dubious, test returned 9 (wstat 2304, 0x900)
+	Failed 9/62 subtests
+
+Is this is a known problem and is there maybe a fix for this issue?
+

Announce 3.20170622
diff --git a/doc/news/version_3.20161219.mdwn b/doc/news/version_3.20161219.mdwn
deleted file mode 100644
index e4f32db..0000000
--- a/doc/news/version_3.20161219.mdwn
+++ /dev/null
@@ -1,14 +0,0 @@
-ikiwiki 3.20161219 released with [[!toggle text="these changes"]]
-[[!toggleable text="""
- * [ Joey Hess ]
-   * inline: Prevent creating a file named ".mdwn" when the
-     postform is submitted with an empty title.
- * [ Simon McVittie ]
-   * Security: tell `git revert` not to follow renames. If it does, then
-     renaming a file can result in a revert writing outside the wiki srcdir
-     or altering a file that the reverting user should not be able to alter,
-     an authorization bypass. Thanks, intrigeri. ([[!debcve CVE-2016-10026]])
-   * cgitemplate: remove some dead code. Thanks, blipvert
-   * Restrict CSS matches against header class to not break
-     Pandoc tables with header rows. Thanks, karsk
-   * Make pagestats output more deterministic. Thanks, intrigeri"""]]
diff --git a/doc/news/version_3.20170622.mdwn b/doc/news/version_3.20170622.mdwn
new file mode 100644
index 0000000..33962b7
--- /dev/null
+++ b/doc/news/version_3.20170622.mdwn
@@ -0,0 +1,31 @@
+ikiwiki 3.20170622 released with [[!toggle text="these changes"]]
+[[!toggleable text="""
+   * `t/git-cgi.t`: Wait 1 second before doing a revert that should work.
+     This hopefully fixes a race condition in which the test failed
+     around 6% of the time. (Closes: #[862494](http://bugs.debian.org/862494))
+   * Guard against set-but-empty `REMOTE_USER` CGI variable on
+     misconfigured nginx servers, and in general treat sessions with
+     a set-but-empty name as if they were not signed in.
+   * When the CGI fails, print the error to stderr, not "Died"
+   * mdwn: Don't mangle <code>&lt;style&gt;</code> into <code>&lt;elyts&gt;</code> under some circumstances
+   * mdwn: Enable footnotes by default when using the default Discount
+     implementation. A new `mdwn_footnotes` option can be used to disable
+     footnotes in MultiMarkdown and Discount.
+   * mdwn: Don't enable alphabetically labelled ordered lists by
+     default when using the default Discount implementation. A new
+     `mdwn_alpha_list` option can be used to restore the old
+     interpretation.
+   * osm: Convert savestate hook into a changes hook. savestate is not
+     the right place to write wiki content, and in particular this
+     breaks websetup if osm's dependencies are not installed, even
+     if the osm plugin is not actually enabled.
+     (Closes: #[719913](http://bugs.debian.org/719913))
+   * toc: if the heading is of the form `<h1 id="...">`, use that for
+     the link in the table of contents (but continue to generate
+     `<a name="index42"></a>` in case someone was relying on it).
+     Thanks, [[Antoine Beaupré|anarcat]]
+   * color: Do not leak markup into contexts that take only the plain
+     text, such as toc
+   * meta: Document `\[[!meta name="foo" content="bar"]]`
+   * debian: Use preferred https URL for Format of `debian/copyright`
+   * debian: Declare compliance with Debian Policy 4.0.0"""]]

meta: Specifically document [[!meta foo:bar="baz"]] as not working
diff --git a/doc/ikiwiki/directive/meta.mdwn b/doc/ikiwiki/directive/meta.mdwn
index 0d4d9d6..3df176c 100644
--- a/doc/ikiwiki/directive/meta.mdwn
+++ b/doc/ikiwiki/directive/meta.mdwn
@@ -217,7 +217,12 @@ a quote in the text by writing `&quot;` and so on.
 
 If the field is not one of the above predefined fields, the metadata will be
 written to the generated html page as a &lt;meta&gt; header. For example,
-`\[[!meta foo="bar"]]` becomes `<meta name="foo" content="bar">`. As with `name`, this
-won't be allowed if the [[!iki plugins/htmlscrubber desc=htmlscrubber]] plugin is enabled.
+`\[[!meta foo="bar"]]` becomes `<meta name="foo" content="bar">`. As
+with `name`, this won't be allowed if the [[!iki plugins/htmlscrubber
+desc=htmlscrubber]] plugin is enabled.
+
+This syntax cannot be used for meta headers with unusual names, in
+particular names containing `:` such as `flattr:id` and `twitter:card`.
+Please use `\[[!meta name="..." content="..."]]` for those headers.
 
 [[!meta robots="noindex, follow"]]

diff --git a/doc/users/james.mdwn b/doc/users/james.mdwn
index ee539c2..2536353 100644
--- a/doc/users/james.mdwn
+++ b/doc/users/james.mdwn
@@ -1 +1 @@
-Runs ikiwiki on his home page at [[http://jamestechnotes.com]] and can be reached at [[james@jamestechnotes.com]]
+James runs ikiwiki on his site at [[https://jamestechnotes.com]] and can be reached at [[j@mesrichardson.com]]

diff --git a/doc/users/Alice_Ferrazzi.mdwn b/doc/users/Alice_Ferrazzi.mdwn
new file mode 100644
index 0000000..ce01362
--- /dev/null
+++ b/doc/users/Alice_Ferrazzi.mdwn
@@ -0,0 +1 @@
+hello

Ensure repo gets picked up by gitremotes script
diff --git a/doc/git.mdwn b/doc/git.mdwn
index d62104b..52c9ca3 100644
--- a/doc/git.mdwn
+++ b/doc/git.mdwn
@@ -68,7 +68,7 @@ think about merging them. This is recommended. :-)
 * [[users/kjs]] `git://src.kalleswork.net/ikiwiki.git`
 * bfree `git://github.com/bfree/ikiwiki.git`
 * [[users/leg]] `git://at.magma-soft.at/ikiwiki.info`
-* [[users/thcipriani]] `https://github.com/thcipriani/ikiwiki.git` ([[browse|https://github.com/thcipriani/ikiwiki]])
+* [[thcipriani]] `https://github.com/thcipriani/ikiwiki.git` ([[browse|https://github.com/thcipriani/ikiwiki]])
 
 ## branches
 

Add jsonfeed patch
diff --git a/doc/todo/JSON_Feed_support.mdwn b/doc/todo/JSON_Feed_support.mdwn
new file mode 100644
index 0000000..deb1ea5
--- /dev/null
+++ b/doc/todo/JSON_Feed_support.mdwn
@@ -0,0 +1,4 @@
+[[!tag patch]]
+[[!template  id=gitbranch branch=thcipriani/jsonfeed author="[[users/thcipriani]]"]]
+
+Made a patch to add basic support for [[https://jsonfeed.org]] version 1 to the inline plugin.

Add thcipriani repository
diff --git a/doc/git.mdwn b/doc/git.mdwn
index 2c92c9a..d62104b 100644
--- a/doc/git.mdwn
+++ b/doc/git.mdwn
@@ -68,6 +68,7 @@ think about merging them. This is recommended. :-)
 * [[users/kjs]] `git://src.kalleswork.net/ikiwiki.git`
 * bfree `git://github.com/bfree/ikiwiki.git`
 * [[users/leg]] `git://at.magma-soft.at/ikiwiki.info`
+* [[users/thcipriani]] `https://github.com/thcipriani/ikiwiki.git` ([[browse|https://github.com/thcipriani/ikiwiki]])
 
 ## branches
 

Add my user page
diff --git a/doc/users/thcipriani.mdwn b/doc/users/thcipriani.mdwn
new file mode 100644
index 0000000..4af0089
--- /dev/null
+++ b/doc/users/thcipriani.mdwn
@@ -0,0 +1,21 @@
+[[!meta title="Tyler Cipriani"]]
+
+/me *waves*
+
+I'm Tyler.
+
+## Contact
+
+* [tyler@tylercipriani.com](mailto:tyler@tylercipriani.com)
+* irc: thcipriani (Freenode)
+* @[thcipriani](https://twitter.com/thcipriani)
+* [github](https://github.com/thcipriani)
+* [pinboard](https://pinboard.in/u:thcipriani/)
+* [library thing](https://www.librarything.com/catalog/thcipriani)
+
+## GPG Key
+
+* [tylercipriani.gpg](018FAC02.asc)
+* [MIT keyserver](https://pgp.mit.edu/pks/lookup?op=vindex&search=0xF6DAD285018FAC02)
+* [Keybase](https://keybase.io/thcipriani)
+* Fingerprint: `6237 D8D3 ECC1 AE91 8729  296F F6DA D285 018F AC02`

current headinganchors does not damage headings' attributes, although it does not act on those headings
diff --git a/doc/plugins/contrib/i18nheadinganchors/discussion.mdwn b/doc/plugins/contrib/i18nheadinganchors/discussion.mdwn
index ec65680..a172e5a 100644
--- a/doc/plugins/contrib/i18nheadinganchors/discussion.mdwn
+++ b/doc/plugins/contrib/i18nheadinganchors/discussion.mdwn
@@ -84,6 +84,10 @@ or similar.
 > It's not a bug, it's a limitation. :) But sure, it's a thing. It's an issue in
 > headinganchors as well of course. -- [[anarcat]]
 
+>> No, current/historical headinganchors has a different bug: it ignores headings
+>> that have any attributes, and does not generate anchors for them. That gives it
+>> degraded functionality, but no information loss. I think that's less bad. --s
+
 I think we should try to use an existing ID before generating our own, with the
 generation step as a fallback, just like Pandoc does. If a htmlize layer like
 Text::MultiMarkdown or Pandoc is generating worse IDs than this plugin, the

diff --git a/doc/plugins/contrib/i18nheadinganchors/discussion.mdwn b/doc/plugins/contrib/i18nheadinganchors/discussion.mdwn
index 8e539b6..ec65680 100644
--- a/doc/plugins/contrib/i18nheadinganchors/discussion.mdwn
+++ b/doc/plugins/contrib/i18nheadinganchors/discussion.mdwn
@@ -21,6 +21,13 @@ clearer where it goes)
 > Can we assume Ikiwiki generates HTML5 all the time? I thought that was still a 
 > setting off by default... --[[anarcat]]
 
+>> ikiwiki always generates HTML5, since 3.20150107. The `html5` option has
+>> been repurposed to control whether we generate new-in-HTML5 semantic
+>> markup like `<section>` and `<nav>` (`html5` enabled), or HTML4 equivalents
+>> like `<div>` with a class (`html5` disabled). The default is still off,
+>> although I should probably either toggle it to on or remove the option
+>> altogether in the next release. --s
+
 So perhaps we could try this Unicode-aware version of what Pandoc documents:
 
 * Remove footnote links if any (this might have to be heuristic, or we could
@@ -55,6 +62,13 @@ supporting [IRIs](https://tools.ietf.org/html/rfc3987): `<a href="#visiting-北
 > as an example, https://caniuse.com/ doesn't have that feature listed in their 
 > tables. :) -- [[anarcat]]
 
+>> That might well indicate that all major browsers have always supported it so
+>> there is no need to check. I don't see any particular reason why a browser vendor
+>> would not want to accept arbitrary non-whitespace as a valid anchor.
+>>
+>> In practice, minor or old browsers are probably insecure anyway, so I don't care
+>> too much about supporting them perfectly... --s
+
 ----
 
 Documentation says:

resolved
diff --git a/doc/todo/toc-with-human-readable-anchors.mdwn b/doc/todo/toc-with-human-readable-anchors.mdwn
index 1e41add..482dad7 100644
--- a/doc/todo/toc-with-human-readable-anchors.mdwn
+++ b/doc/todo/toc-with-human-readable-anchors.mdwn
@@ -24,6 +24,8 @@ my [toc-recycle-id branch][] (see [921a264][]).
 [921a264]: https://gitlab.com/anarcat/ikiwiki/commit/27d5d9d126b6b675ad273ebd63095df0c921a264
 [toc-recycle-id branch]: https://gitlab.com/anarcat/ikiwiki/commits/toc-id-recycle
 
+> [[Merged|done]] --[[smcv]]
+
 The second step is to generate those headings. There are two ways of
 doing this:
 
@@ -40,7 +42,16 @@ doing this:
     > far as I know there's still no API-stable CommonMark library. --[[smcv]]
 
     > > Sure - but then does discount introduce those identifiers in headings?
+    > >
+    > > > Only if you ask for a table of contents, which ikiwiki doesn't.
+    > > > If you want it to have a flag to produce the IDs even without enabling
+    > > > its built-in ToC support, that would be a feature request for discount,
+    > > > not ikiwiki. Until/unless it does, there's always headinganchors. --s
+    > >
     > > And what about the patch to recycle those identifiers? --[[anarcat]]
+    > > >
+    > > > I already merged it, and added a regression test. Sorry, I forgot
+    > > > to close this todo at the time. --s
 
  2. enable the [[plugins/headinganchors]] plugin. if multimarkdown is
     disabled, this can also provide usable identifiers.

response
diff --git a/doc/plugins/contrib/i18nheadinganchors/discussion.mdwn b/doc/plugins/contrib/i18nheadinganchors/discussion.mdwn
index 716fc09..8e539b6 100644
--- a/doc/plugins/contrib/i18nheadinganchors/discussion.mdwn
+++ b/doc/plugins/contrib/i18nheadinganchors/discussion.mdwn
@@ -18,6 +18,9 @@ anchor name](#пример) (the output of putting "example" into English-to-Rus
 Google Translate) hopefully works? (Use a small browser window to make it
 clearer where it goes)
 
+> Can we assume Ikiwiki generates HTML5 all the time? I thought that was still a 
+> setting off by default... --[[anarcat]]
+
 So perhaps we could try this Unicode-aware version of what Pandoc documents:
 
 * Remove footnote links if any (this might have to be heuristic, or we could
@@ -47,6 +50,10 @@ supporting [IRIs](https://tools.ietf.org/html/rfc3987): `<a href="#visiting-北
 
 --[[smcv]]
 
+> I guess this makes sense. I just wonder how well this is actually supported in all
+> browsers.. I looked around and suspect this will work in more recent browsers, but,
+> as an example, https://caniuse.com/ doesn't have that feature listed in their 
+> tables. :) -- [[anarcat]]
 
 ----
 
@@ -60,6 +67,9 @@ I think this is a bug, particularly if you are using Pandoc's
 [header attributes](http://pandoc.org/MANUAL.html#extension-header_attributes)
 or similar.
 
+> It's not a bug, it's a limitation. :) But sure, it's a thing. It's an issue in
+> headinganchors as well of course. -- [[anarcat]]
+
 I think we should try to use an existing ID before generating our own, with the
 generation step as a fallback, just like Pandoc does. If a htmlize layer like
 Text::MultiMarkdown or Pandoc is generating worse IDs than this plugin, the
@@ -69,6 +79,11 @@ htmlize layer, or stop using Text::MultiMarkdown.
 
 --[[smcv]]
 
+> Agreed. However, the situation I was in was that multimarkdown *and* the 
+> headinganchors plugins had issues I had to fix. So it was better and easier
+> for me to just override whatever attributes were there for testing and 
+> fixing this in the short term... -- [[anarcat]]
+
 ----
 
 <pre>Some long scrollable text
@@ -113,3 +128,5 @@ htmlize layer, or stop using Text::MultiMarkdown.
 .
 .
 .</pre>
+
+> This works for me on ` Mozilla/5.0 (X11; Linux x86_64; rv:50.0) Gecko/20100101 Firefox/50.0` on Debian stretch, FWIW. --[[anarcat]]

response
diff --git a/doc/todo/toc-with-human-readable-anchors.mdwn b/doc/todo/toc-with-human-readable-anchors.mdwn
index 09985a9..1e41add 100644
--- a/doc/todo/toc-with-human-readable-anchors.mdwn
+++ b/doc/todo/toc-with-human-readable-anchors.mdwn
@@ -39,6 +39,9 @@ doing this:
     > always be using CommonMark or Discount these days, but as
     > far as I know there's still no API-stable CommonMark library. --[[smcv]]
 
+    > > Sure - but then does discount introduce those identifiers in headings?
+    > > And what about the patch to recycle those identifiers? --[[anarcat]]
+
  2. enable the [[plugins/headinganchors]] plugin. if multimarkdown is
     disabled, this can also provide usable identifiers.
 

diff --git a/doc/todo/smileys_should_support_Unicode_Emojis.mdwn b/doc/todo/smileys_should_support_Unicode_Emojis.mdwn
new file mode 100644
index 0000000..9bbfeaa
--- /dev/null
+++ b/doc/todo/smileys_should_support_Unicode_Emojis.mdwn
@@ -0,0 +1,128 @@
+Why are there graphic-based smileys at all, when Unicode supports most of them directly?
+
+What Unicode doesn't support can be handled by FontAwesome or a little CSS. 
+
+Keeping font-based solutions to emojis allows them to scale naturally with the fonts. An emoji in the title becomes a different size than an emoji in paragraph, or an emoji in a subscript.
+
+Here's a smileys.mdwn file that doesn't use any graphics at all:
+
+<pre>
+This page is used to control what smileys are supported by the wiki.
+Just write the text of a smiley to display it.
+
+* \\:)	[🙂]
+* \\:smile:	[🙂]
+* \\:-)	[🙂]
+* \\:D	[😃] 
+* \\:-D	[😃] 
+* \\:grin:	[😃] 
+* \\B)	[😎]
+* \\B-)	[😎]
+* \\:))	[😛]
+* \\:-))	[😛]
+* \\;)	[😉]
+* \\;-)	[😉]
+* \\:\	[😕]
+* \\:-\	[😕]
+* \\:/	[😕]
+* \\:-/	[😕]
+* \\:|	[😐]
+* \\:-|	[😐]
+* \\>:>	[😈]
+* \\X-(	[😡]
+* \\&lt;:(	[😧]
+* \\:(	[🙁]
+* \\:-(	[🙁]
+* \\:-?	[😝]
+* \\:-P	[😝]
+* \\:o	[😱]
+* \\|)	[😪]
+* \\|-)	[😪]
+* \\{OK}	[👍]
+* \\:+1:    [👍]
+* \\:-1:    [👎]
+* \\(/)	[🚫]
+* \\{X}	[🛑]
+* \\{i}	[ℹ️]
+* \\(./)	[✔︎]
+* \\(!)	[💡]
+* \\[!]	[✋]
+* \\/!\	[⚠️]
+* \\(?)	[❓]
+* \\(!?)	[⁉️]
+* \\{x}	[☒]
+* \\{*}	[☑︎]
+* \\{o}	[☐]
+* \\{1}	[<span class="priority-1">𝟙</span>]
+* \\{2}	[<span class="priority-2">𝟚</span>]
+* \\{3}	[<span class="priority-3">𝟛<span>]
+
+For example: {x} B) {x} {3} :grin: :-1: 
+
+----
+
+To change the supported smileys, just edit the lists on this page.
+Note that the format is important; each list item should start with the
+text that is turned into the smiley, escaped so that users can see what
+produces it, followed by a [[ikiwiki/WikiLink]] to the image to display.
+
+/!\ Bear in mind that the link to the image needs to be written in a way that
+will work if it's copied to other pages on the wiki. So be sure to include the
+smileys directory in the path to the file.
+</pre>
+
+Here's the patch to smiley.pm:
+
+<pre>
+--- smiley.pm.orig	2017-05-26 18:00:01.000000000 -0400
++++ smiley.pm	2017-05-26 22:01:18.000000000 -0400
+@@ -33,17 +33,17 @@
+ 		return;
+ 	}
+ 	my $list=readfile($srcfile);
+-	while ($list =~ m/^\s*\*\s+\\\\([^\s]+)\s+\[\[([^]]+)\]\]/mg) {
++	while ($list =~ m/^\s*\*\s+\\\\([^\s]+)\s+\[([^\]]+)\]/mg) {
+ 		my $smiley=$1;
+-		my $file=$2;
++		my $value=$2;
+
+-		$smileys{$smiley}=$file;
++		$smileys{$smiley}=$value;
+
+ 		# Add a version with < and > escaped, since they probably
+ 		# will be (by markdown) by the time the sanitize hook runs.
+ 		$smiley=~s/</&lt;/g;
+ 		$smiley=~s/>/&gt;/g;
+-		$smileys{$smiley}=$file;
++		$smileys{$smiley}=$value;
+ 	}
+
+ 	if (! %smileys) {
+@@ -94,10 +94,18 @@
+ 		}
+ 		else {
+ 			# Replace the smiley with its expanded value.
+-			my $link=htmllink($params{page}, $params{destpage},
+-				         $smileys{$smiley}, linktext => $smiley);
+-			substr($_, $spos, length($smiley))=$link;
+-			pos=$epos+length($link);
++			my $value = $smileys{$smiley};
++			my $replacement = "";
++			if ($value =~ /\[([^\]]*)/) {
++				$value=$1;
++				$replacement=htmllink($params{page}, $params{destpage},
++							$value, linktext => $smiley);
++			}
++			else {
++				$replacement=$value;
++			}
++			substr($_, $spos, length($smiley))=$replacement;
++			pos=$epos+length($replacement);
+ 		}
+ 	}
+
+</pre>
+
+As you can see, it keeps the [] characters around the smiley. This can be useful if it renders to nothing in the browser -- particularly in the CSS-based solutions. 
+
+It keeps the same data structure, but images get a "[" prefix to them as a marker. Since I minimized the changes to the regex, the trailing "]" is still dropped.

Added a comment: Please do not patch out the symlink check
diff --git a/doc/forum/An_assets_directory_for_my_wiki_with_git_lfs_or_annex__63__/comment_2_84b6b804bdea2fc090d7ace65dcdaeb8._comment b/doc/forum/An_assets_directory_for_my_wiki_with_git_lfs_or_annex__63__/comment_2_84b6b804bdea2fc090d7ace65dcdaeb8._comment
new file mode 100644
index 0000000..e860110
--- /dev/null
+++ b/doc/forum/An_assets_directory_for_my_wiki_with_git_lfs_or_annex__63__/comment_2_84b6b804bdea2fc090d7ace65dcdaeb8._comment
@@ -0,0 +1,19 @@
+[[!comment format=mdwn
+ username="smcv"
+ avatar="http://cdn.libravatar.org/avatar/0ee943fe632ff995f6f0f25b7167d03b"
+ subject="Please do not patch out the symlink check"
+ date="2017-05-26T06:20:22Z"
+ content="""
+The check for symbolic links avoids a security vulnerability. Please do not patch
+it out. We will not support versions of ikiwiki that have been modified in this way.
+
+(In particular, if your wiki has more than one committer, then the other committers
+can use symbolic links to leak the contents of any file that is readable by
+the wiki.)
+
+If you want to store a separate assets directory, I would recommend using an
+underlay directory. You can use git-annex for this if it is placed in direct mode.
+
+I do want to support git-annex and some limited/safe subset of symlinks in
+ikiwiki, but not until we can do that without introducing a security flaw.
+"""]]

Added a comment: git-annex support
diff --git a/doc/forum/An_assets_directory_for_my_wiki_with_git_lfs_or_annex__63__/comment_1_3dc35849d9d4d73f5184d0577afa7f30._comment b/doc/forum/An_assets_directory_for_my_wiki_with_git_lfs_or_annex__63__/comment_1_3dc35849d9d4d73f5184d0577afa7f30._comment
new file mode 100644
index 0000000..014bcb7
--- /dev/null
+++ b/doc/forum/An_assets_directory_for_my_wiki_with_git_lfs_or_annex__63__/comment_1_3dc35849d9d4d73f5184d0577afa7f30._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="mail@b2ae8518bb6eba14728f86acae7830e4c2d9943d"
+ nickname="mail"
+ avatar="http://cdn.libravatar.org/avatar/1b15be83ec9e779dce940ce88cac603a"
+ subject="git-annex support"
+ date="2017-05-25T14:43:18Z"
+ content="""
+There are multiple pages on the wiki regarding git-annex support, also I found that by just enabling use of symlinks, git-annex works well [1].
+
+1: http://git.cbaines.net/ikiwiki/commit/?h=git-annex&id=3957bbab17874d60f2597cebcc02cda5c212067a
+"""]]

diff --git a/doc/forum/An_assets_directory_for_my_wiki_with_git_lfs_or_annex__63__.mdwn b/doc/forum/An_assets_directory_for_my_wiki_with_git_lfs_or_annex__63__.mdwn
new file mode 100644
index 0000000..c6887c9
--- /dev/null
+++ b/doc/forum/An_assets_directory_for_my_wiki_with_git_lfs_or_annex__63__.mdwn
@@ -0,0 +1 @@
+Is it somehow possible to have an assets directory powered by git-lfs or maybe git-annex that can handle pictures and other bigger data so that they won't clutter up my git history?

Added a comment: I suggest asking macOS/brew people
diff --git a/doc/forum/How_to_install_Text:Multimarkdown__63__/comment_1_1095806303c9d701d71078efe431e35e._comment b/doc/forum/How_to_install_Text:Multimarkdown__63__/comment_1_1095806303c9d701d71078efe431e35e._comment
new file mode 100644
index 0000000..52b5ef7
--- /dev/null
+++ b/doc/forum/How_to_install_Text:Multimarkdown__63__/comment_1_1095806303c9d701d71078efe431e35e._comment
@@ -0,0 +1,40 @@
+[[!comment format=mdwn
+ username="smcv"
+ avatar="http://cdn.libravatar.org/avatar/0ee943fe632ff995f6f0f25b7167d03b"
+ subject="I suggest asking macOS/brew people"
+ date="2017-05-22T11:02:44Z"
+ content="""
+The multimarkdown option is not necessarily a good idea. The default
+and recommended Markdown implementation in ikiwiki is Discount, which already
+supports many of the same extensions as multimarkdown (in released versions of ikiwiki,
+footnotes are a notable omission, but those will be enabled by default in the
+next release).
+
+If you want to use multimarkdown anyway, please check what the search path is
+for the version of Perl that you are using to run ikiwiki. In particular, the
+most reliable setup is likely to be one where you get Perl, Text::MultiMarkdown
+and IkiWiki from the same vendor (for example Homebrew or pkgsrc) without
+mixing those vendors.
+
+If you obtained one of those packages (for example ikiwiki) by building it
+yourself from source code, its author is unlikely to be able to help you
+unless they happen to be a macOS user themselves, which most of the ikiwiki
+contributors are not. If you are doing this, you should make sure you
+understand how Perl finds libraries (for example this is described in
+the perlrun man page). It might be necessary to add
+
+```
+ENV:
+  PERL5LIB: /some/path:/some/other/path
+```
+
+(YAML syntax) or
+
+```
+  ENV => {
+    PERL5LIB => \"/some/path:/some/other/path\",
+  },
+```
+
+(Perl syntax) to your [[setup file|setup]].
+"""]]

diff --git a/doc/forum/How_to_install_Text:Multimarkdown__63__.mdwn b/doc/forum/How_to_install_Text:Multimarkdown__63__.mdwn
index 553caed..0d64c58 100644
--- a/doc/forum/How_to_install_Text:Multimarkdown__63__.mdwn
+++ b/doc/forum/How_to_install_Text:Multimarkdown__63__.mdwn
@@ -1,6 +1,6 @@
 The rebuilding command
 
-     ikiwiki --setup mysite.setup --rebuild
+    ikiwiki --setup mysite.setup --rebuild
 
 issues an error
 

diff --git a/doc/forum/How_to_install_Text:Multimarkdown__63__.mdwn b/doc/forum/How_to_install_Text:Multimarkdown__63__.mdwn
new file mode 100644
index 0000000..553caed
--- /dev/null
+++ b/doc/forum/How_to_install_Text:Multimarkdown__63__.mdwn
@@ -0,0 +1,19 @@
+The rebuilding command
+
+     ikiwiki --setup mysite.setup --rebuild
+
+issues an error
+
+    multimarkdown is enabled, but Text::MultiMarkdown is not installed
+
+I then tried to install it on macOS using
+
+    brew install multimarkdown
+
+and then
+
+   sudo pkgin -y install multimarkdown
+
+and then rebuilding, but I still get the same error.
+
+Why and how do I fix it?

Added a comment
diff --git a/doc/forum/Limit_pagespec_to_a_certain_depth/comment_3_21c0348c70bc43e72d23017135554d45._comment b/doc/forum/Limit_pagespec_to_a_certain_depth/comment_3_21c0348c70bc43e72d23017135554d45._comment
new file mode 100644
index 0000000..c1928ed
--- /dev/null
+++ b/doc/forum/Limit_pagespec_to_a_certain_depth/comment_3_21c0348c70bc43e72d23017135554d45._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="openmedi"
+ avatar="http://cdn.libravatar.org/avatar/563ffaff3b492c579bd8f094472e4506"
+ subject="comment 3"
+ date="2017-05-19T15:32:17Z"
+ content="""
+Thanks! That was what I was missing.
+"""]]

Suggested syntax does work, and has a test
diff --git a/doc/bugs/It__39__s_not_possible_to_add_the_new_Flattr_meta_tag_using_the_meta_directive.mdwn b/doc/bugs/It__39__s_not_possible_to_add_the_new_Flattr_meta_tag_using_the_meta_directive.mdwn
index c0452e2..568c998 100644
--- a/doc/bugs/It__39__s_not_possible_to_add_the_new_Flattr_meta_tag_using_the_meta_directive.mdwn
+++ b/doc/bugs/It__39__s_not_possible_to_add_the_new_Flattr_meta_tag_using_the_meta_directive.mdwn
@@ -19,4 +19,7 @@ I tried [a number of possibilities](https://feeding.cloud.geek.nz/recentchanges/
 >
 >     \[[!meta name="flattr:id" content="4j6y0v"]]
 >
-> Please try that. --[[smcv]]
+> This was missing from the documentation, but I have now added it. This feature was
+> broken until 2015, but we now have an automated test to make sure it keeps working;
+> the test includes a check for `twitter:card` which is essentially equivalent to
+> what you're doing here. [[done]] --[[smcv]]

Document the special case for [[!meta name=foo content=bar]]
diff --git a/doc/ikiwiki/directive/meta.mdwn b/doc/ikiwiki/directive/meta.mdwn
index 955648c..0d4d9d6 100644
--- a/doc/ikiwiki/directive/meta.mdwn
+++ b/doc/ikiwiki/directive/meta.mdwn
@@ -13,7 +13,7 @@ per `meta` directive, use more directives if you want to specify more fields.
 The field values are treated as HTML entity-escaped text, so you can include
 a quote in the text by writing `&quot;` and so on.
 
-Supported fields:
+## Supported fields
 
 * title
 
@@ -204,9 +204,20 @@ Supported fields:
 
   	\[[!meta foaf=foaf.rdf]]
 
+* name
+
+  Adds a HTML `<meta>` header with this `name` attribute. Its other attributes are
+  taken from the other parameters, so for example
+  `\[[!meta name="foo" content="bar" x-non-standard-attribute="baz"]]`
+  becomes `<meta name="foo" content="bar" x-non-standard-attribute="baz">`. This
+  won't be allowed if the [[!iki plugins/htmlscrubber desc=htmlscrubber]] plugin is enabled,
+  since it can be used to insert unsafe content.
+
+## Other fields
+
 If the field is not one of the above predefined fields, the metadata will be
-written to the generated html page as a &lt;meta&gt; header. However, this
-won't be allowed if the [[!iki plugins/htmlscrubber desc=htmlscrubber]] plugin is enabled,
-since it can be used to insert unsafe content.
+written to the generated html page as a &lt;meta&gt; header. For example,
+`\[[!meta foo="bar"]]` becomes `<meta name="foo" content="bar">`. As with `name`, this
+won't be allowed if the [[!iki plugins/htmlscrubber desc=htmlscrubber]] plugin is enabled.
 
 [[!meta robots="noindex, follow"]]

it is (meant to be) possible, just not with that syntax
diff --git a/doc/bugs/It__39__s_not_possible_to_add_the_new_Flattr_meta_tag_using_the_meta_directive.mdwn b/doc/bugs/It__39__s_not_possible_to_add_the_new_Flattr_meta_tag_using_the_meta_directive.mdwn
index 7da8bcc..c0452e2 100644
--- a/doc/bugs/It__39__s_not_possible_to_add_the_new_Flattr_meta_tag_using_the_meta_directive.mdwn
+++ b/doc/bugs/It__39__s_not_possible_to_add_the_new_Flattr_meta_tag_using_the_meta_directive.mdwn
@@ -13,3 +13,10 @@ it gets rendered as:
     <meta name="flattr:id=&quot;4j6y0v&quot;" content="" />
 
 I tried [a number of possibilities](https://feeding.cloud.geek.nz/recentchanges/) and they all failed to produce the correct output.
+
+> Directive syntax doesn't allow named arguments containing colons, so we would have to
+> add a different syntax for weird names. However, we already have that:
+>
+>     \[[!meta name="flattr:id" content="4j6y0v"]]
+>
+> Please try that. --[[smcv]]

diff --git a/doc/bugs/It__39__s_not_possible_to_add_the_new_Flattr_meta_tag_using_the_meta_directive.mdwn b/doc/bugs/It__39__s_not_possible_to_add_the_new_Flattr_meta_tag_using_the_meta_directive.mdwn
new file mode 100644
index 0000000..7da8bcc
--- /dev/null
+++ b/doc/bugs/It__39__s_not_possible_to_add_the_new_Flattr_meta_tag_using_the_meta_directive.mdwn
@@ -0,0 +1,15 @@
+The new way to confirm ownership of a domain on Flattr is to add a `meta` tag to the page head. For example:
+
+     <meta name="flattr:id" content="4j6y0v">
+
+However, the [[ikiwiki/directive/meta]] directive doesn't allow setting of names with colons.
+
+If I do this:
+
+    \[[!meta flattr:id="4j6y0v"]]
+
+it gets rendered as:
+
+    <meta name="flattr:id=&quot;4j6y0v&quot;" content="" />
+
+I tried [a number of possibilities](https://feeding.cloud.geek.nz/recentchanges/) and they all failed to produce the correct output.

long out of date
diff --git a/doc/css_market.mdwn b/doc/css_market.mdwn
index d41a4a3..56f78a4 100644
--- a/doc/css_market.mdwn
+++ b/doc/css_market.mdwn
@@ -46,11 +46,6 @@ gnomes will convert them to css files..)
   You can grab some pictures used as background patterns from there.
   [[!meta stylesheet="cstamas"]]
 
-* **[[css_market/bma.css]]**, contributed by [bma](http://subvert.org.uk/~bma/).
-  Not quite the same as I use on my site, since that has slightly modified
-  templates.
-  [[!meta stylesheet="bma"]]
-
 * ** http://blog.lastlog.de/, contributed by joachim schiele; please feel free to copy.
 
 * **[wiki.css](http://cyborginstitute.net/includes/wiki.css)** by [[tychoish]]. 

color: Use markup for the preserved CSS, not character data
This still smuggles it past the sanitize step, but avoids having
other plugins that want to capture text content without markup
(notably toc) see the CSS as if it was text content.
diff --git a/IkiWiki/Plugin/color.pm b/IkiWiki/Plugin/color.pm
index 9bb2359..e80130d 100644
--- a/IkiWiki/Plugin/color.pm
+++ b/IkiWiki/Plugin/color.pm
@@ -38,12 +38,11 @@ sub preserve_style ($$$) {
 				($background =~ /^[a-z]+$/ || $background =~ /^#[0-9a-f]{3,6}$/));
 
 	my $preserved = '';
-	$preserved .= '<span class="color">';
+	$preserved .= '<span class="color"><span value="';
 	$preserved .= 'color: '.$foreground if ($foreground);
 	$preserved .= '; ' if ($foreground && $background);
 	$preserved .= 'background-color: '.$background if ($background);
-	$preserved .= '</span>';
-	$preserved .= '<span class="colorend">'.$text.'</span>';
+	$preserved .= '"></span>'.$text.'</span>';
 	
 	return $preserved;
 
@@ -52,8 +51,7 @@ sub preserve_style ($$$) {
 sub replace_preserved_style ($) {
 	my $content = shift;
 
-	$content =~ s!<span class="color">((color: ([a-z]+|\#[0-9a-f]{3,6})?)?((; )?(background-color: ([a-z]+|\#[0-9a-f]{3,6})?)?)?)</span>!<span class="color" style="$1">!g;
-	$content =~ s!<span class="colorend">!!g;
+	$content =~ s!<span class="color">\s*<span value="((color: ([a-z]+|\#[0-9a-f]{3,6})?)?((; )?(background-color: ([a-z]+|\#[0-9a-f]{3,6})?)?)?)">\s*</span>!<span class="color" style="$1">!g;
 
 	return $content;
 }
diff --git a/doc/bugs/color_plugin_produces_artifacts_in_table-of-contents.mdwn b/doc/bugs/color_plugin_produces_artifacts_in_table-of-contents.mdwn
index f97e5c5..d627091 100644
--- a/doc/bugs/color_plugin_produces_artifacts_in_table-of-contents.mdwn
+++ b/doc/bugs/color_plugin_produces_artifacts_in_table-of-contents.mdwn
@@ -16,6 +16,11 @@ Reason for this behaviour is:
 1. the toc plugin removes everything except plain text from headers in the toc
 1. if the toc plugin is executed before the color plugin in the format hook it sees the special syntax and clobbers the toc, otherwise it just removes the color markup
 
+> The bug here is that the color plugin's special syntax does not
+> gracefully degrade to "render nothing", which I have now [[fixed|done]]
+> by putting the color bits through a value attribute instead of
+> character data. --[[smcv]]
+
 # Solutions
 
 There are a few possible solutions to this depending on how it should work:
@@ -26,6 +31,12 @@ There are a few possible solutions to this depending on how it should work:
 
 I would propose implementing the second option because visual markers in headers are useful to convey additional information very fast and this information should be preserved in the toc. Example: Bug or task/project tracker with color conveying status of the bug or task.
 
+> This is really a separate feature request: copy non-`<a>` markup
+> in headings into the TOC. I don't think this necessarily makes
+> sense in general. In particular, any `id` attributes on child
+> elements must not be passed through because that would make
+> the ID non-unique. --[[smcv]]
+
 It seems you can stuff anything into ordered lists (according to w3.orgs doku), so apart from stylistic reasons and suboptimal display of links in headers (see below) I don't see any problems with markup in the toc. 
 
 # Patch
diff --git a/t/color.t b/t/color.t
index c5c14f6..dca0d86 100755
--- a/t/color.t
+++ b/t/color.t
@@ -25,10 +25,10 @@ sub render {
 
 foreach my $scrub (0, 1) {
 	if ($scrub) {
-		$config{add_plugins}=[qw(color htmlscrubber)];
+		$config{add_plugins}=[qw(color htmlscrubber toc)];
 	}
 	else {
-		$config{add_plugins}=[qw(color)];
+		$config{add_plugins}=[qw(color toc)];
 	}
 
 	IkiWiki::loadplugins();
@@ -44,6 +44,9 @@ foreach my $scrub (0, 1) {
 		qr{(?s)<span class="color" style="">Hi</span>});
 	like(render('[[!color foreground="x; pwned: exploit" text="Hi"]]'),
 		qr{(?s)<span class="color" style="">Hi</span>});
+
+	like(render("[[!toc ]]\n\n## [[!color foreground=red text=Important]]"),
+		qr{<a href="\#index1h2">Important</a>});
 }
 
 done_testing();

we should prefer existing IDs and only act as a fallback
diff --git a/doc/plugins/contrib/i18nheadinganchors/discussion.mdwn b/doc/plugins/contrib/i18nheadinganchors/discussion.mdwn
index 699f055..716fc09 100644
--- a/doc/plugins/contrib/i18nheadinganchors/discussion.mdwn
+++ b/doc/plugins/contrib/i18nheadinganchors/discussion.mdwn
@@ -1,5 +1,5 @@
 I would not be comfortable with merging this into headinganchors and enabling it by
-default for two reasons:
+default for two main reasons:
 
 * it adds a new dependency on [[!cpan Text::Unidecode]]
 * Text::Unidecode specifically documents its transliteration as not being stable
@@ -36,16 +36,39 @@ So perhaps we could try this Unicode-aware version of what Pandoc documents:
   an unused identifier
 
 (Or to provide better uniqueness, we could parse the document looking for any existing
-ID, then generate IDs avoiding collisions with any of them.)
+ID, then append `-1`, `-2` to each generated ID until there is no collision.)
 
 This would give us, for example, `## Visiting 北京` → `id="visiting-北京"`
-(where Text::Unidecode would instead transliterate, resulting in `id="visiting-bei-jing"`).
+(whereas Text::Unidecode would instead transliterate, resulting in
+`id="visiting-bei-jing"`).
 
 To use these IDs in fragments, I would be inclined to rely on browsers
 supporting [IRIs](https://tools.ietf.org/html/rfc3987): `<a href="#visiting-北京">`.
 
 --[[smcv]]
 
+
+----
+
+Documentation says:
+
+> _Also note that all heading attributes are overriden with the ID tag. If this
+> is not desirable, we'd need to fire up a full HTML::Parser or do some more
+> regex magic to preserve the attributes other than id= which we want to keep._
+
+I think this is a bug, particularly if you are using Pandoc's
+[header attributes](http://pandoc.org/MANUAL.html#extension-header_attributes)
+or similar.
+
+I think we should try to use an existing ID before generating our own, with the
+generation step as a fallback, just like Pandoc does. If a htmlize layer like
+Text::MultiMarkdown or Pandoc is generating worse IDs than this plugin, the
+the right solution to that is to send a bug report / feature request to
+make its IDs as good as this plugin's, or turn off ID generation in the
+htmlize layer, or stop using Text::MultiMarkdown.
+
+--[[smcv]]
+
 ----
 
 <pre>Some long scrollable text

cross-reference i18nheadinganchors
diff --git a/doc/plugins/headinganchors/discussion.mdwn b/doc/plugins/headinganchors/discussion.mdwn
index 512caa4..f55408f 100644
--- a/doc/plugins/headinganchors/discussion.mdwn
+++ b/doc/plugins/headinganchors/discussion.mdwn
@@ -34,6 +34,8 @@ A patch to make it more like MediaWiki:
 
 --Changaco
 
+> This was applied in 3.20110608 --[[smcv]]
+
 ----
 
 I think using this below would let the source html clear for the browser
@@ -49,3 +51,14 @@ without changing the render:
 
 Don't you think ?
 [[mathdesc]]
+
+> Older HTML and URI specifications didn't allow Unicode in IDs or fragments,
+> but HTML5 and IRIs do. See also [[plugins/contrib/i18nheadinganchors]]
+> and its [[plugins/contrib/i18nheadinganchors/discussion]] page.
+>
+> I think we should probably try to make these autogenerated IDs
+> punctuation-independent by stripping most non-word characters, like
+> Pandoc does: I would not expect changing
+> `## Headings, maybe with punctuation` to
+> `## Headings (maybe with punctuation)` to have any effect on the
+> generated "slug" `headings-maybe-with-punctuation`. --[[smcv]]

correct ID syntax
diff --git a/doc/plugins/contrib/i18nheadinganchors/discussion.mdwn b/doc/plugins/contrib/i18nheadinganchors/discussion.mdwn
index 1c3eb63..699f055 100644
--- a/doc/plugins/contrib/i18nheadinganchors/discussion.mdwn
+++ b/doc/plugins/contrib/i18nheadinganchors/discussion.mdwn
@@ -66,7 +66,7 @@ supporting [IRIs](https://tools.ietf.org/html/rfc3987): `<a href="#visiting-北
 .
 .
 .
-<span id="#пример">Example fragment ID in Russian should point here</span>
+<span id="пример">Example fragment ID in Russian should point here</span>
 .
 .
 .

browsers and specifications support more Unicode than we give them credit for
diff --git a/doc/plugins/contrib/i18nheadinganchors/discussion.mdwn b/doc/plugins/contrib/i18nheadinganchors/discussion.mdwn
new file mode 100644
index 0000000..1c3eb63
--- /dev/null
+++ b/doc/plugins/contrib/i18nheadinganchors/discussion.mdwn
@@ -0,0 +1,92 @@
+I would not be comfortable with merging this into headinganchors and enabling it by
+default for two reasons:
+
+* it adds a new dependency on [[!cpan Text::Unidecode]]
+* Text::Unidecode specifically documents its transliteration as not being stable
+  across versions
+
+There are several "slugify" libraries available other than Text::Unidecode.
+It isn't clear to me which one is the best. Pandoc also documents
+[an algorithm for generating slugs](http://pandoc.org/MANUAL.html#extension-auto_identifiers),
+and it would be nice if our fallback implementation (with i18n disabled) was compatible
+with Pandoc's, at least for English text.
+
+However! In HTML5, IDs are allowed to contain anything except _space characters_
+(space, newline, tab, CR, FF), so we could consider just passing non-ASCII
+through the algorithm untouched. This [example link to a Russian
+anchor name](#пример) (the output of putting "example" into English-to-Russian
+Google Translate) hopefully works? (Use a small browser window to make it
+clearer where it goes)
+
+So perhaps we could try this Unicode-aware version of what Pandoc documents:
+
+* Remove footnote links if any (this might have to be heuristic, or we could
+  skip this step for a first implementation)
+* Take only the plain text, no markup (passing the heading through HTML::Parser
+  and collecting only the text nodes would be the fully-correct version of this,
+  or we could fake it with regexes and be at least mostly correct)
+* Strip punctuation, using some Unicode-aware definition of what is punctuation:
+  perhaps `s/[^-\w_. ]//gu;` (delete anything that is not a (Unicode-aware) word
+  character, hyphen-minus, underscore, dot or space)
+* Replace spaces with hyphen-minus
+* Force to lower-case with `lc`
+* Strip leading digits and punctuation
+* If the string is empty, use `section`
+* If we already generated a matching identifier, append `-1`, `-2`, etc. until we find
+  an unused identifier
+
+(Or to provide better uniqueness, we could parse the document looking for any existing
+ID, then generate IDs avoiding collisions with any of them.)
+
+This would give us, for example, `## Visiting 北京` → `id="visiting-北京"`
+(where Text::Unidecode would instead transliterate, resulting in `id="visiting-bei-jing"`).
+
+To use these IDs in fragments, I would be inclined to rely on browsers
+supporting [IRIs](https://tools.ietf.org/html/rfc3987): `<a href="#visiting-北京">`.
+
+--[[smcv]]
+
+----
+
+<pre>Some long scrollable text
+.
+.
+.
+.
+.
+.
+.
+.
+.
+.
+.
+.
+.
+.
+.
+.
+.
+<span id="#пример">Example fragment ID in Russian should point here</span>
+.
+.
+.
+.
+.
+.
+.
+.
+.
+.
+.
+.
+.
+.
+.
+.
+.
+.
+.
+.
+.
+.
+.</pre>

close
diff --git a/doc/bugs/pagestats_output_is_not_deterministic.mdwn b/doc/bugs/pagestats_output_is_not_deterministic.mdwn
index 63d52e1..e749a25 100644
--- a/doc/bugs/pagestats_output_is_not_deterministic.mdwn
+++ b/doc/bugs/pagestats_output_is_not_deterministic.mdwn
@@ -9,3 +9,5 @@ for this problem.
 --[[intrigeri]]
 
 [[!tag patch]]
+
+> [[Merged|done]] in 3.20161219 --[[smcv]]

Prune dead links
diff --git a/doc/git.mdwn b/doc/git.mdwn
index 2b92f2d..2c92c9a 100644
--- a/doc/git.mdwn
+++ b/doc/git.mdwn
@@ -39,32 +39,20 @@ think about merging them. This is recommended. :-)
 * [[jonas|JonasSmedegaard]] `git://source.jones.dk/ikiwiki-upstream`
 * [[arpitjain]] `git://github.com/arpitjain11/ikiwiki.git`
 * [[chrysn]] `git://prometheus.amsuess.com/ikiwiki`
-* [[simonraven]] (unavailable) `git://github.com/kjikaqawej/ikiwiki-simon.git`
 * [[schmonz]] `git://github.com/schmonz/ikiwiki.git`
-* [[will]] (unavailable) `http://www.cse.unsw.edu.au/~willu/ikiwiki.git`
-* [[kaizer]] `git://github.com/engla/ikiwiki.git`
-* [[bbb]] (unavailable) `http://git.boulgour.com/bbb/ikiwiki.git`
 * [[KathrynAndersen]] `git://github.com/rubykat/ikiplugins.git`
 * [[ktf]] `git://github.com/ktf/ikiwiki.git`
 * [[tove]] `git://github.com/tove/ikiwiki.git`
 * [[GiuseppeBilotta]] `git://git.oblomov.eu/ikiwiki`
-* [[roktas]] (unavailable) `git://github.com/roktas/ikiwiki.git`
-* [[davrieb|David_Riebenbauer]] (unavailable) `git://git.liegesta.at/git/ikiwiki`
-  ([browse](http://git.liegesta.at/?p=ikiwiki.git;a=summary))
 * [[GustafThorslund]] `http://gustaf.thorslund.org/src/ikiwiki.git`
-* [[users/peteg]] (unavailable) `git://git.hcoop.net/git/peteg/ikiwiki.git`
 * [[privat]] `git://github.com/privat/ikiwiki.git`
 * [[blipvert]] `git://github.com/blipvert/ikiwiki.git`
-* [[bzed|BerndZeimetz]] (unavailable) `git://git.recluse.de/users/bzed/ikiwiki.git`
 * [[wtk]] `git://github.com/wking/ikiwiki.git`
 * [[sunny256]] `git://github.com/sunny256/ikiwiki.git`
-* [[fmarier]] (unavailable) `git://gitorious.org/~fmarier/ikiwiki/fmarier-sandbox.git`
 * [[levitte]] `git://github.com/levitte/ikiwiki.git`
 * jo `git://git.debian.org/users/jo-guest/ikiwiki.git`
   ([browse](http://git.debian.org/?p=users/jo-guest/ikiwiki.git;a=summary))
-* [[timonator]] (unavailable) `git://github.com/timo/ikiwiki.git`
 * [[sajolida]] `http://un.poivron.org/~sajolida/ikiwiki.git/`
-* nezmer (unavailable) `git://gitorious.org/ikiwiki-nezmer/ikiwiki-nezmer.git`
 * [[yds]] `git://github.com/yds/ikiwiki.git`
 * [[pelle]] `git://github.com/hemmop/ikiwiki.git`
 * [[chrismgray]] `git://github.com/chrismgray/ikiwiki.git`
@@ -73,7 +61,6 @@ think about merging them. This is recommended. :-)
 * anderbubble `git://civilfritz.net/ikiwiki.git`
 * frioux `git://github.com/frioux/ikiwiki`
 * llipavsky `git://github.com/llipavsky/ikiwiki`
-* [[cbaines]] (unavailable) `git://git.cbaines.net/ikiwiki`
 * [[mhameed]] `git://github.com/mhameed/ikiwiki.git`
 * [[spalax]] `git://github.com/paternal/ikiwiki.git` ([[browse|https://github.com/paternal/ikiwiki]])
 * [[jcflack]] `git://github.com/jcflack/ikiwiki.git`

Reinstate a git repo that has come back
diff --git a/doc/git.mdwn b/doc/git.mdwn
index 38a2d1c..2b92f2d 100644
--- a/doc/git.mdwn
+++ b/doc/git.mdwn
@@ -47,7 +47,7 @@ think about merging them. This is recommended. :-)
 * [[KathrynAndersen]] `git://github.com/rubykat/ikiplugins.git`
 * [[ktf]] `git://github.com/ktf/ikiwiki.git`
 * [[tove]] `git://github.com/tove/ikiwiki.git`
-* [[GiuseppeBilotta]] (unavailable) `git://git.oblomov.eu/ikiwiki`
+* [[GiuseppeBilotta]] `git://git.oblomov.eu/ikiwiki`
 * [[roktas]] (unavailable) `git://github.com/roktas/ikiwiki.git`
 * [[davrieb|David_Riebenbauer]] (unavailable) `git://git.liegesta.at/git/ikiwiki`
   ([browse](http://git.liegesta.at/?p=ikiwiki.git;a=summary))

Added a comment
diff --git a/doc/forum/__34__S.__34___gets_replace_by___34__a.__34___in_my_ikiwiki/comment_4_b0b4148cde3e30311be4124e5fcfbb76._comment b/doc/forum/__34__S.__34___gets_replace_by___34__a.__34___in_my_ikiwiki/comment_4_b0b4148cde3e30311be4124e5fcfbb76._comment
new file mode 100644
index 0000000..60f5a3d
--- /dev/null
+++ b/doc/forum/__34__S.__34___gets_replace_by___34__a.__34___in_my_ikiwiki/comment_4_b0b4148cde3e30311be4124e5fcfbb76._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="smcv"
+ avatar="http://cdn.libravatar.org/avatar/0ee943fe632ff995f6f0f25b7167d03b"
+ subject="comment 4"
+ date="2017-05-16T07:29:23Z"
+ content="""
+The next ikiwiki release will default to turning off these alphabetically-labelled
+lists, with a `mdwn_alpha_lists` option to turn them back on if required.
+"""]]

Clarify documentation
diff --git a/doc/plugins/mdwn.mdwn b/doc/plugins/mdwn.mdwn
index 3112371..e22f68e 100644
--- a/doc/plugins/mdwn.mdwn
+++ b/doc/plugins/mdwn.mdwn
@@ -40,7 +40,8 @@ might cause formatting that is understood by Discount to be ignored.
   preference to Text::Markdown::Discount. The default is to not use
   MultiMarkdown, and this is recommended.
 * `mdwn_footnotes`: If set to 1, implementations that support it will
-  recognise the PHP Markdown Extra syntax for footnotes. The default
+  recognise the footnote syntax originating in PHP Markdown Extra, with
+  `Footnote reference[^1]` and `[^1]: Footnote definition`. The default
   is 1.
 * `mdwn_alpha_lists`: If set to 1, Text::Markdown::Discount will
   accept letters as well as numbers in ordered list markers. The

mdwn: Don't enable alphabetically labelled ordered lists by default
This avoids misinterpreting initials ("C. S. Lewis was an author"),
the abbreviation for Monsieur ("M. Descartes was a philosopher") and
German page numbering ("S. 42") as ordered lists if they happen to
begin a line.
This only affects the default Discount implementation: Text::Markdown
and Text::MultiMarkdown do not have this feature anyway. A new
mdwn_alpha_list option can be used to restore the old interpretation.
diff --git a/IkiWiki/Plugin/mdwn.pm b/IkiWiki/Plugin/mdwn.pm
index e142fec..9f06c03 100644
--- a/IkiWiki/Plugin/mdwn.pm
+++ b/IkiWiki/Plugin/mdwn.pm
@@ -41,10 +41,19 @@ sub getsetup () {
 			safe => 1,
 			rebuild => 1,
 		},
+		mdwn_alpha_lists => {
+			type => "boolean",
+			example => 0,
+			description => "interpret line like 'A. First item' as ordered list when using Discount?",
+			advanced => 1,
+			safe => 1,
+			rebuild => 1,
+		},
 }
 
 sub checkconfig () {
 	$config{mdwn_footnotes} = 1 unless defined $config{mdwn_footnotes};
+	$config{mdwn_alpha_lists} = 0 unless defined $config{mdwn_alpha_lists};
 }
 
 my $markdown_sub;
@@ -101,6 +110,10 @@ sub htmlize (@) {
 						$flags |= Text::Markdown::Discount::MKD_EXTRA_FOOTNOTE();
 					}
 
+					unless ($config{mdwn_alpha_lists}) {
+						$flags |= Text::Markdown::Discount::MKD_NOALPHALIST();
+					}
+
 					# Workaround for discount's eliding
 					# of <style> blocks.
 					# https://rt.cpan.org/Ticket/Display.html?id=74016
diff --git a/debian/changelog b/debian/changelog
index e2a861c..455e598 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -11,6 +11,10 @@ ikiwiki (3.20170112) UNRELEASED; urgency=medium
   * mdwn: Enable footnotes by default when using the default Discount
     implementation. A new mdwn_footnotes option can be used to disable
     footnotes in MultiMarkdown and Discount.
+  * mdwn: Don't enable alphabetically labelled ordered lists by
+    default when using the default Discount implementation. A new
+    mdwn_alpha_list option can be used to restore the old
+    interpretation.
 
  -- Simon McVittie <smcv@debian.org>  Sun, 14 May 2017 15:34:52 +0100
 
diff --git a/doc/plugins/mdwn.mdwn b/doc/plugins/mdwn.mdwn
index 6b20b7b..3112371 100644
--- a/doc/plugins/mdwn.mdwn
+++ b/doc/plugins/mdwn.mdwn
@@ -7,6 +7,8 @@ It uses the [[ikiwiki/markdown]] minimal markup language.
 This is the standard markup language used by ikiwiki, although some others
 are also available in other plugins.
 
+## Implementations
+
 There are several implementations of markdown support that can be used by
 this plugin. In order of preference:
 
@@ -27,3 +29,21 @@ in the setup file. Note that multimarkdown's metadata and wikilinks
 features are disabled when it's used with ikiwiki. Also note that if the
 `multimarkdown` option is enabled, it takes priority over Discount, which
 might cause formatting that is understood by Discount to be ignored.
+
+
+## Advanced options
+
+* `nodiscount`: If set to 1, Text::Markdown::Discount will not be used
+  even if it is available. The default is to use Discount if available,
+  and this is recommended.
+* `multimarkdown`: If set to 1, Text::MultiMarkdown will be used in
+  preference to Text::Markdown::Discount. The default is to not use
+  MultiMarkdown, and this is recommended.
+* `mdwn_footnotes`: If set to 1, implementations that support it will
+  recognise the PHP Markdown Extra syntax for footnotes. The default
+  is 1.
+* `mdwn_alpha_lists`: If set to 1, Text::Markdown::Discount will
+  accept letters as well as numbers in ordered list markers. The
+  default is 0, to avoid unintended parsing of lines that happen
+  to begin with a letter and a dot, such as "C. S. Lewis was an
+  author" or "M. Descartes was a philosopher".

Added a comment
diff --git a/doc/forum/Error:_template_albumviewer_not_found/comment_2_f2f01f1483c0129874a1fe0536596ab6._comment b/doc/forum/Error:_template_albumviewer_not_found/comment_2_f2f01f1483c0129874a1fe0536596ab6._comment
new file mode 100644
index 0000000..667c019
--- /dev/null
+++ b/doc/forum/Error:_template_albumviewer_not_found/comment_2_f2f01f1483c0129874a1fe0536596ab6._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="qazwsx"
+ avatar="http://cdn.libravatar.org/avatar/a99432c83acad59215abc20267d9dc7a"
+ subject="comment 2"
+ date="2017-05-15T06:19:37Z"
+ content="""
+That make the individual image page show up now. But the sidebar overlaps with the 'next image' and sometimes the image primarily displayed on the page. Any idea how to avoid the overlapping?
+"""]]

mdwn: Enable footnotes by default when using Discount
A new mdwn_footnotes option can be used to disable footnotes in
MultiMarkdown and Discount.
diff --git a/IkiWiki/Plugin/mdwn.pm b/IkiWiki/Plugin/mdwn.pm
index aeb3a3f..e142fec 100644
--- a/IkiWiki/Plugin/mdwn.pm
+++ b/IkiWiki/Plugin/mdwn.pm
@@ -7,6 +7,7 @@ use strict;
 use IkiWiki 3.00;
 
 sub import {
+	hook(type => "checkconfig", id => "mdwn", call => \&checkconfig);
 	hook(type => "getsetup", id => "mdwn", call => \&getsetup);
 	hook(type => "htmlize", id => "mdwn", call => \&htmlize, longname => "Markdown");
 	hook(type => "htmlize", id => "md", call => \&htmlize, longname => "Markdown (popular file extension)", nocreate => 1);
@@ -33,6 +34,17 @@ sub getsetup () {
 			safe => 1,
 			rebuild => 1,
 		},
+		mdwn_footnotes => {
+			type => "boolean",
+			example => 1,
+			description => "enable footnotes in Markdown (where supported)?",
+			safe => 1,
+			rebuild => 1,
+		},
+}
+
+sub checkconfig () {
+	$config{mdwn_footnotes} = 1 unless defined $config{mdwn_footnotes};
 }
 
 my $markdown_sub;
@@ -54,7 +66,13 @@ sub htmlize (@) {
 			}
 			else {
 				$markdown_sub=sub {
-					Text::MultiMarkdown::markdown(shift, {use_metadata => 0});
+					my %flags=( use_metadata => 0 );
+
+					if ($config{mdwn_footnotes}) {
+						$flags{disable_footnotes}=1;
+					}
+
+					Text::MultiMarkdown::markdown(shift, \%flags);
 				}
 			}
 		}
@@ -79,6 +97,10 @@ sub htmlize (@) {
 					# Use the typography plugin instead
 					$flags |= Text::Markdown::Discount::MKD_NOPANTS();
 
+					if ($config{mdwn_footnotes}) {
+						$flags |= Text::Markdown::Discount::MKD_EXTRA_FOOTNOTE();
+					}
+
 					# Workaround for discount's eliding
 					# of <style> blocks.
 					# https://rt.cpan.org/Ticket/Display.html?id=74016
diff --git a/debian/changelog b/debian/changelog
index 08e320f..e2a861c 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -8,6 +8,9 @@ ikiwiki (3.20170112) UNRELEASED; urgency=medium
     a set-but-empty name as if they were not signed in.
   * When the CGI fails, print the error to stderr, not "Died"
   * mdwn: Don't mangle <style> into <elyts> under some circumstances
+  * mdwn: Enable footnotes by default when using the default Discount
+    implementation. A new mdwn_footnotes option can be used to disable
+    footnotes in MultiMarkdown and Discount.
 
  -- Simon McVittie <smcv@debian.org>  Sun, 14 May 2017 15:34:52 +0100
 
diff --git a/doc/bugs/footnotes-look-weird.mdwn b/doc/bugs/footnotes-look-weird.mdwn
index be1e5d5..a821ab4 100644
--- a/doc/bugs/footnotes-look-weird.mdwn
+++ b/doc/bugs/footnotes-look-weird.mdwn
@@ -92,6 +92,10 @@ screen readers), as detailed in [this Stack Overflow discussion][].
 >>> --[[smcv]]
 >>>
 >>>> Makes perfect sense to me. --[[anarcat]]
+>>>>
+>>>>> I have now enabled footnotes in Discount by default, with a new
+>>>>> `mdwn_footnotes` option that can switch them off if they become
+>>>>> problematic. --[[smcv]]
 >>>
 >> For example, to enable footnotes, one needs to call Discount like this:
 >> 

mdwn: Don't mangle <style> into <elyts> under some circumstances
We can ask libdiscount not to elide <style> blocks, which means we
don't have to work around them.
diff --git a/IkiWiki/Plugin/mdwn.pm b/IkiWiki/Plugin/mdwn.pm
index 436f246..aeb3a3f 100644
--- a/IkiWiki/Plugin/mdwn.pm
+++ b/IkiWiki/Plugin/mdwn.pm
@@ -82,10 +82,15 @@ sub htmlize (@) {
 					# Workaround for discount's eliding
 					# of <style> blocks.
 					# https://rt.cpan.org/Ticket/Display.html?id=74016
-					$t=~s/<style/<elyts/ig;
-					my $r=Text::Markdown::Discount::markdown($t, $flags);
-					$r=~s/<elyts/<style/ig;
-					return $r;
+					if (Text::Markdown::Discount->can("MKD_NOSTYLE")) {
+						$flags |= Text::Markdown::Discount::MKD_NOSTYLE();
+					}
+					else {
+						# This is correct for the libmarkdown.so.2 ABI
+						$flags |= 0x00400000;
+					}
+
+					return Text::Markdown::Discount::markdown($t, $flags);
 				}
 			}
 		}
diff --git a/debian/changelog b/debian/changelog
index a92e371..08e320f 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -7,6 +7,7 @@ ikiwiki (3.20170112) UNRELEASED; urgency=medium
     misconfigured nginx servers, and in general treat sessions with
     a set-but-empty name as if they were not signed in.
   * When the CGI fails, print the error to stderr, not "Died"
+  * mdwn: Don't mangle <style> into <elyts> under some circumstances
 
  -- Simon McVittie <smcv@debian.org>  Sun, 14 May 2017 15:34:52 +0100
 
diff --git a/doc/bugs/escaped_style_tag_becomes_elyts.mdwn b/doc/bugs/escaped_style_tag_becomes_elyts.mdwn
index 7095425..336e2ff 100644
--- a/doc/bugs/escaped_style_tag_becomes_elyts.mdwn
+++ b/doc/bugs/escaped_style_tag_becomes_elyts.mdwn
@@ -28,3 +28,7 @@ discuss style markup several times. The first couple of times I saw this happen,
 I thought it was some sort of misguided anti-cross-site-scripting filter...
 
 --[[smcv]]
+
+> [[Fixed|done]] by passing the `MKD_NOSTYLE` flag to Discount instead.
+> Unfortunately this isn't bound by [[!cpan Text::Markdown::Discount]] yet,
+> so for now I'm hard-coding its numeric value. --[[smcv]]

httpauth: Recommend if_not_empty parameter for REMOTE_USER
This is untested, but should hopefully avoid the failure mode
described in [[bugs/Anon_edit_caused_lock_out_on_entire_site_]].
diff --git a/doc/plugins/httpauth.mdwn b/doc/plugins/httpauth.mdwn
index 58a0859..b2f789b 100644
--- a/doc/plugins/httpauth.mdwn
+++ b/doc/plugins/httpauth.mdwn
@@ -41,6 +41,6 @@ users authentication via other methods.
 You have to pass the $remote_user variable to the CGI:
 
     location /ikiwiki.cgi {
-        fastcgi_param REMOTE_USER $remote_user;
+        fastcgi_param REMOTE_USER $remote_user if_not_empty;
         ....
     }

httpauth: If REMOTE_USER is empty, behave as though it was unset
A frequently cut-and-pasted HTTP basic authentication configuration
for nginx sets it to the empty string when not authenticated, which
is not useful.
diff --git a/IkiWiki/Plugin/httpauth.pm b/IkiWiki/Plugin/httpauth.pm
index 76d574b..041eaeb 100644
--- a/IkiWiki/Plugin/httpauth.pm
+++ b/IkiWiki/Plugin/httpauth.pm
@@ -66,7 +66,7 @@ sub auth ($$) {
 	my $cgi=shift;
 	my $session=shift;
 
-	if (defined $cgi->remote_user()) {
+	if (length $cgi->remote_user()) {
 		$session->param("name", $cgi->remote_user());
 	}
 }
@@ -80,7 +80,7 @@ sub formbuilder_setup (@) {
 	my $buttons=$params{buttons};
 
 	if ($form->title eq "signin" &&
-	    ! defined $cgi->remote_user() && defined $config{cgiauthurl}) {
+	    ! length $cgi->remote_user() && defined $config{cgiauthurl}) {
 		my $button_text="Login with HTTP auth";
 		push @$buttons, $button_text;
 
@@ -97,7 +97,7 @@ sub canedit ($$$) {
 	my $cgi=shift;
 	my $session=shift;
 
-	if (! defined $cgi->remote_user() &&
+	if (! length $cgi->remote_user() &&
 	    (! defined $session->param("name") ||
              ! IkiWiki::userinfo_get($session->param("name"), "regdate")) &&
 	    defined $config{httpauth_pagespec} &&
diff --git a/debian/changelog b/debian/changelog
index d3576c5..005c811 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -3,6 +3,9 @@ ikiwiki (3.20170112) UNRELEASED; urgency=medium
   * t/git-cgi.t: Wait 1 second before doing a revert that should work.
     This hopefully fixes a race condition in which the test failed
     around 6% of the time. (Closes: 862494)
+  * Guard against set-but-empty REMOTE_USER CGI variable on
+    misconfigured nginx servers, and in general treat sessions with
+    a set-but-empty name as if they were not signed in.
 
  -- Simon McVittie <smcv@debian.org>  Sun, 14 May 2017 15:34:52 +0100
 
diff --git a/doc/bugs/Anon_edit_caused_lock_out_on_entire_site_.mdwn b/doc/bugs/Anon_edit_caused_lock_out_on_entire_site_.mdwn
index 02d43e8..5fa1aaa 100644
--- a/doc/bugs/Anon_edit_caused_lock_out_on_entire_site_.mdwn
+++ b/doc/bugs/Anon_edit_caused_lock_out_on_entire_site_.mdwn
@@ -81,6 +81,10 @@ It seems I can't log out from nowhere. I've rebuild the wiki from the command li
 > with one of a limited set of authorized usernames.
 >
 > --[[smcv]]
+>
+>> If my theory is correct, ikiwiki git master now works around this, and the
+>> [[plugins/httpauth]] documentation now recommends a more correct configuration.
+>> --[[smcv]]
 
 ---
 

complete last paragraph
diff --git a/doc/bugs/Anon_edit_caused_lock_out_on_entire_site_.mdwn b/doc/bugs/Anon_edit_caused_lock_out_on_entire_site_.mdwn
index 3cbcf60..02d43e8 100644
--- a/doc/bugs/Anon_edit_caused_lock_out_on_entire_site_.mdwn
+++ b/doc/bugs/Anon_edit_caused_lock_out_on_entire_site_.mdwn
@@ -107,5 +107,14 @@ Is there a session file or something to logout this phantom user?
 
 >> I think I've sent right away when you asked, anyway I still have the tarball hanging around. The last *iikb* domains will expire next month though, the wiki will only be accessible by mirror <https://notabug.org/iikb/dev.iikb.org>.
 
->>> I see you have a lot of uncommitted changes. This is probably because
->>> whatever is causing the anonymous accesses to succeed is 
+>>> I see from the tarball that you have a lot of uncommitted changes. This is
+>>> probably because whatever is causing the anonymous accesses to succeed is
+>>> breaking other code paths by giving them an empty username: in particular
+>>> it seems reasonably likely that the `git` plugin will refuse to commit
+>>> changes in that situation.
+>>>
+>>> I would expect that you should be getting error messages on the ikiwiki
+>>> CGI script's `stderr` in this situation. In Apache they would normally
+>>> end up in `error.log`; I don't know how nginx does logging, but it is
+>>> probably something similar. Please check that log for relevant-looking
+>>> error messages. --[[smcv]]

I have a theory
diff --git a/doc/bugs/Anon_edit_caused_lock_out_on_entire_site_.mdwn b/doc/bugs/Anon_edit_caused_lock_out_on_entire_site_.mdwn
index 1691ae1..3cbcf60 100644
--- a/doc/bugs/Anon_edit_caused_lock_out_on_entire_site_.mdwn
+++ b/doc/bugs/Anon_edit_caused_lock_out_on_entire_site_.mdwn
@@ -32,6 +32,9 @@ The `anonok` plugin is **not** enabled
 
 >> Pasted [[here|addplugins]]
 
+>>> I asked three questions and you gave one answer. Please answer the
+>>> other two questions. --[[smcv]]
+
 ---
 
 ## Steps
@@ -50,6 +53,35 @@ None of this phantom user edits are being commited - this [blog post](https://de
 
 It seems I can't log out from nowhere. I've rebuild the wiki from the command line and restarted the nginx server, the phantom user remains logged in and open to anyone willing to edit away the wiki.
 
+> I wonder whether this might be caused by the combination of the `httpauth` plugin
+> with the nginx web server. `httpauth` is known to work correctly with Apache,
+> but you might be the first to use it with nginx.
+>
+> Specifically, I wonder whether `$cgi->remote_user()` might be returning the
+> empty string. Looking at the code, we expect it to be either a non-empty
+> username, or `undef`.
+>
+> Please try installing this CGI script on your nginx server, making it
+> executable and accessing its URL without carrying out any special HTTP
+> authentication (you can delete the script immediately afterwards if
+> you want). If my theory is right, you will see a line `REMOTE_USER=` in
+> the output. Post the output somewhere, or mail it to `smcv` at
+> `debian.org` if you don't want to make it public.
+>
+> ```
+> #!/bin/sh
+> printf 'Content-type: text/plain\r\n\r\n'
+> env | LC_ALL=C sort
+> ```
+>
+> If you do not intend to use
+> [HTTP basic authentication](https://en.wikipedia.org/wiki/Basic_access_authentication),
+> please do not enable the `httpauth` plugin. That plugin is intended to be used
+> in conjunction with a web server configured to require HTTP basic authentication
+> with one of a limited set of authorized usernames.
+>
+> --[[smcv]]
+
 ---
 
 ## Conclusion
@@ -74,3 +106,6 @@ Is there a session file or something to logout this phantom user?
 > share them, please contact <mailto:smcv@debian.org>. --[[smcv]]
 
 >> I think I've sent right away when you asked, anyway I still have the tarball hanging around. The last *iikb* domains will expire next month though, the wiki will only be accessible by mirror <https://notabug.org/iikb/dev.iikb.org>.
+
+>>> I see you have a lot of uncommitted changes. This is probably because
+>>> whatever is causing the anonymous accesses to succeed is 

Added a comment
diff --git a/doc/forum/ikwiki_with_AsciiDoc:_page_cannot_be_rendered/comment_2_750f5682996d5186e48347f5b1723b17._comment b/doc/forum/ikwiki_with_AsciiDoc:_page_cannot_be_rendered/comment_2_750f5682996d5186e48347f5b1723b17._comment
new file mode 100644
index 0000000..b7fb2d4
--- /dev/null
+++ b/doc/forum/ikwiki_with_AsciiDoc:_page_cannot_be_rendered/comment_2_750f5682996d5186e48347f5b1723b17._comment
@@ -0,0 +1,24 @@
+[[!comment format=mdwn
+ username="smcv"
+ avatar="http://cdn.libravatar.org/avatar/0ee943fe632ff995f6f0f25b7167d03b"
+ subject="comment 2"
+ date="2017-05-14T12:01:08Z"
+ content="""
+The AsciiDoc plugin is not part of ikiwiki, and none of the ikiwiki maintainers
+develop or use it. You might get better results by contacting its authors,
+or by reading its source code or the source code of the third-party libraries
+or tools that it uses.
+
+[Searching for the error
+message](https://codesearch.debian.net/search?q=ifeval+invalid+safe+document)
+is probably a good starting point for understanding what is happening here.
+
+I suspect that what is happening might be that the plugin puts asciidoc into
+some sort of \"safe mode\" so that wiki editors cannot cause arbitrary code
+execution, but you are making use of asciidoc features that can execute
+arbitrary code, which the asciidoc implementation forbids.
+
+In general, ikiwiki plugins are expected to arrange for filtering or
+configuration to be carried out so that the ability to edit the wiki does
+not give an attacker the ability to execute arbitrary code on the server.
+"""]]

diff --git a/doc/plugins/mdwn.mdwn b/doc/plugins/mdwn.mdwn
index 62d97b1..6b20b7b 100644
--- a/doc/plugins/mdwn.mdwn
+++ b/doc/plugins/mdwn.mdwn
@@ -20,7 +20,8 @@ this plugin. In order of preference:
 
 [[!cpan Text::MultiMarkdown]] can be used in order to use tables, footnotes,
 and other new features from the markdown variant called
-[multimarkdown](http://fletcherpenney.net/MultiMarkdown/). Multimarkdown is
+[multimarkdown](http://fletcherpenney.net/MultiMarkdown/) (some of which
+are also available in the recommended implementation, Discount). Multimarkdown is
 not enabled by default, but can be turned on via the `multimarkdown` option
 in the setup file. Note that multimarkdown's metadata and wikilinks
 features are disabled when it's used with ikiwiki. Also note that if the

recommend discount over multimarkdown
diff --git a/doc/plugins/mdwn.mdwn b/doc/plugins/mdwn.mdwn
index 8a73083..62d97b1 100644
--- a/doc/plugins/mdwn.mdwn
+++ b/doc/plugins/mdwn.mdwn
@@ -12,6 +12,9 @@ this plugin. In order of preference:
 
 * [Discount](http://www.pell.portland.or.us/~orc/Code/discount/),
   via the [[!cpan Text::Markdown::Discount]] perl module.
+  This implementation is considered to be the default and is strongly
+  recommended, but it is not mandatory because it requires an external
+  C library.
 * The [[!cpan Text::Markdown]] perl module.
 * The [original version of markdown](http://daringfireball.net/projects/markdown/).
 
@@ -20,4 +23,6 @@ and other new features from the markdown variant called
 [multimarkdown](http://fletcherpenney.net/MultiMarkdown/). Multimarkdown is
 not enabled by default, but can be turned on via the `multimarkdown` option
 in the setup file. Note that multimarkdown's metadata and wikilinks
-features are disabled when it's used with ikiwiki.
+features are disabled when it's used with ikiwiki. Also note that if the
+`multimarkdown` option is enabled, it takes priority over Discount, which
+might cause formatting that is understood by Discount to be ignored.

multimarkdown: it's a trap!
diff --git a/doc/todo/toc-with-human-readable-anchors.mdwn b/doc/todo/toc-with-human-readable-anchors.mdwn
index 60edaff..09985a9 100644
--- a/doc/todo/toc-with-human-readable-anchors.mdwn
+++ b/doc/todo/toc-with-human-readable-anchors.mdwn
@@ -31,6 +31,14 @@ doing this:
     add `id` anchors when using [Text::Multimarkdown][] which is
     simply a matter of adding `multimarkdown: 1` in the setup file
 
+    > I don't think multimarkdown is a good solution. It served a useful
+    > purpose when we were defaulting to [[!cpan Text::Markdown]] or to
+    > `markdown.pl`, but now that we're using Discount by default,
+    > Multimarkdown is mostly a trap for the unwary - it's a less predictable
+    > and (in general) less featureful parser than Discount. Ideally we'd
+    > always be using CommonMark or Discount these days, but as
+    > far as I know there's still no API-stable CommonMark library. --[[smcv]]
+
  2. enable the [[plugins/headinganchors]] plugin. if multimarkdown is
     disabled, this can also provide usable identifiers.
 

Added a comment: Use an underlay instead
diff --git a/doc/forum/How_to_use_multiple_template_files_directories__63__/comment_1_cc2ffde6879a2a61353d0b116f6b4954._comment b/doc/forum/How_to_use_multiple_template_files_directories__63__/comment_1_cc2ffde6879a2a61353d0b116f6b4954._comment
new file mode 100644
index 0000000..79429d0
--- /dev/null
+++ b/doc/forum/How_to_use_multiple_template_files_directories__63__/comment_1_cc2ffde6879a2a61353d0b116f6b4954._comment
@@ -0,0 +1,29 @@
+[[!comment format=mdwn
+ username="smcv"
+ avatar="http://cdn.libravatar.org/avatar/0ee943fe632ff995f6f0f25b7167d03b"
+ subject="Use an underlay instead"
+ date="2017-05-14T11:37:13Z"
+ content="""
+The exact setup you asked for is not currently possible because `templatedir`
+only takes one value, but you can get the same practical result with an underlay:
+
+* Create `/Users/XXX/config/ikiwiki/common-files/` or something (the exact name
+  is not significant, use whatever you want)
+* Put your templates in `/Users/XXX/config/ikiwiki/common-files/templates/*.tmpl`
+  (it has to be a `templates/` subdirectory)
+* Add the [[plugins/underlay]] plugin to the `add_plugins` config option
+* Add `/Users/XXX/config/ikiwiki/common-files` to the `add_underlays` config
+  option (same syntax as `add_plugins`)
+
+This is priority 2 from your list: it's \"less important\" than the `templates/`
+subdirectory of the `srcdir`, but \"more important\" than the templates shipped
+with ikiwiki.
+
+If you create non-template pages or attachments in that underlay, they will
+also be considered \"less important\" than pages or attachments of the same
+name in the `srcdir`, but \"more important\" than ikiwiki's `basewiki` underlay.
+I use an underlay like this to make
+[smcv.pseudorandom.co.uk](https://smcv.pseudorandom.co.uk/)
+and [www.pseudorandom.co.uk](https://www.pseudorandom.co.uk/)
+share a stylesheet.
+"""]]

removed
diff --git a/doc/forum/How_to_use_multiple_template_files_directories__63__/comment_1_a333f20af1154bb5f6663874ea716f6c._comment b/doc/forum/How_to_use_multiple_template_files_directories__63__/comment_1_a333f20af1154bb5f6663874ea716f6c._comment
deleted file mode 100644
index 11c302f..0000000
--- a/doc/forum/How_to_use_multiple_template_files_directories__63__/comment_1_a333f20af1154bb5f6663874ea716f6c._comment
+++ /dev/null
@@ -1,16 +0,0 @@
-[[!comment format=mdwn
- username="smcv"
- avatar="http://cdn.libravatar.org/avatar/0ee943fe632ff995f6f0f25b7167d03b"
- subject="You can do almost this with an underlay"
- date="2017-05-14T11:27:53Z"
- content="""
-The exact situation that you have described is not currently possible, because
-`templatedir` can only have one value. But you can have a very similar practical result
-like this:
-
-* Create `/Users/XXX/config/ikiwiki/underlay/` or something (the name is unimportant,
-  you can use anything)
-* Put your templates in `/Users/XXX/config/ikiwiki/underlay/templates/`
-* Include `/Users/XXX/config/ikiwiki/underlay` in the `underlaydirs` configuration
-  option (the syntax is the same as `add_plugins`)
-"""]]

Added a comment: You can do almost this with an underlay
diff --git a/doc/forum/How_to_use_multiple_template_files_directories__63__/comment_1_a333f20af1154bb5f6663874ea716f6c._comment b/doc/forum/How_to_use_multiple_template_files_directories__63__/comment_1_a333f20af1154bb5f6663874ea716f6c._comment
new file mode 100644
index 0000000..11c302f
--- /dev/null
+++ b/doc/forum/How_to_use_multiple_template_files_directories__63__/comment_1_a333f20af1154bb5f6663874ea716f6c._comment
@@ -0,0 +1,16 @@
+[[!comment format=mdwn
+ username="smcv"
+ avatar="http://cdn.libravatar.org/avatar/0ee943fe632ff995f6f0f25b7167d03b"
+ subject="You can do almost this with an underlay"
+ date="2017-05-14T11:27:53Z"
+ content="""
+The exact situation that you have described is not currently possible, because
+`templatedir` can only have one value. But you can have a very similar practical result
+like this:
+
+* Create `/Users/XXX/config/ikiwiki/underlay/` or something (the name is unimportant,
+  you can use anything)
+* Put your templates in `/Users/XXX/config/ikiwiki/underlay/templates/`
+* Include `/Users/XXX/config/ikiwiki/underlay` in the `underlaydirs` configuration
+  option (the syntax is the same as `add_plugins`)
+"""]]

Added a comment
diff --git a/doc/forum/Error:_template_albumviewer_not_found/comment_1_9969da19fd2463a5df8ed54606a0f995._comment b/doc/forum/Error:_template_albumviewer_not_found/comment_1_9969da19fd2463a5df8ed54606a0f995._comment
new file mode 100644
index 0000000..be17eeb
--- /dev/null
+++ b/doc/forum/Error:_template_albumviewer_not_found/comment_1_9969da19fd2463a5df8ed54606a0f995._comment
@@ -0,0 +1,21 @@
+[[!comment format=mdwn
+ username="smcv"
+ avatar="http://cdn.libravatar.org/avatar/0ee943fe632ff995f6f0f25b7167d03b"
+ subject="comment 1"
+ date="2017-05-14T11:00:47Z"
+ content="""
+The album plugin is not exactly polished - it still hasn't been merged into mainstream
+ikiwiki despite being written by someone who is now an ikiwiki co-maintainer (me),
+because I'm not actively using or developing it at the moment.
+
+I think you might need to use `viewertemplate=albumviewer.tmpl` instead of just
+`viewertemplate=albumviewer` - or miss out that parameter altogether, because
+`albumviewer.tmpl` is the default anyway. If you use `albumviewer` without the
+extension, I think ikiwiki will be looking for an ordinary page (`albumviewer.mdwn` or
+something) that contains a [[templatebody directive|ikiwiki/directive/templatebody]],
+rather than a `.tmpl` file.
+
+If I'm right about that, the `prevtemplate` and `nexttemplate` parameters are
+also going to have the same issue - but you probably haven't noticed that
+because the [[plugins/trail]] links let you navigate anyway.
+"""]]

Added a comment: you can't use and/or/! inside the page() parameter, move them outside
diff --git a/doc/forum/Limit_pagespec_to_a_certain_depth/comment_2_5fef3835d207c454f4642879bdca7d9b._comment b/doc/forum/Limit_pagespec_to_a_certain_depth/comment_2_5fef3835d207c454f4642879bdca7d9b._comment
new file mode 100644
index 0000000..8e59e12
--- /dev/null
+++ b/doc/forum/Limit_pagespec_to_a_certain_depth/comment_2_5fef3835d207c454f4642879bdca7d9b._comment
@@ -0,0 +1,28 @@
+[[!comment format=mdwn
+ username="smcv"
+ avatar="http://cdn.libravatar.org/avatar/0ee943fe632ff995f6f0f25b7167d03b"
+ subject="you can't use and/or/! inside the page() parameter, move them outside"
+ date="2017-05-14T10:49:53Z"
+ content="""
+`page(x)` interprets _x_ as a glob (a wildcard pattern like the ones in Unix and DOS,
+with `*` and `?` as special characters), not as a full pagespec. I think you want:
+
+    page(*) and !*/*
+
+which is shorthand for
+
+    page(*) and !glob(*/*)
+
+The only difference between `page` and `glob` is that `glob` accepts both
+(HTML) pages and attachments, while `page` only accepts pages. For instance on
+ikiwiki installations that use the standard basewiki,
+
+    [[!map pages=\"glob(*)\"]]
+
+matches both [sandbox](/sandbox/) (a page) and [style.css](/style.css) (an
+attachment at the top level), while
+
+    [[!map pages=\"page(*)\"]]
+
+matches [sandbox](/sandbox/) but not [style.css](/style.css).
+"""]]

fix syntax
diff --git a/doc/forum/Limit_pagespec_to_a_certain_depth.mdwn b/doc/forum/Limit_pagespec_to_a_certain_depth.mdwn
index b1d7e49..75a5b9c 100644
--- a/doc/forum/Limit_pagespec_to_a_certain_depth.mdwn
+++ b/doc/forum/Limit_pagespec_to_a_certain_depth.mdwn
@@ -1 +1 @@
-I'd like my index page of my wiki to show me a list of all the files in the wiki's root and only the names of "folder-pages" (those pages that are named the same way as the folders). I used the map directive to create a list, but I can't come up with a way to limit the depth of the pagespec, so everything inside of the folders is matched and listed as well, which is not what I want. Is there a way to limit the page spec's depth or make it exclude pages in subfolders? I tried `[[!map  pages="page(* and !*/*)"]]` or `[[!map  pages="page(* and !foobar/*)"]]`, but both exclude the "folder-pages" (either all of them (first case) or the ones that I have specified (second case)).
+I'd like my index page of my wiki to show me a list of all the files in the wiki's root and only the names of "folder-pages" (those pages that are named the same way as the folders). I used the map directive to create a list, but I can't come up with a way to limit the depth of the pagespec, so everything inside of the folders is matched and listed as well, which is not what I want. Is there a way to limit the page spec's depth or make it exclude pages in subfolders? I tried `\[[!map  pages="page(* and !*/*)"]]` or `\[[!map  pages="page(* and !foobar/*)"]]`, but both exclude the "folder-pages" (either all of them (first case) or the ones that I have specified (second case)).

Piny: mothballing
diff --git a/doc/ikiwikiusers.mdwn b/doc/ikiwikiusers.mdwn
index 9f453f7..4dbcf2c 100644
--- a/doc/ikiwikiusers.mdwn
+++ b/doc/ikiwikiusers.mdwn
@@ -16,8 +16,6 @@ Ikiwiki Hosting
 [[!table data="""
 Name                                              | Ikiwiki Configuration                                                             | Costs
 [Branchable](http://branchable.com/)              | Open configuration with [ikiwiki-hosting](http://ikiwiki-hosting.branchable.com/) | Free for free software, otherwise involves fees
-[Piny.be](http://piny.be/)                        | Restricted configuration with [Piny](http://piny.be/piny-code/)                   | Free for non-profit purposes (including open source projects); commercial activity disallowed.
-[FairlyStable.org](http://fairlystable.org/)      | Restricted configuration with [Piny](http://piny.be/piny-code/)                   | Free for small projects, otherwise involves fees
 [FreedomBox](https://wiki.debian.org/FreedomBox/) | Web configuration with Plinth                                                     | Runs on your home's private cloud server
 """]]
 

diff --git a/doc/forum/How_to_use_themes__63__.mdwn b/doc/forum/How_to_use_themes__63__.mdwn
new file mode 100644
index 0000000..b91d541
--- /dev/null
+++ b/doc/forum/How_to_use_themes__63__.mdwn
@@ -0,0 +1,5 @@
+So I'm trying out ikiwiki locally on a behind-a-firewall server, and I'm having trouble activating themes.  
+
+I added "theme" to my config file's "add_plugins" directive, and uncommented the "theme: actiontabs" line. I then ran "ikwiki --setup wiki.setup" and... no change on reload.
+
+I'm on Ubuntu 16.04. Any idea what I'm doing wrong? --STrRedWolf

diff --git a/doc/forum/Error:_template_albumviewer_not_found.mdwn b/doc/forum/Error:_template_albumviewer_not_found.mdwn
new file mode 100644
index 0000000..5f4ee69
--- /dev/null
+++ b/doc/forum/Error:_template_albumviewer_not_found.mdwn
@@ -0,0 +1,25 @@
+I'm having some trouble to have the album plug-in working.
+
+With ikiwiki version 3.20170111 installed via pkgsrc on macOS 10.12.4, I installed the album plugin for Ikiwiki following the instruction in the section 'Manual installation' at https://ikiwiki.info/plugins/contrib/album/.  The problem is that after 'ikiwiki --rebuild --verbose --setup mysite.setup --gettime', the page with
+
+```
+# Images
+[[!sidebar content=""]]
+[[!album 
+  sort="age"
+  size="full"
+  thumbnailsize="96x96"
+  viewertemplate="albumviewer"
+  prevtemplate="albumprev"
+  nexttemplate="albumnext"]]
+```
+
+builds correctly into an page with a list of images, but if I click any individual thumbnail to get to a page that's supposed to contain just that one image, I see the following exposed code 
+
+```
+[[!albumimage Error: template albumviewer not found]]
+```
+
+I verified that I do have albumviewer.tmpl in sourcedir/templates/.
+
+Any idea why and how to fix it?

Added a comment
diff --git a/doc/forum/ikiwiki_can__39__t_find_imagemagick/comment_11_02ec53cadf9e7d7efe75e8eeb9c9230b._comment b/doc/forum/ikiwiki_can__39__t_find_imagemagick/comment_11_02ec53cadf9e7d7efe75e8eeb9c9230b._comment
new file mode 100644
index 0000000..88afd34
--- /dev/null
+++ b/doc/forum/ikiwiki_can__39__t_find_imagemagick/comment_11_02ec53cadf9e7d7efe75e8eeb9c9230b._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="DataComputist"
+ avatar="http://cdn.libravatar.org/avatar/a17d83194742f0bd57df1e9fc6858c8f"
+ subject="comment 11"
+ date="2017-05-08T21:16:18Z"
+ content="""
+What should be the correct order for this to work?
+
+>First came brew, then the os, then pkgsrc.
+
+?
+"""]]

diff --git a/doc/forum/How_to_use_multiple_template_files_directories__63__.mdwn b/doc/forum/How_to_use_multiple_template_files_directories__63__.mdwn
new file mode 100644
index 0000000..45724ba
--- /dev/null
+++ b/doc/forum/How_to_use_multiple_template_files_directories__63__.mdwn
@@ -0,0 +1,7 @@
+For an ikiwiki source directory, I already have multiple paths for storing template files:
+
+1. /opt/pkg/share/ikiwiki/templates/*.tmpl which came to be as a result of installing ikiwiki via pkgsrc on macOS;
+2. /Users/XXX/config/ikiwiki/templatedir/, a manually created directory for storing *.tmpl files potentially modified by myself but intended to use for all my ikiwiki sites;
+3. /Ysers/XXX/mywiki-srcdir/templates/*.tmpl, which according to https://ikiwiki.info/usage/ is another option to store template files. I intend to store template files potentially modified and only suitable for the particular instance 'mywiki-srcdir'.
+
+I want all three paths to be usable for compiling mywiki-scrdir but want 3 be the default, which should fall back to 2 if a file is missing, which in turn should fall back to 1, if a file is missing.