Recent changes to this wiki:

Added a comment
diff --git a/doc/forum/Some_thoughts_about_Ikiwiki/comment_1_db32786dd1c1022cec983a12a30b2b17._comment b/doc/forum/Some_thoughts_about_Ikiwiki/comment_1_db32786dd1c1022cec983a12a30b2b17._comment
new file mode 100644
index 000000000..524ca09c3
--- /dev/null
+++ b/doc/forum/Some_thoughts_about_Ikiwiki/comment_1_db32786dd1c1022cec983a12a30b2b17._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="jon+ikiwiki@663db4cb26e845748f3e7e6d51eeb26c6014f1c3"
+ nickname="jon+ikiwiki"
+ avatar="http://cdn.libravatar.org/avatar/2a3bcb34947fceef61560bd8a2931957"
+ subject="comment 1"
+ date="2018-02-22T16:30:42Z"
+ content="""
+I have basically been on a similar journey recently. Honestly I would like to move on from IkiWiki myself, and I agree with most of your first points (except the OOP one, which I think is a red herring). I haven't done a deep evaluation of other static site generators, just a shallow one; but I haven't looked at only Python. But results across other languages are much the same. A few core concepts in IkiWiki are very *right*, IMHO: the pagespec/wikilink rules amongst them. -- [[Jon]]
+"""]]

Some thoughts about Ikiwiki
diff --git a/doc/forum/Some_thoughts_about_Ikiwiki.mdwn b/doc/forum/Some_thoughts_about_Ikiwiki.mdwn
new file mode 100644
index 000000000..a204bf5d8
--- /dev/null
+++ b/doc/forum/Some_thoughts_about_Ikiwiki.mdwn
@@ -0,0 +1,20 @@
+*Note : In this post, I only consider Ikiwiki as a static site compiler, not a wiki engine.*
+
+I have been using Ikiwiki for some years, writing [[several packages|spalax]], making some small contributions, and I somehow have the feeling that IkiWiki is getting old (maybe it has some technological debt). Among the things I am missing is:
+
+* it is written in Perl, and I don't know Perl;
+* I think it could benefit from using OOP (object oriented programming);
+* the template system is very very limited (compared to some modern template engines, like [Jinja2](http://jinja.pocoo.org/) or [Django](https://docs.djangoproject.com/en/2.0/topics/templates/)).
+
+So I looked at other static site generators (only in Python, because it is the only programming language I master). My thought was: since Ikiwiki is old (as [Joeyh said](https://joeyh.name/blog/entry/twenty_years_of_free_software_--_part_1_ikiwiki/): *it was a static site generator before we knew what those were. It wasn't the first, but it broke plenty of new ground*), modern static site generators should be as good as Ikiwiki, with some design mistakes fixed, right? I was wrong.
+
+Here are a few things that Ikiwiki does well, that other tools miss (and I might be biaised, but do no think that my opinion about it is an aversion to change: I do think Ikiwiki does it better).
+
+* The other tools I tried use separate pages from images from data (each one is in its own tree directory structure). There are workarounds, but [they might have caveats](https://github.com/getnikola/nikola/issues/2266#issuecomment-365922299). This might be linked to the next point:
+* [[Wikilinks|ikiwiki/wikilink]] are great! I did not like them at first (I feared that if a page `foo` was linked to `bar`, this link might be broken later if another page `bar` was created, with a higher precedence than the original one). But I ended up liking it.
+* The way other tools can be extended seems not clean: I do not want to write complex stuff or have to use regexp to match my new directive (or wathever it is called). Ikiwiki [[directive|ikiwiki/directive]] are great: writing a new directive is both very simple and very effective.
+* Ikiwiki documentation is great (for other tools I tried, it is acceptable for using the static site, but poor for extending it).
+
+Well, this post was meant to congratulate [[joey]] and every ikiwiki contributors: its design is great (I already used "great" a few times, sorry for my poor vocabulary). What next? I can hope that every single user and contributor of ikiwiki decide to rewrite it in Python3 (to keep the great ideas, integrate some more modern tools, and avoid a fork), or, to be more realistic, I could go back in time to convince/bribe/coerce Joey to write it in Python (which would not solve everything, but would make it easier for me to contribute). A more serious path would be to have a look at [staticsite](https://github.com/spanezz/staticsite/) which is written by Enrico Zini, who seems to want the same thing I want: a "more modern" ikiwiki.
+
+-- Louis

remove template that does not belong here
Finnish translation of another template, this is not the place to put
it. The ikiwiki-l10n can iirc manage such translations.
diff --git a/doc/templates/tiimi.mdwn b/doc/templates/tiimi.mdwn
deleted file mode 100644
index e9b65e813..000000000
--- a/doc/templates/tiimi.mdwn
+++ /dev/null
@@ -1,20 +0,0 @@
-[[!templatebody <<ENDBODY
-
-<table border="1">
-<tr><th colspan="4"><TMPL_VAR nimi></th></tr>
-
-<TMPL_IF status>
-<tr><td>Status:</td><td colspan="3"></td></td>
-</TMPL_IF>
-<TMPL_IF erityistä>
-<tr><td>Erityistä:</td><td colspan="3"></td></td>
-</TMPL_IF>
-
-<tr><td>Sidosryhmät / asiakkaat</td><td>Aiheet</td><td>Vastuuhenkilöt</td><td>Jäsenet</td></tr>
-<tr><td><TMPL_VAR asiakkaat</td><td><TMPL_VAR aiheet></td><td><TMPL_VAR vastuuhenkilöt></td><td><TMPL_VAR jäsenet></td></tr>
-</table>
-
-ENDBODY]]
-
-Pakolliset parametrit: nimi, asiakkaat, aiheet, vastuuhenkilöt, jäsenet
-Valinnaiset parametrit: status, erityistä

parametrien dokumentointi
diff --git a/doc/templates/tiimi.mdwn b/doc/templates/tiimi.mdwn
index fc20cf58e..e9b65e813 100644
--- a/doc/templates/tiimi.mdwn
+++ b/doc/templates/tiimi.mdwn
@@ -11,7 +11,10 @@
 </TMPL_IF>
 
 <tr><td>Sidosryhmät / asiakkaat</td><td>Aiheet</td><td>Vastuuhenkilöt</td><td>Jäsenet</td></tr>
-<tr><td></td><td><TMPL_VAR aiheet></td><td><TMPL_VAR vastuuhenkilöt></td><td><TMPL_VAR jäsenet></td></tr>
+<tr><td><TMPL_VAR asiakkaat</td><td><TMPL_VAR aiheet></td><td><TMPL_VAR vastuuhenkilöt></td><td><TMPL_VAR jäsenet></td></tr>
 </table>
 
 ENDBODY]]
+
+Pakolliset parametrit: nimi, asiakkaat, aiheet, vastuuhenkilöt, jäsenet
+Valinnaiset parametrit: status, erityistä

First post
diff --git a/doc/templates/tiimi.mdwn b/doc/templates/tiimi.mdwn
new file mode 100644
index 000000000..fc20cf58e
--- /dev/null
+++ b/doc/templates/tiimi.mdwn
@@ -0,0 +1,17 @@
+[[!templatebody <<ENDBODY
+
+<table border="1">
+<tr><th colspan="4"><TMPL_VAR nimi></th></tr>
+
+<TMPL_IF status>
+<tr><td>Status:</td><td colspan="3"></td></td>
+</TMPL_IF>
+<TMPL_IF erityistä>
+<tr><td>Erityistä:</td><td colspan="3"></td></td>
+</TMPL_IF>
+
+<tr><td>Sidosryhmät / asiakkaat</td><td>Aiheet</td><td>Vastuuhenkilöt</td><td>Jäsenet</td></tr>
+<tr><td></td><td><TMPL_VAR aiheet></td><td><TMPL_VAR vastuuhenkilöt></td><td><TMPL_VAR jäsenet></td></tr>
+</table>
+
+ENDBODY]]

improve reply wording with a crosslink
diff --git a/doc/todo/Restrict_page_viewing.mdwn b/doc/todo/Restrict_page_viewing.mdwn
index d40cee6d1..69b15a187 100644
--- a/doc/todo/Restrict_page_viewing.mdwn
+++ b/doc/todo/Restrict_page_viewing.mdwn
@@ -41,6 +41,7 @@ much more maintainable htaccess file.
 >>>>> If you use the httpauth and the cgiauthurl method, you can restrict a path 
 >>>>> like /private/* to be accessible only under the authenticated request uri.
 
->>>>>> Note that if editing is enabled, then you should set the restriction in locked_pages too
+>>>>>> Note that if editing is enabled, then you should set the restriction in
+>>>>>> [[plugins/lockedit]]'s locked_pages too
 >>>>>> or they may be able to view pages by editing the page= value in the editor's
 >>>>>> query string. --[mjr](http://mjr.towers.org.uk/)

Try to explain editor loophole to viewing restrictions
diff --git a/doc/todo/Restrict_page_viewing.mdwn b/doc/todo/Restrict_page_viewing.mdwn
index 20b59cb13..d40cee6d1 100644
--- a/doc/todo/Restrict_page_viewing.mdwn
+++ b/doc/todo/Restrict_page_viewing.mdwn
@@ -40,3 +40,7 @@ much more maintainable htaccess file.
 
 >>>>> If you use the httpauth and the cgiauthurl method, you can restrict a path 
 >>>>> like /private/* to be accessible only under the authenticated request uri.
+
+>>>>>> Note that if editing is enabled, then you should set the restriction in locked_pages too
+>>>>>> or they may be able to view pages by editing the page= value in the editor's
+>>>>>> query string. --[mjr](http://mjr.towers.org.uk/)

typo fixed
diff --git a/doc/tips/optimising_ikiwiki.mdwn b/doc/tips/optimising_ikiwiki.mdwn
index 0c67e606c..2999573ac 100644
--- a/doc/tips/optimising_ikiwiki.mdwn
+++ b/doc/tips/optimising_ikiwiki.mdwn
@@ -207,7 +207,7 @@ The best way to do it is:
 
 * Install [[!cpan Devel::NYTProf]]
 * `PERL5OPT=-d:NYTProf`
-* `export PER5OPT`
+* `export PERL5OPT`
 * Now run ikiwiki as usual, and it will generate a `nytprof.out` file.
 * Run `nytprofhtml` to generate html files.
 * Those can be examined to see what parts of ikiwiki are being slow.

diff --git a/doc/tips/optimising_ikiwiki/discussion.mdwn b/doc/tips/optimising_ikiwiki/discussion.mdwn
index 2b043787a..f8c01fe51 100644
--- a/doc/tips/optimising_ikiwiki/discussion.mdwn
+++ b/doc/tips/optimising_ikiwiki/discussion.mdwn
@@ -18,3 +18,5 @@ What do I do now? Where is the TROUBLESHOOTING file located? --[[users/svetlana]
 
 
 Found <https://metacpan.org/pod/Devel::NYTProf#%22Profile-data-incomplete,-...%22-or-%22Profile-format-error:-...%22>, however, "export NYTPROF=sigexit=1" does not help either. Running "unset PER5OPT" before running nytprofhtml does not help either as well. That leaves this problem unsolved still. --[[users/svetlana]] Fri Feb  2 08:03:13 2018
+
+Fixed by exporting "PERL5OPT" rather than "PER5OPT"; fixing typo in documentation... --[[users/svetlana]]

more details
diff --git a/doc/tips/optimising_ikiwiki/discussion.mdwn b/doc/tips/optimising_ikiwiki/discussion.mdwn
index 0bb863471..2b043787a 100644
--- a/doc/tips/optimising_ikiwiki/discussion.mdwn
+++ b/doc/tips/optimising_ikiwiki/discussion.mdwn
@@ -15,3 +15,6 @@ Following the steps "Install Devel::NYTProf. PERL5OPT=-d:NYTProf. export PER5OPT
 Typing "export NYTPROF=sigexit=int,hup,pipe,bus,segv,term" and repeating ikiwiki and nytprofhtml commands has no effect.
 
 What do I do now? Where is the TROUBLESHOOTING file located? --[[users/svetlana]]
+
+
+Found <https://metacpan.org/pod/Devel::NYTProf#%22Profile-data-incomplete,-...%22-or-%22Profile-format-error:-...%22>, however, "export NYTPROF=sigexit=1" does not help either. Running "unset PER5OPT" before running nytprofhtml does not help either as well. That leaves this problem unsolved still. --[[users/svetlana]] Fri Feb  2 08:03:13 2018

NYTProf: Profile data incomplete, inflate error -5 ((null))
diff --git a/doc/tips/optimising_ikiwiki/discussion.mdwn b/doc/tips/optimising_ikiwiki/discussion.mdwn
new file mode 100644
index 000000000..0bb863471
--- /dev/null
+++ b/doc/tips/optimising_ikiwiki/discussion.mdwn
@@ -0,0 +1,17 @@
+# Profile data incomplete
+
+Following the steps "Install Devel::NYTProf. PERL5OPT=-d:NYTProf. export PER5OPT. Now run ikiwiki as usual, and it will generate a nytprof.out file. Run nytprofhtml to generate html files.", get the following error message:
+
+    [svetlana /home/private/wiki]$ PERL5OPT=-d:NYTProf
+    [svetlana /home/private/wiki]$ export PER5OPT
+    [svetlana /home/private/wiki]$ ikiwiki --setup ikiwiki.setup 
+    skipping bad filename free/To-dos.mdwn~
+    [svetlana /home/private/wiki]$ nytprofhtml
+    Reading nytprof.out
+    Profile data incomplete, inflate error -5 ((null)) at end of input file, perhaps the process didn't exit cleanly or the
+     file has been truncated  (refer to TROUBLESHOOTING in the documentation)
+    [svetlana /home/private/wiki]$ 
+
+Typing "export NYTPROF=sigexit=int,hup,pipe,bus,segv,term" and repeating ikiwiki and nytprofhtml commands has no effect.
+
+What do I do now? Where is the TROUBLESHOOTING file located? --[[users/svetlana]]

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 c2ea4f26d..c21b9668d 100644
--- a/doc/bugs/imagemagick_6.9.8_test_suite_failure.mdwn
+++ b/doc/bugs/imagemagick_6.9.8_test_suite_failure.mdwn
@@ -53,3 +53,14 @@ Is this is a known problem and is there maybe a fix for this issue?
 > 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]]
+
+>> I see the same issue on Fedora, with ImageMagic 6.9.9-19:
+>> 
+>>     #   Failed test at t/img.t line 119.
+>>     #          got: 'no image: Exception 435: unable to open image `:t/tmp/out/imgconversions/10x-redsquare.png': No such file or directory @ error/blob.c/OpenBlob/2701'
+>>     #     expected: '10x10'
+>>     [...]
+>> 
+>> So it seems, that an empty coder prefix is not accepted anymore. To me it seems that [this commit](https://github.com/ImageMagick/ImageMagick/commit/4bc9b6b) changed the behavior. Unfortunately, the commit message doens't tell us about the reasons behind. The commit is included from version 6.9.8-3 on.
+
+

urlfix
diff --git a/doc/users/svetlana.mdwn b/doc/users/svetlana.mdwn
index cdddd6629..9d309e0dd 100644
--- a/doc/users/svetlana.mdwn
+++ b/doc/users/svetlana.mdwn
@@ -1,6 +1,6 @@
 I speak English and Russian. I use ikiwiki at [my personal site](http://svetlana.nfshost.com).
 
-I also help a few software projects localize their documentation -- [guppy](http://guppy.branchable.com).
+I also help a few software projects localize their documentation -- [guppy](http://guppy.branchable.com/index.en.html).
 
 I enjoy ikiwiki.
 

update
diff --git a/doc/users/svetlana.mdwn b/doc/users/svetlana.mdwn
index 6fca6dc1d..cdddd6629 100644
--- a/doc/users/svetlana.mdwn
+++ b/doc/users/svetlana.mdwn
@@ -1,7 +1,8 @@
 I speak English and Russian. I use ikiwiki at [my personal site](http://svetlana.nfshost.com).
 
-I also help a few software projects localize their documentation -- [vy](http://vy.branchable.com) and [guppy](http://guppy.branchable.com).
+I also help a few software projects localize their documentation -- [guppy](http://guppy.branchable.com).
 
 I enjoy ikiwiki.
 
 I am testing the po and osm plugins.
+

%?
diff --git a/doc/ikiwiki/directive/img/discussion.mdwn b/doc/ikiwiki/directive/img/discussion.mdwn
index 6fc28e75e..03cd4e6b3 100644
--- a/doc/ikiwiki/directive/img/discussion.mdwn
+++ b/doc/ikiwiki/directive/img/discussion.mdwn
@@ -32,3 +32,7 @@ It does show a clickable question mark for ikiwiki.cgi?page=utah-2006-100-180.pn
 I have a local copy of the [[rcs/Git]] page.  After installing the `imagemagick-perl` package some of the elements display and others are missing including the page outlines with turned corners and all of the yellow folders.  Ideas?
 
 -- [[RonParker]]
+
+# Percentage size
+
+Would like an image to occupy 50% of the page width. Is this available? With what syntax? --[[svetlana]]

Auto-remove tag pages?
diff --git a/doc/plugins/tag/discussion.mdwn b/doc/plugins/tag/discussion.mdwn
index dfd749252..ad6b8d6ff 100644
--- a/doc/plugins/tag/discussion.mdwn
+++ b/doc/plugins/tag/discussion.mdwn
@@ -29,3 +29,8 @@ See [[todo/auto-create tag pages according to a template]]
 -- Jeremy Schultz <jeremy.schultz@uleth.ca>
 
 `tag_autocreate` can now enable this. --[[Joey]] 
+
+
+# Auto-remove tag pages?
+
+When zero pages are tagged with a particular tag, its page could be auto-removed. Would that make sense? Doesn't look like this is already implemented. --[[user/svetlana]]

diff --git a/doc/plugins/rename/discussion.mdwn b/doc/plugins/rename/discussion.mdwn
index ff172e728..8412f0561 100644
--- a/doc/plugins/rename/discussion.mdwn
+++ b/doc/plugins/rename/discussion.mdwn
@@ -9,3 +9,7 @@ Expected result, updated link inside of the page from 'baz2.png' to a relative o
 Actual result, the link inside of the page is not updated. It stays a broken link.
 
 --[[svetlana]]
+
+# Can not rename individual attachments files
+
+It looks like I can not rename/move individual attachments files (those that are not pages) using the web interface. I need to do this on the fs. Perhaps that's intended but I am not sure. --[[svetlana]]

diff --git a/doc/plugins/rename/discussion.mdwn b/doc/plugins/rename/discussion.mdwn
new file mode 100644
index 000000000..ff172e728
--- /dev/null
+++ b/doc/plugins/rename/discussion.mdwn
@@ -0,0 +1,11 @@
+# Bug with attachments in parent directory
+
+1. Create page '/foo', attach file baz2.png (it will be 'foo/baz2.png')
+1. Create '/foo/bar' page with '[[baz2.png]]' contents, this works and shows the image
+1. Rename /foo/bar to /iliketrains/bar
+
+Expected result, updated link inside of the page from 'baz2.png' to a relative or absolute path that works.
+
+Actual result, the link inside of the page is not updated. It stays a broken link.
+
+--[[svetlana]]

okay, sorry about that
This reverts commit b7263302c7d74d25b15f87359a633fc3cca857a3
diff --git a/doc/index.mdwn b/doc/index.mdwn
index 7050f9779..e0e401656 100644
--- a/doc/index.mdwn
+++ b/doc/index.mdwn
@@ -10,7 +10,7 @@ array of [[plugins]].
 Alternatively, think of ikiwiki as a particularly flexible static
 site generator with some dynamic features.
 
-. .
+
 
 ## using ikiwiki
 

Testing if this is really so easily editable by the public? (my ikiwiki 'instance' is) How is it not constantly being riddled with spam?
diff --git a/doc/index.mdwn b/doc/index.mdwn
index e0e401656..7050f9779 100644
--- a/doc/index.mdwn
+++ b/doc/index.mdwn
@@ -10,7 +10,7 @@ array of [[plugins]].
 Alternatively, think of ikiwiki as a particularly flexible static
 site generator with some dynamic features.
 
-
+. .
 
 ## using ikiwiki
 

404, no 'wmd'
diff --git a/doc/plugins/wmd/discussion.mdwn b/doc/plugins/wmd/discussion.mdwn
index 191004dc3..7b5b1d7d0 100644
--- a/doc/plugins/wmd/discussion.mdwn
+++ b/doc/plugins/wmd/discussion.mdwn
@@ -20,3 +20,5 @@ Other conversations:
 >> on line 247.  --[[simonraven]]
 
 >>> Well, I re-figured out that I needed a TMPL_VAR FOO in the template(s). --[[simonraven]]
+
+<https://code.google.com/archive/p/pagedown/> is 404, <https://github.com/edrohler/pagedown-core> claims to be its copy but it does not have 'wmd' directory inside. What are the current steps to follow here? --[[svetlana]]

move main documentation to converter's README file
diff --git a/doc/tips/convert_moinmoin_to_ikiwiki.mdwn b/doc/tips/convert_moinmoin_to_ikiwiki.mdwn
index 142a8e81f..40f01aa51 100644
--- a/doc/tips/convert_moinmoin_to_ikiwiki.mdwn
+++ b/doc/tips/convert_moinmoin_to_ikiwiki.mdwn
@@ -10,101 +10,4 @@ The MoinMoin side of things was completely re-written by [[anarcat]] and is curr
 
 It doesn't feature support to migrate from Tikiwiki anymore and focuses on MoinMoin support.
 
-Issues can be filed on the [project page](https://gitlab.com/anarcat/moin2iki/).
-
-[[!toc levels=2]]
-
-## Usage
-
-Usage instructions are in the `README` file.
-
-## MoinMoin importer features
-
- * supports latest MoinMoin versions (tested with 1.9.x)
- * uses `git fast-import` to improve performance (10 minutes and 200M of ram for a 7 years old 2GB Moinmoin wiki)
- * multistep process allows bulk edit through git before markdown conversion, or staying with a 
- * imports attachments as subpages
- * uses the per-page edit log
- * consistent: multiple runs will generate the same repository
- * re-entrant: can be run multiple times to import new changes
-
-## MoinMoin converter features
-
- * most of the inline markup
- * links
- * attachment links
- * smileys
- * images (not well tested), into [[ikiwiki/directive/img]]
- * preformatted and code areas, including [[ikiwiki/directive/format]]
- * ordered, unordered and definition lists
- * tables (although only with HTML and no styles)
-
-### Supported macros
-
- * TableOfContents, through [[ikiwiki/directive/toc]]
- * Navigation, through [[ikiwiki/directive/map]] (so as a nested
-   vertical list instead of an horizontal list)
- * PageList, through [[ikiwiki/directive/map]]
- * MonthCalendar, partially, through [[ikiwiki/directive/calendar]]
- * FootNote, through multimarkdown (`[^foo]` → `[^foo]: this is the footnote`)
- * Anchor, through markdown and plain HTML
- * `<<BR>>`, through the weird line ending thing
- * AttachList, through a weird [[ikiwiki/directive/inline]]
- * FullSearch, partially, only through [[ikiwiki/directive/inline]] (so no textual search)
- * Include, partially through [[ikiwiki/directive/inline]] (so missing boundary extraction and heading level generation)
- * PageCount, same name even :)
- * OrphanedPages, through [[ikiwiki/directive/orphans]]
- * Date and Datetime, should be through [[plugins/date]] instead of
-   current hack
-
-### Supported parsers
-
- * the main "moin wiki" markup
- * highlight parser, through the [[plugins/format]] plugin
- * other parsers may be supported if an equivalent plugin exists in Ikiwiki (example: [[plugins/rst]])
-
-## Current blocker
-
-This script is being used to test the conversion of the venerable [Koumbit wiki](https://wiki.koumbit.net/) into Ikiwiki, and so far progress is steady but difficult. The current blocker is:
-
- * figuring out exactly which pages should exist and which should not, as there is ambiguity in the internal datastructures of MoinMoin, which become apparent when running the conversion script, as files a missing
-
-## Todos
-
-There are also significant pieces missing:
-
- * inline parsers and hackish styled tables
- * turn categories into tags
- * name converted page to the right name depending on the `#format` parameter on top of page
- * finish a full converter run on the Koumbitwiki
- * improve the output of the converter (too much debugging)
-
-## MoinMoin features missing from ikiwiki
-
-The importer is pretty much complete, but the converter can only go so far as what features ikiwiki supports. Here are the MoinMoin features that are known to be missing from ikiwiki. Note that some of those features are available in MoinMoin only through third-party extensions.
-
- * [[todo/do_not_make_links_backwards/]] - MoinMoin and Creole use `\[[link|text]]`, while ikiwiki uses `\[[text|link]]` - for now the converter generates [[markdown]] links so this is not so much an issue, but will freak out users
- * [[todo/internal_definition_list_support/]] - includes tabling the results ([MoinMoin's DictColumns macro](http://moinmo.in/MacroMarket/DictColumns))
- * [[todo/per page ACLs]] - ([MoinMoin's ACLs](http://moinmo.in/HelpOnAccessControlLists))
- * [MailTo](http://moinmo.in/HelpOnMacros/MailTo) macro spam protection
- * list pages based on full text page search
- * extract part of other pages with the inline macro
- * specifying a template when creating a page (as opposed to matching a pagespec)
- * specifying a style for a sub-section (MoinMoin's inline parsers
-   allow the user to specify a CSS class - very useful see
-   [the documentation](http://moinmo.in/HelpOnMoinWikiSyntax#Using_the_wiki_parser_with_css_classes)
-   to get an idea)
- * the above also keeps the SectionParser from being properly supported
- * regex matching all over the place: pagespec, basically, but all
-   full text search (which is missing anyways, see above)
-
-### Missing macros
-
- * RandomPage(N) - lists N random pages, skipped
- * Gallery() - skipped
- * Gettext - translates the string accordign to internal translation
-   system, ignored
- * AdvancedSearch - an elaborate search form provided by MoinMoin
- * Goto - a simple "jump to page" macro
-
-Comments and feedback always welcome! --[[anarcat]]
+Issues can be filed on the [project page](https://gitlab.com/anarcat/moin2iki/), where more information about features, installation and usage is available as well. -- [[anarcat]]

repository was moved
diff --git a/doc/tips/convert_moinmoin_to_ikiwiki.mdwn b/doc/tips/convert_moinmoin_to_ikiwiki.mdwn
index 492418b5a..142a8e81f 100644
--- a/doc/tips/convert_moinmoin_to_ikiwiki.mdwn
+++ b/doc/tips/convert_moinmoin_to_ikiwiki.mdwn
@@ -6,11 +6,11 @@ The converter was originally written by [[JoshTriplett]] and included support fo
 
 The MoinMoin side of things was completely re-written by [[anarcat]] and is currently still in development. That version is available at:
 
-    git clone git://git.koumbit.net/moin2iki.git
+    git clone https://gitlab.com/anarcat/moin2iki/
 
 It doesn't feature support to migrate from Tikiwiki anymore and focuses on MoinMoin support.
 
-Issues can be filed in the redmine bugtracker: <https://redmine.koumbit.net/projects/moin2iki>
+Issues can be filed on the [project page](https://gitlab.com/anarcat/moin2iki/).
 
 [[!toc levels=2]]
 

Added a comment: Todo already exists for `basename`
diff --git a/doc/forum/Most_TMPL__95__VAR_variables_are_empty_in_a_template/comment_2_7dba0f1345260aa27d89bcd3526d5c10._comment b/doc/forum/Most_TMPL__95__VAR_variables_are_empty_in_a_template/comment_2_7dba0f1345260aa27d89bcd3526d5c10._comment
new file mode 100644
index 000000000..1c5590ecc
--- /dev/null
+++ b/doc/forum/Most_TMPL__95__VAR_variables_are_empty_in_a_template/comment_2_7dba0f1345260aa27d89bcd3526d5c10._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="vegardv@75ae889e836bda8ce69bc038d8335c398a2f6f40"
+ nickname="vegardv"
+ avatar="http://cdn.libravatar.org/avatar/b35da1da5c23c19063f73defc0431ab0"
+ subject="Todo already exists for `basename`"
+ date="2018-01-10T08:54:27Z"
+ content="""
+https://ikiwiki.info/todo/Add_basename_in_edittemplate/
+"""]]

co-maintainer opinion
diff --git a/doc/todo/consider_using_python3_for_rst_plugin.mdwn b/doc/todo/consider_using_python3_for_rst_plugin.mdwn
index 5135d153a..b95dff641 100644
--- a/doc/todo/consider_using_python3_for_rst_plugin.mdwn
+++ b/doc/todo/consider_using_python3_for_rst_plugin.mdwn
@@ -15,3 +15,11 @@ by changing the source rather than by using `sed` after installation. I didn't a
 change upstream immediately to give other maintainers a chance to comment. Thoughts?
 
 --[[smcv]]
+
+> I can attest as a pkgsrc developer, where we try to build and package
+> software on all sorts of platforms (some old and wacky), that as long
+> as the relevant Pythons build on those platforms (and we tend to make
+> sure they do), I don't foresee any negative impact of your suggested
+> change to ikiwiki. Can't attest for other situations, but am generally
+> biased toward biting future bullets as early as possible.
+> --[[schmonz]]

Don't send relative redirect URLs when behind a reverse proxy
diff --git a/CHANGELOG b/CHANGELOG
index 1456810e0..0ffbd4579 100644
--- a/CHANGELOG
+++ b/CHANGELOG
@@ -1,3 +1,9 @@
+ikiwiki (3.20180106) UNRELEASED; urgency=medium
+
+  * core: Don't send relative redirect URLs when behind a reverse proxy
+
+ -- Simon McVittie <smcv@debian.org>  Mon, 08 Jan 2018 10:51:10 +0000
+
 ikiwiki (3.20180105) upstream; urgency=medium
 
   * emailauth: Fix cookie problem when user is on https and the cgiurl
diff --git a/IkiWiki/CGI.pm b/IkiWiki/CGI.pm
index 64f5c6b8c..2c5b4a84d 100644
--- a/IkiWiki/CGI.pm
+++ b/IkiWiki/CGI.pm
@@ -91,7 +91,7 @@ sub redirect ($$) {
 	my $q=shift;
 	eval q{use URI};
 
-	my $topurl;
+	my $topurl = $config{cgiurl};
 	if (defined $q && ! $config{w3mmode} && ! $config{reverse_proxy}) {
 		$topurl = $q->url;
 	}
diff --git a/doc/bugs/cgi_redirecting_to_non-https_URL.mdwn b/doc/bugs/cgi_redirecting_to_non-https_URL.mdwn
index 58b4a0137..02c04900f 100644
--- a/doc/bugs/cgi_redirecting_to_non-https_URL.mdwn
+++ b/doc/bugs/cgi_redirecting_to_non-https_URL.mdwn
@@ -42,11 +42,11 @@ that so as to have the path for letsencrypt negotiation not redirected.-- [[User
 > Is the connection between nginx and lighttpd http or https?
 >
 > I think this is maybe a bug in `IkiWiki::redirect` when used in conjunction with
-> `reverse_proxy: 1`. I've added a failing test case marked as TODO to `t/relativity.t`,
-> although I haven't been able to fix the bug yet. The bug I found is that when marked
-> as behind a reverse proxy, `IkiWiki::redirect` sends `Location: /foo/bar/`, which
-> your backend web server might be misinterpreting. It should send
-> `Location: https://redacted/foo/bar/` instead.
+> `reverse_proxy: 1`: when marked as behind a reverse proxy,
+> `IkiWiki::redirect` sent `Location: /phd/foo/bar/`, which your backend web
+> server might be misinterpreting. ikiwiki git master now sends
+> `Location: https://redacted/phd/foo/bar/` instead: does that resolve this
+> for you?
 >
 > Assuming nginx has a reasonable level of configuration, you can redirect http to https
 > for the entire server except `/.well-known/acme-challenge/` as a good way to bootstrap
diff --git a/t/relativity.t b/t/relativity.t
index 3fd55375a..1dda19687 100755
--- a/t/relativity.t
+++ b/t/relativity.t
@@ -403,10 +403,7 @@ sub test_site6_behind_reverse_proxy {
 	like($bits{cgihref}, qr{^(?:(?:https:)?//example.com)?/cgi-bin/ikiwiki.cgi$});
 	like($bits{basehref}, qr{^(?:(?:https:)?//example\.com)?/wiki/$});
 	like($bits{stylehref}, qr{^(?:(?:https:)?//example.com)?/wiki/style.css$});
-	TODO: {
-	local $TODO = "https://ikiwiki.info/bugs/cgi_redirecting_to_non-https_URL/";
 	check_goto(qr{^https://example\.com/wiki/a/b/c/$}, HTTP_HOST => 'localhost');
-	}
 
 	# previewing a page
 	%bits = parse_cgi_content(run_cgi(is_preview => 1, HTTP_HOST => 'localhost'));

point to previous TODO entry
diff --git a/doc/todo/css_and_javascript_aggregation.mdwn b/doc/todo/css_and_javascript_aggregation.mdwn
index 4b3e5f766..7e38f7600 100644
--- a/doc/todo/css_and_javascript_aggregation.mdwn
+++ b/doc/todo/css_and_javascript_aggregation.mdwn
@@ -1,5 +1,7 @@
 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.
 
+> For the CSS case, this was already proposed at [[todo/concatenating or compiling CSS]] --[[smcv]]
+
 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 is a web server configuration issue rather than a bug in the ikiwiki code
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
index 7c2c501b7..ae53fc5b3 100644
--- a/doc/bugs/Login_should_redirect_to_secure_version_of_site.mdwn
+++ b/doc/bugs/Login_should_redirect_to_secure_version_of_site.mdwn
@@ -7,3 +7,26 @@ Steps to reproduce:
 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.
+
+> This is web server configuration for those sites, so not really a bug in the
+> ikiwiki software. If you run an ikiwiki instance and you have a browser-trusted certificate,
+> I would recommend:
+>
+> * setting the `url` and `cgiurl` options to `https://...`
+> * configuring your web server (frontend web server if you are using a reverse-proxy)
+>   to redirect from `http://...` to `https://...` automatically, possibly excluding
+>   `/.well-known/acme-challenge/` to make it easier to bootstrap Let's Encrypt certificates
+>
+> In [ikiwiki-hosting](https://ikiwiki-hosting.branchable.com/) the latter can be achieved
+> by setting the `redirect_to_https` option to `1`.
+>
+> When not using ikiwiki-hosting, the ikiwiki software does not control the web server
+> configuration, so it can't do this for you. The CGI script could redirect from http
+> to https if it knew you had a browser-trusted certificate, but it can't know that
+> unless you tell it (by setting `url` and `cgiurl`), and there's the potential for
+> infinite redirect loops in misconfigured reverse-proxy setups if it did that
+> (see [[bugs/login problem redux]]), so I think this is better solved at the web
+> server level.
+>
+> The operator of ikiwiki.info and branchable.com can change the web server
+> configuration for those sites, but other ikiwiki developers can't. --[[smcv]]

failing test (marked TODO) now present
diff --git a/doc/bugs/cgi_redirecting_to_non-https_URL.mdwn b/doc/bugs/cgi_redirecting_to_non-https_URL.mdwn
index f27e75fcb..58b4a0137 100644
--- a/doc/bugs/cgi_redirecting_to_non-https_URL.mdwn
+++ b/doc/bugs/cgi_redirecting_to_non-https_URL.mdwn
@@ -23,6 +23,10 @@ Response Headers
     Status: 302 Found
     Location: http://redacted/phd/blog/38th_Dec/?updated#comment-bd0549eb2464b5ca0544f68e6c32221e
 
+> Your form submission was in fact done successfully. The failing redirection to http is
+> when ikiwiki follows up the successful edit by redirecting you from the form submission
+> URL to the updated page, which is done by `IkiWiki::redirect`. --[[smcv]]
+
 The CGI is served by lighttpd, but the whole site is front-ended by nginx, which reverse-proxies to lighttpd.
 
 ----
@@ -38,7 +42,11 @@ that so as to have the path for letsencrypt negotiation not redirected.-- [[User
 > Is the connection between nginx and lighttpd http or https?
 >
 > I think this is maybe a bug in `IkiWiki::redirect` when used in conjunction with
-> `reverse_proxy: 1`. I'm in the process of adding a test case in `t/relativity.t`.
+> `reverse_proxy: 1`. I've added a failing test case marked as TODO to `t/relativity.t`,
+> although I haven't been able to fix the bug yet. The bug I found is that when marked
+> as behind a reverse proxy, `IkiWiki::redirect` sends `Location: /foo/bar/`, which
+> your backend web server might be misinterpreting. It should send
+> `Location: https://redacted/foo/bar/` instead.
 >
 > Assuming nginx has a reasonable level of configuration, you can redirect http to https
 > for the entire server except `/.well-known/acme-challenge/` as a good way to bootstrap

diff --git a/doc/bugs/cgi_redirecting_to_non-https_URL.mdwn b/doc/bugs/cgi_redirecting_to_non-https_URL.mdwn
index 217aa336d..f27e75fcb 100644
--- a/doc/bugs/cgi_redirecting_to_non-https_URL.mdwn
+++ b/doc/bugs/cgi_redirecting_to_non-https_URL.mdwn
@@ -38,7 +38,7 @@ that so as to have the path for letsencrypt negotiation not redirected.-- [[User
 > Is the connection between nginx and lighttpd http or https?
 >
 > I think this is maybe a bug in `IkiWiki::redirect` when used in conjunction with
-> `reverse_proxy: 1`. I'm in the process of adding a 
+> `reverse_proxy: 1`. I'm in the process of adding a test case in `t/relativity.t`.
 >
 > Assuming nginx has a reasonable level of configuration, you can redirect http to https
 > for the entire server except `/.well-known/acme-challenge/` as a good way to bootstrap

test case potentially in progress
diff --git a/doc/bugs/cgi_redirecting_to_non-https_URL.mdwn b/doc/bugs/cgi_redirecting_to_non-https_URL.mdwn
index abdc676a0..217aa336d 100644
--- a/doc/bugs/cgi_redirecting_to_non-https_URL.mdwn
+++ b/doc/bugs/cgi_redirecting_to_non-https_URL.mdwn
@@ -31,3 +31,15 @@ I think this might be to do with nginx not rewriting POST URLs when reverse-prox
 they would be generated in an HTTP form in any case, except perhaps by lighttpd's CGI handler since the back
 end is HTTP. A workaround is for nginx to redirect any HTTP URI to the HTTPS equivalent. I initially disabled
 that so as to have the path for letsencrypt negotiation not redirected.-- [[Users/Jon]]
+
+> Do you have the `reverse_proxy` option set to 1? (It affects how ikiwiki generates
+> self-referential URLs).
+>
+> Is the connection between nginx and lighttpd http or https?
+>
+> I think this is maybe a bug in `IkiWiki::redirect` when used in conjunction with
+> `reverse_proxy: 1`. I'm in the process of adding a 
+>
+> Assuming nginx has a reasonable level of configuration, you can redirect http to https
+> for the entire server except `/.well-known/acme-challenge/` as a good way to bootstrap
+> ACME negotiation. --[[smcv]]

I'm not sure this can be solved without web server configuration
diff --git a/doc/bugs/login_problem_redux.mdwn b/doc/bugs/login_problem_redux.mdwn
index 559782ec8..20a4d407a 100644
--- a/doc/bugs/login_problem_redux.mdwn
+++ b/doc/bugs/login_problem_redux.mdwn
@@ -1,12 +1,71 @@
 Following up on [[login_problem]], there's still some problems mixing https
 and http logins on sites that allow both and don't redirect http to https.
 
+> I think the only good solution to this is to configure web servers to
+> redirect http to https, which is outside the scope of the ikiwiki
+> software (but would be a useful configuration change on sites like
+> ikiwiki.info). Redirecting from CGI code is problematic because
+> reverse-proxies are a thing; see below. --[[smcv]]
+
 If the user logs in on https first, their cookie is https-only. If they
 then open the http site and do something that needs them logged in, it will
 try to log them in again. But, the https-only cookie is apparently not
 replaced by the http login cookie. The login will "succeed", but the cookie
 is inaccessible over https and so they'll not be really logged in.
 
+> Mitigation: If you have a browser-trusted certificate (which lots of
+> people do now, because Let's Encrypt exists), setting the `cgiurl` to
+> `https://...` will result in the CGI (which is the only part that
+> needs cookies) being accessed via https whenever the user follows
+> links from static content.
+> (`test_site4_cgi_is_secure_static_content_doesnt_have_to_be` in
+> `t/relativity.t`.)
+>
+> In the past I've wondered whether to add a distinction between
+> authenticating and unauthenticating CGI URLs, so that on sites that
+> don't particularly care about eavesdropping, anonymous/read-only actions
+> like `?do=goto` can go via `http`, but write actions and actions that
+> are usually authenticated like `?do=edit` go via `https`. However, in
+> 2018 with Let's Encrypt widely available, it seems reasonable to just
+> use `https` for all CGI accesses.
+> --[[smcv]]
+
 I think that the only fix for this is make the login page redirect from
 http to https, and for it to return to the https version of the page that
 prompted the login. --[[Joey]]
+
+> Redirecting the login page from http to https inside ikiwiki.cgi is
+> problematic, because ikiwiki can't reliably know whether it was already
+> accessed via https. If there is a reverse-proxy in use but the site admin
+> has not set the `reverse_proxy` option (which is not *always* necessary
+> even behind reverse proxies AIUI, and I suspect some reverse-proxied sites
+> haven't set it correctly), then ikiwiki.cgi would infinitely redirect back
+> to itself.
+>
+> For example, suppose your frontend web server is example.com and your
+> ikiwiki backend is 127.0.0.1:8080.
+>
+> * frontend web server sees an access to http://example.com/ikiwiki.cgi
+> * frontend web server reverse-proxies it to http://127.0.0.1:8080/ikiwiki.cgi
+> * backend web server invokes ikiwiki.cgi with `HTTPS` environment variable
+>   undefined
+> * ikiwiki.cgi thinks "I'm being accessed via plain http" (this time correctly,
+>   as it happens)
+> * ikiwiki.cgi sends a redirect to https://example.com/ikiwiki.cgi
+> * {1} web browser follows redirect
+> * frontend web server sees an access to https://example.com/ikiwiki.cgi
+> * frontend web server reverse-proxies it to http://127.0.0.1:8080/ikiwiki.cgi
+> * backend web server invokes ikiwiki.cgi with `HTTPS` environment variable
+>   undefined
+> * ikiwiki.cgi thinks "I'm being accessed via plain http" (this time incorrectly!)
+> * ikiwiki.cgi sends a redirect to https://example.com/ikiwiki.cgi
+> * goto {1}
+>
+> I think this redirection is better achieved via web server configuration, like
+> the Apache configuration set up by `redirect_to_https: 1` in
+> [ikiwiki-hosting](https://ikiwiki-hosting.branchable.com/).
+>
+> If you change ikiwiki's behaviour in this area, please add test-cases to
+> `t/relativity.t` to cover the cases that changed.
+>
+> --[[smcv]]

bug
diff --git a/doc/bugs/login_problem_redux.mdwn b/doc/bugs/login_problem_redux.mdwn
new file mode 100644
index 000000000..559782ec8
--- /dev/null
+++ b/doc/bugs/login_problem_redux.mdwn
@@ -0,0 +1,12 @@
+Following up on [[login_problem]], there's still some problems mixing https
+and http logins on sites that allow both and don't redirect http to https.
+
+If the user logs in on https first, their cookie is https-only. If they
+then open the http site and do something that needs them logged in, it will
+try to log them in again. But, the https-only cookie is apparently not
+replaced by the http login cookie. The login will "succeed", but the cookie
+is inaccessible over https and so they'll not be really logged in.
+
+I think that the only fix for this is make the login page redirect from
+http to https, and for it to return to the https version of the page that
+prompted the login. --[[Joey]]

open
diff --git a/doc/todo/consider_using_python3_for_rst_plugin.mdwn b/doc/todo/consider_using_python3_for_rst_plugin.mdwn
new file mode 100644
index 000000000..5135d153a
--- /dev/null
+++ b/doc/todo/consider_using_python3_for_rst_plugin.mdwn
@@ -0,0 +1,17 @@
+Python 2 is officially unsupported after 2020, which is before the expected end-of-life
+date of the next round of long-term-stable distributions like Debian 10 and Ubuntu 18.04,
+so those distributions are encouraging all software that can migrate to Python 3 to do so.
+
+The down side of this is that it would make it harder to use the `rst` plugin on
+very old OS releases, or on OSs where Python 3 is available but doesn't have a `python3`
+symbolic link (if such OSs exist - [PEP 394](https://www.python.org/dev/peps/pep-0394/)
+says they shouldn't), or in shared hosting environments where Python 2 is installed but
+Python 3 isn't. (Mitigation: switching it to `python` or `python2` is a 1-line change.)
+
+For today's upload to Debian, I switched the `#!` line in the [[plugins/rst]] plugin
+to `#!/usr/bin/python3`. In upstream ikiwiki it would probably be more appropriate
+to use `#!/usr/bin/env python3`, and it would certainly be more appropriate to do it
+by changing the source rather than by using `sed` after installation. I didn't apply that
+change upstream immediately to give other maintainers a chance to comment. Thoughts?
+
+--[[smcv]]

Reinstate links on front page, removed by spam edits
diff --git a/doc/index.mdwn b/doc/index.mdwn
index 0122e489c..e0e401656 100644
--- a/doc/index.mdwn
+++ b/doc/index.mdwn
@@ -1,3 +1,5 @@
+[[!template id=links]]
+
 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]].

add news item for ikiwiki 3.20180105
diff --git a/doc/news/version_3.20161229.1.mdwn b/doc/news/version_3.20161229.1.mdwn
deleted file mode 100644
index a09a3b2ac..000000000
--- a/doc/news/version_3.20161229.1.mdwn
+++ /dev/null
@@ -1,5 +0,0 @@
-ikiwiki 3.20161229.1 released with [[!toggle text="these changes"]]
-[[!toggleable text="""
-   * git: Attribute reverts to the user doing the revert, not the wiki
-     itself.
-   * git: Do not disable the commit hook while preparing a revert."""]]
\ No newline at end of file
diff --git a/doc/news/version_3.20180105.mdwn b/doc/news/version_3.20180105.mdwn
new file mode 100644
index 000000000..2082db897
--- /dev/null
+++ b/doc/news/version_3.20180105.mdwn
@@ -0,0 +1,12 @@
+ikiwiki 3.20180105 released with [[!toggle text="these changes"]]
+[[!toggleable text="""
+   * emailauth: Fix cookie problem when user is on https and the cgiurl
+     uses http, by making the emailed login link use https.
+   * passwordauth: Use https for emailed password reset link when user
+     is on https.
+   * Remove openid provider icons from login selector, since openid providers
+     are increasingly not working. Verisign retired theirs, and aol and
+     yahoo/flickr are not commonly used for openid. Any users who still
+     clicked those icons to login will need to instead enter their openid url.
+   * Updated German basewiki and directives translation from
+     Sebastian Kuhnert."""]]
\ No newline at end of file

add and use cgiurl_abs_samescheme
* emailauth: Fix cookie problem when user is on https and the cgiurl
uses http, by making the emailed login link use https.
* passwordauth: Use https for emailed password reset link when user
is on https.
Not entirely happy with this approach, but I don't currently see a
better one.
I have not verified that the passwordauth change fixes any problem,
other than the user getting a http link when they were using https.
The emailauth problem is verified fixed by this commit.
This commit was sponsored by Michael Magin.
diff --git a/IkiWiki.pm b/IkiWiki.pm
index 1eda16da1..0d87242eb 100644
--- a/IkiWiki.pm
+++ b/IkiWiki.pm
@@ -1232,6 +1232,19 @@ sub cgiurl_abs (@) {
 	URI->new_abs(cgiurl(@_), $config{cgiurl});
 }
 
+# Same as cgiurl_abs, but when the user connected using https,
+# will be a https url even if the cgiurl is normally a http url.
+#
+# This should be used for anything involving emailing a login link,
+# because a https session cookie will not be sent over http.
+sub cgiurl_abs_samescheme (@) {
+	my $u=cgiurl_abs(@_);
+	if (($ENV{HTTPS} && lc $ENV{HTTPS} ne "off")) {
+		$u=~s/^http:/https:/i;
+	}
+	return $u
+}
+
 sub baseurl (;$) {
 	my $page=shift;
 
diff --git a/IkiWiki/Plugin/emailauth.pm b/IkiWiki/Plugin/emailauth.pm
index 9c595dc86..44311400a 100644
--- a/IkiWiki/Plugin/emailauth.pm
+++ b/IkiWiki/Plugin/emailauth.pm
@@ -76,7 +76,7 @@ sub email_auth ($$$$) {
 	$template->param(
 		wikiname => $config{wikiname},
 		# Intentionally using short field names to keep link short.
-		authurl => IkiWiki::cgiurl_abs(
+		authurl => IkiWiki::cgiurl_abs_samescheme(
 			'e' => $email,
 			'v' => $token,
 		),
diff --git a/IkiWiki/Plugin/passwordauth.pm b/IkiWiki/Plugin/passwordauth.pm
index 8d99cf2f6..cfa3ad418 100644
--- a/IkiWiki/Plugin/passwordauth.pm
+++ b/IkiWiki/Plugin/passwordauth.pm
@@ -358,7 +358,7 @@ sub formbuilder (@) {
 				my $template=template("passwordmail.tmpl");
 				$template->param(
 					user_name => $user_name,
-					passwordurl => IkiWiki::cgiurl_abs(
+					passwordurl => IkiWiki::cgiurl_abs_samescheme(
 						'do' => "reset",
 						'name' => $user_name,
 						'token' => $token,
diff --git a/debian/changelog b/debian/changelog
index 63e5f61d6..6cf509f9d 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,5 +1,9 @@
 ikiwiki (3.20171002) UNRELEASED; urgency=medium
 
+  * emailauth: Fix cookie problem when user is on https and the cgiurl
+    uses http, by making the emailed login link use https.
+  * passwordauth: Use https for emailed password reset link when user
+    is on https.
   * Updated German basewiki and directives translation from
     Sebastian Kuhnert.
 
diff --git a/doc/bugs/login_problem.mdwn b/doc/bugs/login_problem.mdwn
index 0946a238f..14e3fb325 100644
--- a/doc/bugs/login_problem.mdwn
+++ b/doc/bugs/login_problem.mdwn
@@ -18,10 +18,21 @@ firefox-esr, or chromium. --[[Joey]]
 > Ok, to reproduce the problem: Log into joeyh.name using https. The email
 > login link is a http link. The session cookie was set https-only.
 > --[[Joey]]
-
+> 
+> The reason the edit form is able to be displayed is that emailauth
+> sets up a session, in getsession(), and that $session is used for the
+> remainder of that cgi call. But, a cookie for that session is not stored
+> in the browser in this case. Ikiwiki *does* send a session cookie, but
+> the browser seems to not let an existing https-only session cookie be
+> replaced by a new session cookie that can be used with http. (If the
+> emailed link, generated on https is opened in a different browser, this
+> problem doesn't happen.) There may have been a browser behavior change
+> here?
+> 
 > So what to do about this? Sites with the problem have `redirect_to_https: 0`
-> and the cgiurl is http not https. So when emailauth generates the url,
-> it's a http url, even if the user got to that point using https.
+> and the cgiurl is http not https. So when emailauth generates the url
+> with `cgiurl_abs`, it's a http url, even if the user got to that point
+> using https.
 > 
 > I suppose that emailauth could look at `$ENV{HTTPS}` same as
 > printheader() does, to detect this case, and rewrite the cgiurl as a
@@ -31,3 +42,12 @@ firefox-esr, or chromium. --[[Joey]]
 > 
 > Of course, the easy workaround, increasingly a good idea anyway, is to
 > enable `redirect_to_https`.. --[[Joey]]
+
+> One of the users also reported a problem with password reset, and
+> indeed, passwordauth is another caller of `cgiurl_abs`. (The only other
+> caller, notifyemail, is probably fine.) The emailed password reset link
+> also should be https if the user was using https. So, let's add a
+> `cgiurl_abs_samescheme` that both can use. --[[Joey]]
+
+[[fixed|done]].. At least I hope that was the thing actually preventing most
+of the people from logging in. --[[Joey]]

how to fix?
diff --git a/doc/bugs/login_problem.mdwn b/doc/bugs/login_problem.mdwn
index b9f70d755..0946a238f 100644
--- a/doc/bugs/login_problem.mdwn
+++ b/doc/bugs/login_problem.mdwn
@@ -18,3 +18,16 @@ firefox-esr, or chromium. --[[Joey]]
 > Ok, to reproduce the problem: Log into joeyh.name using https. The email
 > login link is a http link. The session cookie was set https-only.
 > --[[Joey]]
+
+> So what to do about this? Sites with the problem have `redirect_to_https: 0`
+> and the cgiurl is http not https. So when emailauth generates the url,
+> it's a http url, even if the user got to that point using https.
+> 
+> I suppose that emailauth could look at `$ENV{HTTPS}` same as
+> printheader() does, to detect this case, and rewrite the cgiurl as a
+> https url. Or, printheader() could just not set "-secure" on the cookie,
+> but that does degrade security as MITM can then steal the cookie you're
+> using on a https site.
+> 
+> Of course, the easy workaround, increasingly a good idea anyway, is to
+> enable `redirect_to_https`.. --[[Joey]]

think I cracked it
diff --git a/doc/bugs/login_problem.mdwn b/doc/bugs/login_problem.mdwn
index 1a9e7650e..b9f70d755 100644
--- a/doc/bugs/login_problem.mdwn
+++ b/doc/bugs/login_problem.mdwn
@@ -8,8 +8,13 @@ It doesn't seem limited to any login method; email and password have both
 been said not to work. (Openid too, but could be openid provider problem
 there.)
 
-I have not managed to reproduce the problem myself. --[[Joey]]
+I have not managed to reproduce the problem myself, using firefox,
+firefox-esr, or chromium. --[[Joey]]
 
 > Otto Kekäläinen described to me a problem where email login to post a
 > comment seemed to work; it displayed the comment edit form; but posting
-> the form went back to the login page. Cookie problem? --[[Joey]]
+> the form went back to the login page. Cookie problem?
+> 
+> Ok, to reproduce the problem: Log into joeyh.name using https. The email
+> login link is a http link. The session cookie was set https-only.
+> --[[Joey]]

update
diff --git a/doc/bugs/login_problem.mdwn b/doc/bugs/login_problem.mdwn
index 374fb51dc..1a9e7650e 100644
--- a/doc/bugs/login_problem.mdwn
+++ b/doc/bugs/login_problem.mdwn
@@ -9,3 +9,7 @@ been said not to work. (Openid too, but could be openid provider problem
 there.)
 
 I have not managed to reproduce the problem myself. --[[Joey]]
+
+> Otto Kekäläinen described to me a problem where email login to post a
+> comment seemed to work; it displayed the comment edit form; but posting
+> the form went back to the login page. Cookie problem? --[[Joey]]

correction; I did not reproduce this
I was manually reloading /ikiwiki.cgi?do=login, and postsignin is not
set when that's done, which is a bug, but not the bug I was after.
diff --git a/doc/bugs/login_problem.mdwn b/doc/bugs/login_problem.mdwn
index c83cd5870..374fb51dc 100644
--- a/doc/bugs/login_problem.mdwn
+++ b/doc/bugs/login_problem.mdwn
@@ -2,30 +2,10 @@ For around 2 weeks, I've been getting an increasing quantity of nonspecific
 reports from users of login problems on ikiwiki sites, mostly joeyh.name
 and git-annex.branchable.com. A few users are still logging in
 successfully, but it seems to be hitting many users; post volume has gone
-down more than holidays would explain. --[[Joey]] 
+down more than holidays would explain.
 
 It doesn't seem limited to any login method; email and password have both
 been said not to work. (Openid too, but could be openid provider problem
 there.)
 
-After a few tries
-I seem to have reproduced the problem with email login; I ended up at a
-"Error: login failed, perhaps you need to turn on cookies?" 
-page but my browser had an ikiwiki session cookie. And,
-looking in the session database file, the cookie id was in there. Then I
-went to "/do=prefs" in the same browser, and I was actually already 
-logged in. 
-
-That points at a problem with the "postsignin" redirect;
-if the session does not get a postsignin url set, it can error out that way
-despite being logged in.
-
-Reproducing again, I posted the login form, and before clicking on the
-login link, looked at the session.db -- it contained an entry for my session,
-but without a postsignin url.
-
-	$ strings sessions.db
-	$D = {'_SESSION_ID' => 'xxx','_SESSION_REMOTE_ADDR' => 'yyy','_SESSION_ATIME' => 1515106022,'_SESSION_CTIME' => 1515105990};;$D
-
-The postsignin url is certianly getting set at other times though,
-and why would this have only recently started to affect lots of users?
+I have not managed to reproduce the problem myself. --[[Joey]]

bug report
diff --git a/doc/bugs/login_problem.mdwn b/doc/bugs/login_problem.mdwn
new file mode 100644
index 000000000..c83cd5870
--- /dev/null
+++ b/doc/bugs/login_problem.mdwn
@@ -0,0 +1,31 @@
+For around 2 weeks, I've been getting an increasing quantity of nonspecific
+reports from users of login problems on ikiwiki sites, mostly joeyh.name
+and git-annex.branchable.com. A few users are still logging in
+successfully, but it seems to be hitting many users; post volume has gone
+down more than holidays would explain. --[[Joey]] 
+
+It doesn't seem limited to any login method; email and password have both
+been said not to work. (Openid too, but could be openid provider problem
+there.)
+
+After a few tries
+I seem to have reproduced the problem with email login; I ended up at a
+"Error: login failed, perhaps you need to turn on cookies?" 
+page but my browser had an ikiwiki session cookie. And,
+looking in the session database file, the cookie id was in there. Then I
+went to "/do=prefs" in the same browser, and I was actually already 
+logged in. 
+
+That points at a problem with the "postsignin" redirect;
+if the session does not get a postsignin url set, it can error out that way
+despite being logged in.
+
+Reproducing again, I posted the login form, and before clicking on the
+login link, looked at the session.db -- it contained an entry for my session,
+but without a postsignin url.
+
+	$ strings sessions.db
+	$D = {'_SESSION_ID' => 'xxx','_SESSION_REMOTE_ADDR' => 'yyy','_SESSION_ATIME' => 1515106022,'_SESSION_CTIME' => 1515105990};;$D
+
+The postsignin url is certianly getting set at other times though,
+and why would this have only recently started to affect lots of users?

Is it still Joey's opinion that ikiwiki.info should remain using the anti-theme?
diff --git a/doc/todo/Modern_standard_layout.mdwn b/doc/todo/Modern_standard_layout.mdwn
index 37f1ee740..64399b1b2 100644
--- a/doc/todo/Modern_standard_layout.mdwn
+++ b/doc/todo/Modern_standard_layout.mdwn
@@ -37,3 +37,32 @@ I think it would be a good idea to think about the standard layout style of ikiw
 > `auto.setup` and `auto-blog.setup` could have different defaults,
 > or allow a theme to be picked as [Branchable](http://branchable.com/)
 > does. Perhaps actiontabs for auto-blog and default for wikis? --[[Joey]]
+
+----                                                                                                                   
+                                                                                                                       
+Is it still Joey's opinion that ikiwiki.info should remain using the anti-theme?                                       
+                                                                                                                       
+I'd like to make one last, clear petition to move ikiwiki.info to using the actiontabs                                 
+theme. Rationale below.                                                                                                
+                                                                                                                       
+I wanted to just ask one last time if that was still the case. I've been considering                                   
+picking back up my ikiwiki hacking efforts,  as well as thinking about my personal use                                 
+of ikiwiki, and I was privately pondering on the health of the project. IMHO, it's not                                 
+great unfortunately, and we could use more contributors. I feel that the anti-theme on                                 
+ikiwiki.info is putting off potential users and thus potential contributors. The                                       
+actiontabs theme would be a better "advert" for ikiwiki: a better demonstration of what                                
+you *could* do with it, and I think that's an important function of the site. I think                                  
+people might come across ikiwiki.info whilst looking for basic information on the project                              
+and be put off by the anti-theme.                                                                                      
+                                                                                                                       
+Honestly, I also find it hard to read information on the site due to the anti-theme (yes,                              
+the default font face and size etc. are my own brower's preferences, but I sometimes use                               
+browsers on other machines that I have not configured), including the wide (lack of)                                   
+content margins, and prefer to interact with it (generally) using local clones.                                        
+(I've just made *this* edit this way, but actually because the login process via email                                 
+seems to be broken for edit/preview workflow. I might investigate/file about that later.)                              
+                                                                                                                       
+I wonder if someone feels the same, since you defaulted to actiontabs on branchable.                                   
+                                                                                                                       
+Thanks, [[users/Jon]].  (PS: Every log in method failed for me with Firefox Quantum
+trying to post this. Untrusted git push also failed.)

Serialist doesn't use Ikiwiki any more, and also isn't called Serialist any more, whoops
diff --git a/doc/ikiwikiusers.mdwn b/doc/ikiwikiusers.mdwn
index 4dbcf2cb3..a47692cfd 100644
--- a/doc/ikiwikiusers.mdwn
+++ b/doc/ikiwikiusers.mdwn
@@ -68,7 +68,6 @@ Projects & Organizations
 * [IPOL Image Processing On Line](http://www.ipol.im)
 * [Debian Costa Rica](http://cr.debian.net/)
 * [Fvwm Wiki](http://fvwmwiki.xteddy.org)
-* [Serialist](http://serialist.net/)'s static pages (documentation, blog).  We actually have ikiwiki generate its static content as HTML fragments using a modified page.tmpl template, and then the FastCGI powering our site grabs those fragments and embeds them in the standard dynamic site template.
 * [Software in the Public Interest](http://spi-inc.org/)
 * [NXT Improved Firmware](http://nxt-firmware.ni.fr.eu.org/)
 * [The FreedomBox Foundation](http://www.freedomboxfoundation.org/)

diff --git a/doc/bugs/cgi_redirecting_to_non-https_URL.mdwn b/doc/bugs/cgi_redirecting_to_non-https_URL.mdwn
index 5f7570dac..abdc676a0 100644
--- a/doc/bugs/cgi_redirecting_to_non-https_URL.mdwn
+++ b/doc/bugs/cgi_redirecting_to_non-https_URL.mdwn
@@ -29,4 +29,5 @@ The CGI is served by lighttpd, but the whole site is front-ended by nginx, which
 
 I think this might be to do with nginx not rewriting POST URLs when reverse-proxying, but I'm not sure why
 they would be generated in an HTTP form in any case, except perhaps by lighttpd's CGI handler since the back
-end is HTTP. -- [[Users/Jon]]
+end is HTTP. A workaround is for nginx to redirect any HTTP URI to the HTTPS equivalent. I initially disabled
+that so as to have the path for letsencrypt negotiation not redirected.-- [[Users/Jon]]

possible explanation
diff --git a/doc/bugs/cgi_redirecting_to_non-https_URL.mdwn b/doc/bugs/cgi_redirecting_to_non-https_URL.mdwn
index fe895c859..5f7570dac 100644
--- a/doc/bugs/cgi_redirecting_to_non-https_URL.mdwn
+++ b/doc/bugs/cgi_redirecting_to_non-https_URL.mdwn
@@ -25,3 +25,8 @@ Response Headers
 
 The CGI is served by lighttpd, but the whole site is front-ended by nginx, which reverse-proxies to lighttpd.
 
+----
+
+I think this might be to do with nginx not rewriting POST URLs when reverse-proxying, but I'm not sure why
+they would be generated in an HTTP form in any case, except perhaps by lighttpd's CGI handler since the back
+end is HTTP. -- [[Users/Jon]]

Added a comment: Fixed... by upgrading!
diff --git a/doc/forum/How_to_use_themes__63__/comment_6_78124cdad487a10e8c93b5397b1da142._comment b/doc/forum/How_to_use_themes__63__/comment_6_78124cdad487a10e8c93b5397b1da142._comment
new file mode 100644
index 000000000..22bd8889b
--- /dev/null
+++ b/doc/forum/How_to_use_themes__63__/comment_6_78124cdad487a10e8c93b5397b1da142._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="STrRedWolf"
+ avatar="http://cdn.libravatar.org/avatar/c2c9c483fb5d000b153a9042e2662567"
+ subject="Fixed... by upgrading!"
+ date="2017-12-08T16:05:58Z"
+ content="""
+Pulled the latest from git and installed that.  
+
+Yep, that worked.  Much better.
+
+
+"""]]

Added a comment
diff --git a/doc/forum/How_to_use_themes__63__/comment_5_ffbd5dda54f4a186f5b27e2d88256484._comment b/doc/forum/How_to_use_themes__63__/comment_5_ffbd5dda54f4a186f5b27e2d88256484._comment
new file mode 100644
index 000000000..892f926ee
--- /dev/null
+++ b/doc/forum/How_to_use_themes__63__/comment_5_ffbd5dda54f4a186f5b27e2d88256484._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="STrRedWolf"
+ avatar="http://cdn.libravatar.org/avatar/c2c9c483fb5d000b153a9042e2662567"
+ subject="comment 5"
+ date="2017-12-08T15:11:10Z"
+ content="""
+No joy in mudville there.  I have the plugin added in, and I'm using --rebuild, but it's not working.
+"""]]

formatting
diff --git a/doc/bugs/cgi_redirecting_to_non-https_URL.mdwn b/doc/bugs/cgi_redirecting_to_non-https_URL.mdwn
index 148e8ea47..fe895c859 100644
--- a/doc/bugs/cgi_redirecting_to_non-https_URL.mdwn
+++ b/doc/bugs/cgi_redirecting_to_non-https_URL.mdwn
@@ -1,26 +1,27 @@
 I have a private ikiwiki (3.20170111) which is running on a host that serves HTTP and HTTPS, but ikiwiki is configured for (and only served on) HTTPS:
 
-    url: https://<redacted>/phd/
-    cgiurl: https://<redacted>/phd/cgi
+    url: https://redacted/phd/
+    cgiurl: https://redacted/phd/cgi
 
 However, form submissions from ikiwiki are going to a HTTP URL and thus not being served. Example headers from submitting a comment:
 
-```
-Request URL:https://<redacted>/phd/cgi
-Request Method:POST
-Status Code:302 Found
-Remote Address:<redacted>:443
-Referrer Policy:no-referrer-when-downgrade
+
+
+    Request URL:https://redacted/phd/cgi
+    Request Method:POST
+    Status Code:302 Found
+    Remote Address:redacted:443
+    Referrer Policy:no-referrer-when-downgrade
 
 Response Headers
-HTTP/1.1 302 Found
-Server: nginx/1.10.3
-Date: Fri, 08 Dec 2017 11:53:35 GMT
-Content-Length: 0
-Connection: keep-alive
-Status: 302 Found
-Location: http://<redacted>/phd/blog/38th_Dec/?updated#comment-bd0549eb2464b5ca0544f68e6c32221e
-```
+
+    HTTP/1.1 302 Found
+    Server: nginx/1.10.3
+    Date: Fri, 08 Dec 2017 11:53:35 GMT
+    Content-Length: 0
+    Connection: keep-alive
+    Status: 302 Found
+    Location: http://redacted/phd/blog/38th_Dec/?updated#comment-bd0549eb2464b5ca0544f68e6c32221e
 
 The CGI is served by lighttpd, but the whole site is front-ended by nginx, which reverse-proxies to lighttpd.
 

diff --git a/doc/bugs/cgi_redirecting_to_non-https_URL.mdwn b/doc/bugs/cgi_redirecting_to_non-https_URL.mdwn
index 042acb615..148e8ea47 100644
--- a/doc/bugs/cgi_redirecting_to_non-https_URL.mdwn
+++ b/doc/bugs/cgi_redirecting_to_non-https_URL.mdwn
@@ -22,3 +22,5 @@ Status: 302 Found
 Location: http://<redacted>/phd/blog/38th_Dec/?updated#comment-bd0549eb2464b5ca0544f68e6c32221e
 ```
 
+The CGI is served by lighttpd, but the whole site is front-ended by nginx, which reverse-proxies to lighttpd.
+

bug report re http redirect
diff --git a/doc/bugs/cgi_redirecting_to_non-https_URL.mdwn b/doc/bugs/cgi_redirecting_to_non-https_URL.mdwn
new file mode 100644
index 000000000..042acb615
--- /dev/null
+++ b/doc/bugs/cgi_redirecting_to_non-https_URL.mdwn
@@ -0,0 +1,24 @@
+I have a private ikiwiki (3.20170111) which is running on a host that serves HTTP and HTTPS, but ikiwiki is configured for (and only served on) HTTPS:
+
+    url: https://<redacted>/phd/
+    cgiurl: https://<redacted>/phd/cgi
+
+However, form submissions from ikiwiki are going to a HTTP URL and thus not being served. Example headers from submitting a comment:
+
+```
+Request URL:https://<redacted>/phd/cgi
+Request Method:POST
+Status Code:302 Found
+Remote Address:<redacted>:443
+Referrer Policy:no-referrer-when-downgrade
+
+Response Headers
+HTTP/1.1 302 Found
+Server: nginx/1.10.3
+Date: Fri, 08 Dec 2017 11:53:35 GMT
+Content-Length: 0
+Connection: keep-alive
+Status: 302 Found
+Location: http://<redacted>/phd/blog/38th_Dec/?updated#comment-bd0549eb2464b5ca0544f68e6c32221e
+```
+

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