Recent changes to this wiki:

Added a comment: more info needed
diff --git a/doc/forum/global__95__sidebars_breaks_my_web_setup_page/comment_1_5af6f470cc568fa7139d43a896763767._comment b/doc/forum/global__95__sidebars_breaks_my_web_setup_page/comment_1_5af6f470cc568fa7139d43a896763767._comment
new file mode 100644
index 0000000..b75b5e8
--- /dev/null
+++ b/doc/forum/global__95__sidebars_breaks_my_web_setup_page/comment_1_5af6f470cc568fa7139d43a896763767._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="http://smcv.pseudorandom.co.uk/"
+ nickname="smcv"
+ subject="more info needed"
+ date="2014-11-27T12:14:56Z"
+ content="""
+That sounds like a bug. Please check your web server log for warnings
+or error messages from the CGI script.
+"""]]

diff --git a/doc/forum/global__95__sidebars_breaks_my_web_setup_page.mdwn b/doc/forum/global__95__sidebars_breaks_my_web_setup_page.mdwn
new file mode 100644
index 0000000..d1d3505
--- /dev/null
+++ b/doc/forum/global__95__sidebars_breaks_my_web_setup_page.mdwn
@@ -0,0 +1,8 @@
+After enabling "Show sidebar on all pages" (global_sidebars) I can no longer access the setup page via the web interface.
+
+The rest of the wiki continues to work, but only "Content-type: text/html" gets sent for this page.
+
+* Fresh ikiwiki --setup of 3.20141016-1 
+* Nginx
+
+Would this be something I'm doing wrong or a bug?

update
diff --git a/doc/bugs/outdated_jquery-ui.mdwn b/doc/bugs/outdated_jquery-ui.mdwn
index f74c66b..41d3f1b 100644
--- a/doc/bugs/outdated_jquery-ui.mdwn
+++ b/doc/bugs/outdated_jquery-ui.mdwn
@@ -3,4 +3,8 @@
            2010-5312, and/or 2012-6662)
 
 I'll do this next time I spend some time on ikiwiki unless Joey or
-Amitai gets there first. --[[smcv]]
+Amitai gets there first.
+
+It doesn't look as though we actually use the vulnerable functionality.
+
+--[[smcv]]

IRC is not a bug tracker
diff --git a/doc/bugs/outdated_jquery-ui.mdwn b/doc/bugs/outdated_jquery-ui.mdwn
new file mode 100644
index 0000000..f74c66b
--- /dev/null
+++ b/doc/bugs/outdated_jquery-ui.mdwn
@@ -0,0 +1,6 @@
+    < thm> joeyh: ping
+    < thm> can you update the embedded jquery-ui? (for cve 
+           2010-5312, and/or 2012-6662)
+
+I'll do this next time I spend some time on ikiwiki unless Joey or
+Amitai gets there first. --[[smcv]]

you'd get this error on any refresh?
diff --git a/doc/bugs/Spam:_recent_changes_discussion.mdwn b/doc/bugs/Spam:_recent_changes_discussion.mdwn
index 74188a3..f036374 100644
--- a/doc/bugs/Spam:_recent_changes_discussion.mdwn
+++ b/doc/bugs/Spam:_recent_changes_discussion.mdwn
@@ -23,4 +23,20 @@ The content is changing frequently without being checked into the git repository
 > that owns the wiki), commit that, and merge with the bare repository
 > if necessary.
 >
+> ----
+>
+> When I tried editing the spammed page to clear it, I got this error:
+>
+>     Error: /srv/www/Kurse/AFu-Lizenz/e09.tex independently created, not overwriting with version from Kurse/AFu-Lizenz/e09.tex
+>
+> Your srcdir and destdir seem to have got out of sync. You might need
+> to rebuild the wiki.
+>
+> (I think I'd have received the same error for *any* edit right now.)
+>
+> If you're going to enable completely anonymous editing, I
+> recommend monitoring the wiki more carefully. It might be useful
+> to enable the `syslog` option so that wiki errors go to the
+> system log.
+>
 > --[[smcv]]

moreinfo
diff --git a/doc/bugs/Spam:_recent_changes_discussion.mdwn b/doc/bugs/Spam:_recent_changes_discussion.mdwn
index cdaa5b8..74188a3 100644
--- a/doc/bugs/Spam:_recent_changes_discussion.mdwn
+++ b/doc/bugs/Spam:_recent_changes_discussion.mdwn
@@ -5,3 +5,22 @@ see <http://www.dk0tu.de/recentchanges/discussion/>
 The content is changing frequently without being checked into the git repository. Any ideas?
 
 --[[bastla]]
+
+> Please check your web server logs for any error messages from the CGI.
+> It seems likely that the spammer is editing that page but the changes
+> are somehow not getting committed or pushed.
+>
+> I can't tell you much without knowing details of your setup.
+> For instance, are you using the suggested git repository setup
+> shown in the diagram on the [[rcs/git]] page, or something
+> different? Can you publish a (possibly censored) setup file somewhere?
+>
+> It would probably also be worthwhile to compare the git history of
+> `srcdir/.git` with the git history of the bare repository, if you
+> have one.
+>
+> To recover, you could undo the spam in the `srcdir` (as the user ID
+> that owns the wiki), commit that, and merge with the bare repository
+> if necessary.
+>
+> --[[smcv]]

core: generate HTML5 by default, but keep avoiding new elements like <section> that require specific browser support unless html5 is set to 1.
diff --git a/debian/changelog b/debian/changelog
index ab48846..01f6066 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -13,6 +13,9 @@ ikiwiki (3.20141017) UNRELEASED; urgency=medium
     can mostly supersede the ikiwiki-calendar command.
     Thanks, Louis Paternault
   * search: add more classes as a hook for CSS. Thanks, sajolida
+  * core: generate HTML5 by default, but keep avoiding new elements
+    like <section> that require specific browser support unless html5 is
+    set to 1.
 
  -- Joey Hess <joeyh@debian.org>  Mon, 20 Oct 2014 12:04:49 -0400
 
diff --git a/doc/todo/generate_HTML5_by_default.mdwn b/doc/todo/generate_HTML5_by_default.mdwn
index f8d598c..56041d9 100644
--- a/doc/todo/generate_HTML5_by_default.mdwn
+++ b/doc/todo/generate_HTML5_by_default.mdwn
@@ -59,3 +59,5 @@ At the moment my preferred option is the last, for which see my `ready/html5`
 branch. I'll apply this at some point if there are no objections.
 
 --[[smcv]]
+
+> [[merged|done]] --[[smcv]]

review
diff --git a/doc/todo/Let_plugins_influence_what_environment_variables_a_wrapper_will_preserve.mdwn b/doc/todo/Let_plugins_influence_what_environment_variables_a_wrapper_will_preserve.mdwn
index 48901a2..4f44783 100644
--- a/doc/todo/Let_plugins_influence_what_environment_variables_a_wrapper_will_preserve.mdwn
+++ b/doc/todo/Let_plugins_influence_what_environment_variables_a_wrapper_will_preserve.mdwn
@@ -12,3 +12,53 @@ I was asked by [[Joey]] to create a page here for purposes of review. I'm still
 That seemed to be ok for reviewing [[bugs/CGI wrapper doesn't store PERL5LIB environment variable]], so I hope it's ok for this one too. If another way would be preferable, please let me know.
 
 -- [[jcflack]]
+
+> This is less about what plugins need, and more about what is safe.
+> If an environment variable is unsafe (in the sense of "can make a
+> setuid executable change its behaviour in dangerous ways") then we
+> must not pass it through, however desirable it might be.
+>
+> Because the only safe thing we can do is a whitelist, the list
+> is secondarily about what plugins need: if nothing needs a variable,
+> we don't pass it through.
+>
+> However, if a particular variable is safe, then it's always safe;
+> so if any plugin needs something, we might as well just put it in
+> the big list of things to keep. (In other words, any change to this
+> list is already security-sensitive.)
+>
+> As such, and because importing CGI into Setup pulls in a bunch
+> of extra code that is normally only imported when we are actually
+> running as a CGI, it might make more sense to have the "master list"
+> stay in Wrapper.
+>
+> What variables would `signinview` need? Can we just add them to
+> the list and skip the complexity of per-plugin configurability?
+>
+> Sorting the list makes sense to me, and so does adding the RFC 3875 set.
+>
+> [[!format txt """
+This change does seem to have exposed a thing where various plugins that
+call checksessionexpiry() (in CGI.pm) have been supplying one more argument
+than its prototype allows ... for years ...
+"""]]
+>
+> I fixed that in ikiwiki 3.20141016. Please don't add the extra ignored
+> parameter to the prototype.
+>
+> [[!format diff """
++ if ( $config{needenvkeys} ) {
+"""]]
+>
+> If this is needed at all, you should include this in the master list of
+> setup keys in IkiWiki.pm so it's documentable. Please mention setuid
+> in the description: "environment variables that are safe to pass through
+> a setuid wrapper" or something.
+>
+> I think it's `safe => 0, advanced => 1`.
+>
+> `preserve_env` or `env_keep` (or without the underscore, as you prefer)
+> might be better names for it (terminology stolen from `debuild` and `sudo`
+> respectively).
+>
+> --[[smcv]]

search: add more classes as a hook for CSS. Thanks, sajolida
diff --git a/debian/changelog b/debian/changelog
index 1cf3dce..ab48846 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -12,6 +12,7 @@ ikiwiki (3.20141017) UNRELEASED; urgency=medium
   * calendar: add calendar_autocreate option, with which "ikiwiki --refresh"
     can mostly supersede the ikiwiki-calendar command.
     Thanks, Louis Paternault
+  * search: add more classes as a hook for CSS. Thanks, sajolida
 
  -- Joey Hess <joeyh@debian.org>  Mon, 20 Oct 2014 12:04:49 -0400
 
diff --git a/doc/bugs/Impossible_to_resize_text_input_in_search_results.mdwn b/doc/bugs/Impossible_to_resize_text_input_in_search_results.mdwn
index 0cc5aca..68e49b9 100644
--- a/doc/bugs/Impossible_to_resize_text_input_in_search_results.mdwn
+++ b/doc/bugs/Impossible_to_resize_text_input_in_search_results.mdwn
@@ -43,3 +43,5 @@ Here is a patch:
      <hr>
     --
     2.1.1
+
+> [[Applied|done]], thanks --[[smcv]]

a plan
diff --git a/doc/todo/support_multiple_perl_libraries.mdwn b/doc/todo/support_multiple_perl_libraries.mdwn
index b71780f..06fd424 100644
--- a/doc/todo/support_multiple_perl_libraries.mdwn
+++ b/doc/todo/support_multiple_perl_libraries.mdwn
@@ -18,5 +18,23 @@ I think the change is a one-liner, but I put this here for discussion before att
 >
 > [[Louis|spalax]]
 
+>> Modifying `getconfig` is not a valid solution, because IkiWiki.pm is also imported by
+>> [[ikiwiki-transition]], [[ikiwiki-calendar]], the regression tests, etc.
+>>
+>> The way I would personally do it is to have a new non-exported function `getlibdirs`
+>> or something, have it do something like this:
+>>
+>>     if (! ref $config{libdir}) {
+>>             if (length $config{libdir}) {
+>>                     $config{libdir} = [$config{libdir}];
+>>             } else {
+>>                     $config{libdir} = [];
+>>             }
+>>     }
+>>     return @{$config{libdir}};
+>>
+>> and replace all uses of $config{libdir} with it.
+>>
+>> --[[smcv]]
 
 [[!taglink wishlist]]

Fix broken links in the basewiki
diff --git a/doc/ikiwiki/directive/calendar.mdwn b/doc/ikiwiki/directive/calendar.mdwn
index 412285c..4c2b99c 100644
--- a/doc/ikiwiki/directive/calendar.mdwn
+++ b/doc/ikiwiki/directive/calendar.mdwn
@@ -27,8 +27,8 @@ to display or list pages created in the given time frame.
 
 ## Generating archive pages
 
-If [[option|plugins/calendar]] `calendar_autocreate` is not set, the
-[[ikiwiki-calendar]] command can be used to automatically generate the archive
+If [[!iki plugins/calendar desc=option]] `calendar_autocreate` is not set, the
+[[!iki ikiwiki-calendar]] command can be used to automatically generate the archive
 pages. It also refreshes the wiki, updating the calendars to highlight the
 current day. This command is typically run at midnight from cron.
 
@@ -37,8 +37,9 @@ An example crontab:
     0 0 * * * ikiwiki-calendar ~/ikiwiki.setup "posts/* and !*/Discussion"
 
 
-With [[setup option|plugins/calendar]] `calendar_autocreate`, all this work is
-done by `ikiwiki` itself. Thus, the crontab command can be replaced by:
+With [[!iki plugins/calendar desc="setup option"]] `calendar_autocreate`,
+all this work is done by `ikiwiki` itself. Thus, the crontab command can be
+replaced by:
 
     0 0 * * * ikiwiki --setup ~/ikiwiki.setup --refresh
 
@@ -53,7 +54,7 @@ done by `ikiwiki` itself. Thus, the crontab command can be replaced by:
   for the whole wiki by setting `archivebase` in ikiwiki's setup file.
   Calendars link to pages under here, with names like "2010/04" and
   "2010". These pages can be automatically created using the
-  `calendar_autocreate` [[setup option|plugins/calendar]].
+  `calendar_autocreate` [[!iki plugins/calendar desc="setup option"]].
 * `year` - The year for which the calendar is requested. Defaults to the
   current year. Can also use -1 to refer to last year, and so on.
 * `month` - The numeric month for which the calendar is requested, in the

calendar: add calendar_autocreate option, with which "ikiwiki --refresh" can mostly supersede the ikiwiki-calendar command. Thanks, Louis Paternault
diff --git a/debian/changelog b/debian/changelog
index 014066e..1cf3dce 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,5 +1,6 @@
 ikiwiki (3.20141017) UNRELEASED; urgency=medium
 
+  [ Joey Hess ]
   * Added ikiwiki-comment program.
   * Add missing build-depends on libcgi-formbuilder-perl, needed for
     t/relativity.t
@@ -7,6 +8,11 @@ ikiwiki (3.20141017) UNRELEASED; urgency=medium
   * Set Debian package maintainer to Simon McVittie as I'm retiring from
     Debian.
 
+  [ Simon McVittie ]
+  * calendar: add calendar_autocreate option, with which "ikiwiki --refresh"
+    can mostly supersede the ikiwiki-calendar command.
+    Thanks, Louis Paternault
+
  -- Joey Hess <joeyh@debian.org>  Mon, 20 Oct 2014 12:04:49 -0400
 
 ikiwiki (3.20141016) unstable; urgency=medium
diff --git a/doc/todo/calendar_autocreate.mdwn b/doc/todo/calendar_autocreate.mdwn
index 371079d..c1f9c45 100644
--- a/doc/todo/calendar_autocreate.mdwn
+++ b/doc/todo/calendar_autocreate.mdwn
@@ -1,5 +1,7 @@
 Here is a patch that makes [[ikiwiki-calendar]] almost useless.
 
+> [[merged|done]], thanks! --[[smcv]]
+
 It adds some options, the main one being `calendar_autocreate`, which is
 similar to the `tag_autocreate` option of the [[tag|plugins/tag]]: it create
 archive pages when needed.

fix some typos
diff --git a/IkiWiki/Plugin/calendar.pm b/IkiWiki/Plugin/calendar.pm
index f0ac9ac..3d10b1e 100644
--- a/IkiWiki/Plugin/calendar.pm
+++ b/IkiWiki/Plugin/calendar.pm
@@ -193,7 +193,7 @@ sub gencalendaryear {
 		}
 
 		# Filling potential gaps in years (e.g. calendar goes from 2010 to 2014,
-		# and we just added year 2005. We have to had years 2006 to 2009).
+		# and we just added year 2005. We have to add years 2006 to 2009).
 		return if $params{norecurse};
 		if ($wikistate{calendar}{minyear} > $year) {
 			foreach my $other ($year + 1 .. $wikistate{calendar}{minyear} - 1) {
diff --git a/doc/plugins/calendar.mdwn b/doc/plugins/calendar.mdwn
index d55c21a..8d18ed0 100644
--- a/doc/plugins/calendar.mdwn
+++ b/doc/plugins/calendar.mdwn
@@ -17,12 +17,12 @@ pages from templates (overriding the existing ones).
 * `calendar_autocreate` - Control whether new archive pages are created as
   needed. It defaults to being done only if option `archivebase` is set.
 * `calendar_fill_gaps` - If set (and `calendar_autocreate` is set as well),
-  build calendar pages of emty years and months (but does not build pages older
+  build calendar pages of empty years and months (but does not build pages older
   than the older page, and younger than the younger page of the pagespec). If
-  not, thoses empty calendar pages will be skipped. *Please note:*
+  not, those empty calendar pages will be skipped. *Please note:*
   * The archive pages will not be automatically updated if this option changes.
     It is up to the user to delete relevant pages, and rebuild the wiki.
-  * When `calendar_fill_gaps` is set, and post is deleted, making the
+  * When `calendar_fill_gaps` is set, and a post is deleted, making the
     corresponding year/month empty, the corresponding page is left, and shows
     an empty calendar. This is on purpose, not to break any external link
     pointing to this particular page. If you do not like it, delete the

diff --git a/doc/index.mdwn b/doc/index.mdwn
index 336f625..f4073aa 100644
--- a/doc/index.mdwn
+++ b/doc/index.mdwn
@@ -30,4 +30,4 @@ The [[RoadMap]] describes where the project is going.
 can be submitted and tracked using this wiki.
 
 Ikiwiki is developed by [[Joey]] and many contributors,
-and is [[FreeSoftware]]. asdf
+and is [[FreeSoftware]].

diff --git a/doc/index.mdwn b/doc/index.mdwn
index f4073aa..336f625 100644
--- a/doc/index.mdwn
+++ b/doc/index.mdwn
@@ -30,4 +30,4 @@ The [[RoadMap]] describes where the project is going.
 can be submitted and tracked using this wiki.
 
 Ikiwiki is developed by [[Joey]] and many contributors,
-and is [[FreeSoftware]].
+and is [[FreeSoftware]]. asdf

Thoughts about several libdirs
diff --git a/doc/todo/support_multiple_perl_libraries.mdwn b/doc/todo/support_multiple_perl_libraries.mdwn
index 2869b50..b71780f 100644
--- a/doc/todo/support_multiple_perl_libraries.mdwn
+++ b/doc/todo/support_multiple_perl_libraries.mdwn
@@ -8,4 +8,15 @@ I think the change is a one-liner, but I put this here for discussion before att
 
 [[DavidBremner]]
 
+> I would like this feature too, for the very same reasons.
+>
+> To preserve backward compatibility, I tried to implement it in the following way: if `libdir` is a string, it is (as it is right now), a directory in which plugins can be searched; if `libdir` is an array of strings, it is a list of libdirs. The ideal place to put it in would be in subroutine [checkconfig](http://source.ikiwiki.branchable.com/?p=source.git;a=blob;f=IkiWiki.pm;hb=56f8223f9594ae687099dada0c138d669a6f931f#l569). However, plugins are loaded (and option `libdir` is used) in subroutine [loadplugins](http://source.ikiwiki.branchable.com/?p=source.git;a=blob;f=IkiWiki.pm;hb=56f8223f9594ae687099dada0c138d669a6f931f#l713), which is called [just before `checkconfig`](http://source.ikiwiki.branchable.com/?p=source.git;a=blob;f=ikiwiki.in;hb=729991564ec7e1116fc023c51e73b47af8b6fce7#l143).
+>
+> A solution would be to check `libdir` (and turn it into a list if necessary) somewhere in subroutine [getconfig](http://source.ikiwiki.branchable.com/?p=source.git;a=blob;f=ikiwiki.in;hb=729991564ec7e1116fc023c51e73b47af8b6fce7#l26), but I do not know where to put it not to make it look like a bad hack…
+>
+> Any idea about the best place to preprocess `libdir`? Or any better idea to implement this?
+>
+> [[Louis|spalax]]
+
+
 [[!taglink wishlist]]

diff --git a/doc/bugs/Spam:_recent_changes_discussion.mdwn b/doc/bugs/Spam:_recent_changes_discussion.mdwn
index 88e984b..cdaa5b8 100644
--- a/doc/bugs/Spam:_recent_changes_discussion.mdwn
+++ b/doc/bugs/Spam:_recent_changes_discussion.mdwn
@@ -1,5 +1,7 @@
 We have a weird spam problem on our site - must be something via CGI.
 
-see http://www.dk0tu.de/recentchanges/discussion/
+see <http://www.dk0tu.de/recentchanges/discussion/>
 
 The content is changing frequently without being checked into the git repository. Any ideas?
+
+--[[bastla]]

Discussion Spam
diff --git a/doc/bugs/Spam:_recent_changes_discussion.mdwn b/doc/bugs/Spam:_recent_changes_discussion.mdwn
new file mode 100644
index 0000000..88e984b
--- /dev/null
+++ b/doc/bugs/Spam:_recent_changes_discussion.mdwn
@@ -0,0 +1,5 @@
+We have a weird spam problem on our site - must be something via CGI.
+
+see http://www.dk0tu.de/recentchanges/discussion/
+
+The content is changing frequently without being checked into the git repository. Any ideas?

Added a comment
diff --git a/doc/forum/Federated_wiki__63__/comment_2_bbfb11517e968311419a8cd2d77de189._comment b/doc/forum/Federated_wiki__63__/comment_2_bbfb11517e968311419a8cd2d77de189._comment
new file mode 100644
index 0000000..7fe8366
--- /dev/null
+++ b/doc/forum/Federated_wiki__63__/comment_2_bbfb11517e968311419a8cd2d77de189._comment
@@ -0,0 +1,7 @@
+[[!comment format=mdwn
+ username="anarcat"
+ subject="comment 2"
+ date="2014-11-20T03:16:50Z"
+ content="""
+you should probably look at the [[tips/distributed_wikis/]] page, which details a few of those scenarios. --[[anarcat]]
+"""]]

thanks Patrick ZAJDA for a kind contribution
diff --git a/doc/tipjar.mdwn b/doc/tipjar.mdwn
index 80d8f5c..d23dc10 100644
--- a/doc/tipjar.mdwn
+++ b/doc/tipjar.mdwn
@@ -18,6 +18,7 @@ Thanks to the following people for their kind contributions:
 * Jon Dowland
 * Amitai Schlair
 * Luca Capello
+* Patrick ZAJDA
 
 (Note that this page is locked to prevent anyone from tampering with the PayPal link.
 If you prefer your donation *not* be listed here, let [[Joey]] know.)

diff --git a/doc/sandbox.mdwn b/doc/sandbox.mdwn
index 748fdbe..9aeb10d 100644
--- a/doc/sandbox.mdwn
+++ b/doc/sandbox.mdwn
@@ -36,6 +36,7 @@ Numbered list
     1. foo
     2. bar
     3. quz
+    3. quze
 
 Bulleted list
 

Amendment, following review
diff --git a/doc/todo/calendar_autocreate.mdwn b/doc/todo/calendar_autocreate.mdwn
index 2a7350b..371079d 100644
--- a/doc/todo/calendar_autocreate.mdwn
+++ b/doc/todo/calendar_autocreate.mdwn
@@ -191,22 +191,30 @@ sub gencalendaryear {
 >
 > I think that should be `ikiwiki --setup ~/ikiwiki.setup --refresh`
 >
+> > [[Corrected|https://github.com/paternal/ikiwiki/commit/213dad76d47bab9db8e44d6e20c8371960375e77]]
+>
 > The indentation of some of the new code in `IkiWiki/Plugin/calendar.pm`
 > is weird. Please use one hard tab (U+0009) per indent step: you seem
 > to have used a mixture of one hard tab per indent or two spaces
 > per indent, which looks bizarre for anyone whose tab size is not
 > 2 spaces.
 >
+> > [[Corrected|https://github.com/paternal/ikiwiki/commit/1d97160dae775c31e166d9886472dacdd773d571]]
+>
 >     +	return unless $config{calendar_autocreate};
 >
 > This is checked in `gencalendaryear` but not in `gencalendarmonth`.
 > Shouldn't `gencalendarmonth` do it too? Alternatively, do the check
 > in `scan`, which calls `gencalendarmonth` directly.
 >
+> > Once again, [[you are right|https://github.com/paternal/ikiwiki/commit/473bcbe7a42a4168cab82ed12185817248de045f]]
+>
 >     +		my $year  = $date[5] + 1900;
 >
 > You calculate this, but you don't seem to do anything with it?
 >
+> > [[Corrected|https://github.com/paternal/ikiwiki/commit/d0b34951240317642543351ec62f98d3d8df8c0f]]
+>
 >     +  if (not exists $changed{$params{year}}) {
 >     +    $changed{$params{year}} = ();
 >     +  }
@@ -222,4 +230,9 @@ sub gencalendaryear {
 > in order to put the pair `$params{month} => 1` in it (the term to look
 > up if you're curious is "autovivification").
 >
+> > [[Corrected|https://github.com/paternal/ikiwiki/commit/d0b34951240317642543351ec62f98d3d8df8c0f]]
+>
 > --[[smcv]]
+>
+> > Thank you for your review.
+> > --[[Louis|spalax]]

typo
diff --git a/doc/ikiwiki/directive/calendar.mdwn b/doc/ikiwiki/directive/calendar.mdwn
index 4814b02..412285c 100644
--- a/doc/ikiwiki/directive/calendar.mdwn
+++ b/doc/ikiwiki/directive/calendar.mdwn
@@ -40,7 +40,7 @@ An example crontab:
 With [[setup option|plugins/calendar]] `calendar_autocreate`, all this work is
 done by `ikiwiki` itself. Thus, the crontab command can be replaced by:
 
-    0 0 * * * ikiwiki ~/ikiwiki.setup --refresh
+    0 0 * * * ikiwiki --setup ~/ikiwiki.setup --refresh
 
 ## usage
 

Add "patch" tag.
diff --git a/doc/bugs/Impossible_to_resize_text_input_in_search_results.mdwn b/doc/bugs/Impossible_to_resize_text_input_in_search_results.mdwn
index da4c798..0cc5aca 100644
--- a/doc/bugs/Impossible_to_resize_text_input_in_search_results.mdwn
+++ b/doc/bugs/Impossible_to_resize_text_input_in_search_results.mdwn
@@ -11,6 +11,8 @@ the sidebar.
 Having CSS selectors to style the elements of this form would solve our
 problem.
 
+[[!tag patch]]
+
 Here is a patch:
 
     From c4c6c9bf3b296c2db10d6fb9e6421d82f341b1cf Mon Sep 17 00:00:00 2001

file bug
diff --git a/doc/bugs/Impossible_to_resize_text_input_in_search_results.mdwn b/doc/bugs/Impossible_to_resize_text_input_in_search_results.mdwn
new file mode 100644
index 0000000..da4c798
--- /dev/null
+++ b/doc/bugs/Impossible_to_resize_text_input_in_search_results.mdwn
@@ -0,0 +1,43 @@
+While working on the [Tails website](https://tails.boum.org/), I didn't
+managed to resize the text input on top of the search results.
+
+This is problematic with our layout and it might be the same for others.
+For example, reducing a bit the width of the browser on [this
+page](https://tails.boum.org/ikiwiki.cgi?P=testing) makes the search
+results jump at the bottom of the page since the text input is wider
+(size=65 by default) than the body of the page when side by side with
+the sidebar.
+
+Having CSS selectors to style the elements of this form would solve our
+problem.
+
+Here is a patch:
+
+    From c4c6c9bf3b296c2db10d6fb9e6421d82f341b1cf Mon Sep 17 00:00:00 2001
+    From: sajolida <sajolida@pimienta.org>
+    Date: Sun, 9 Nov 2014 16:48:33 +0100
+    Subject: [PATCH] Add classes to form in search results
+    
+    This is needed to style it, for example to reduce the width of the text
+    input and prevent layout issues.
+    ---
+     templates/searchquery.tmpl | 4 ++--
+     1 file changed, 2 insertions(+), 2 deletions(-)
+    
+    diff --git a/templates/searchquery.tmpl b/templates/searchquery.tmpl
+    index 15bc78e..6277266 100644
+    --- a/templates/searchquery.tmpl
+    +++ b/templates/searchquery.tmpl
+    @@ -33,8 +33,8 @@ $def{NEXT,$if{$ne{$last,$msize},<INPUT TYPE=submit NAME="&gt;" VALUE="Next">}}
+     
+     <FORM NAME=P METHOD=GET
+     ACTION="$html{$env{CGIURL}}" TARGET="_top">
+    -<div style="text-align:center">
+    -<INPUT NAME=P VALUE="$html{$query}" SIZE=65>
+    +<div class="searchquery" style="text-align:center">
+    +<INPUT class="searchbox" NAME=P VALUE="$html{$query}" SIZE=65>
+     <INPUT TYPE=SUBMIT VALUE="Search">
+     $env{HELPLINK}
+     <hr>
+    --
+    2.1.1

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

Update RTL tip to use dir instead of class
diff --git a/doc/tips/Right-to-left___40__RTL__41___page_text.mdwn b/doc/tips/Right-to-left___40__RTL__41___page_text.mdwn
index 2b176c8..339f05b 100644
--- a/doc/tips/Right-to-left___40__RTL__41___page_text.mdwn
+++ b/doc/tips/Right-to-left___40__RTL__41___page_text.mdwn
@@ -10,7 +10,7 @@ footer. Only what is rendered from the mdwn file is affected.
 
 Create a new template page *templates/rtl.mdwn* with the following content:
 
-    <div class="rtl">
+    <div dir="rtl">
     <TMPL_VAR text>
     </div>
     <TMPL_UNLESS text>
@@ -21,18 +21,7 @@ Create a new template page *templates/rtl.mdwn* with the following content:
     </ul>
     </TMPL_UNLESS>
 
-# 2 Add an RTL class to the CSS
-
-In your *local.css* add the following:
-
-[[!format css """
-/* rtl template */
-.rtl {
-    direction: rtl;
-}
-"""]]
-
-# 3 Use the Template
+# 2 Use the Template
 
 To make a page or part of it RTL, use the [[ikiwiki/directive/template]] directive:
 

Ask about forum/ML integration
diff --git a/doc/forum/proposal:_mailing_list_and_forum_integration.mdwn b/doc/forum/proposal:_mailing_list_and_forum_integration.mdwn
new file mode 100644
index 0000000..57f2fc3
--- /dev/null
+++ b/doc/forum/proposal:_mailing_list_and_forum_integration.mdwn
@@ -0,0 +1,21 @@
+For a while I've been wondering how to use a communication channel which can be
+accessed both by e-mail and web interface, while using ikiwiki's git repo. There
+are solutions like Drupal which can combine mailing lists and a forum, but then
+you lose the ikiwiki integration.
+
+So I had an idea:
+
+What if an ikiwiki server subscribes to a mailing list, and automatically posts
+under a "forum" page (like the [[/forum]] here) every time it gets a new e-mail?
+And when someone posts a new entry using git or the web UI, it can send an
+e-mail to the mailing list! (perhaps mark it somehow to avoid an infinite loop)
+
+Does something like this make sense? It can work not only with e-mail but also
+with other forum tools (e.g. Syndie). Are there any critical synchronization
+issues I'm missing? If not, I'd like to suggest this as a feature and add this
+to my todo list :-)
+
+Currently I have mail and forum separate, and I'd like to integrate them. If I
+get positive feedback, I'll start working on it at some point (soon, I hope).
+
+-- [[fr33domlover]]

diff --git a/doc/plugins/contrib/sqlite__95__search.mdwn b/doc/plugins/contrib/sqlite__95__search.mdwn
new file mode 100644
index 0000000..cc205b5
--- /dev/null
+++ b/doc/plugins/contrib/sqlite__95__search.mdwn
@@ -0,0 +1,5 @@
+[[!template id="plugin" name="sqlite_search" author="Baldur Kristinsson"]]
+
+The [sqlite_search plugin](https://github.com/bk/ikiwiki-plugin-sqlite_search), available on GitHub, provides a full text search backend for those who, for one reason or another, find it impractical or bothersome to install or configure the Xapian-based backend of the search module which comes with IkiWiki. Practically the only dependency is DBD::SQLite.
+
+It is suitable for small and medium sites in a language written using the Latin alphabet and with a UTF-8 locale.

add copyleft.org
and tweak wording
diff --git a/doc/ikiwikiusers.mdwn b/doc/ikiwikiusers.mdwn
index bc5df6c..e3a5002 100644
--- a/doc/ikiwikiusers.mdwn
+++ b/doc/ikiwikiusers.mdwn
@@ -6,7 +6,7 @@ Feel free to add your own ikiwiki site! In case you have created a custom theme
 See also: [Debian ikiwiki popcon graph](http://qa.debian.org/popcon.php?package=ikiwiki)
 and [google search for ikiwiki powered sites](http://www.google.com/search?q=%22powered%20by%20ikiwiki%22).
 
-While nothing makes me happier than knowing that ikiwiki has happy users,
+While nothing makes us happier than knowing that ikiwiki has happy users,
 dropping some change in the [[TipJar]] is a nice way to show extra
 appreciation.
 
@@ -100,6 +100,7 @@ Projects & Organizations
 * [[Smuxi IRC Client|https://smuxi.im/]] - powerful IRC client for GNOME
 * [[hplusroadmap|http://diyhpl.us/wiki/]] - a community for open source hardware, do-it-yourself biohacking and practical transhumanism
 * [[OpenAFS|http://wiki.openafs.org]] - an open-source, cross-platform distributed file system
+* [Copyleft.org](http://copyleft.org/)
 
 Personal sites and blogs
 ========================

Added a comment
diff --git a/doc/forum/Federated_wiki__63__/comment_1_44b7dbfb6035fc387e1e79c35b27d003._comment b/doc/forum/Federated_wiki__63__/comment_1_44b7dbfb6035fc387e1e79c35b27d003._comment
new file mode 100644
index 0000000..95a6c28
--- /dev/null
+++ b/doc/forum/Federated_wiki__63__/comment_1_44b7dbfb6035fc387e1e79c35b27d003._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawkwqKsWfFCk-NK99S77R2v1JorVCnpzXUA"
+ nickname="Dave"
+ subject="comment 1"
+ date="2014-11-07T16:25:57Z"
+ content="""
+Apparently the author of the article uses this: https://github.com/WardCunningham/Smallest-Federated-Wiki
+"""]]

diff --git a/doc/forum/Federated_wiki__63__.mdwn b/doc/forum/Federated_wiki__63__.mdwn
index 16c2072..cdf76a9 100644
--- a/doc/forum/Federated_wiki__63__.mdwn
+++ b/doc/forum/Federated_wiki__63__.mdwn
@@ -1,10 +1,6 @@
 Has anyone experimented with pulling commits from an external ikiwiki into your own?
 
-I ask because I've just read a great article about Federated Wikis.
-
-Here's the link.  http://hapgood.us/2014/11/06/federated-education-new-directions-in-digital-collaboration/
-
-...I probably won't be able to post this because of the link.  Let's see.
+I ask because I've just read a great [article about Federated Wikis](http://hapgood.us/2014/11/06/federated-education-new-directions-in-digital-collaboration/ "Federated Education: New Directions In Digital Collaboration").
 
 Anyway, the author opens with the idea that good ideas are often lost or delayed for years because of we don't communicate as well as we could.  He presents an example: Arthur C. Clarke speculating about GPS over a decade before Sputnik.
 

diff --git a/doc/forum/Federated_wiki__63__.mdwn b/doc/forum/Federated_wiki__63__.mdwn
new file mode 100644
index 0000000..16c2072
--- /dev/null
+++ b/doc/forum/Federated_wiki__63__.mdwn
@@ -0,0 +1,19 @@
+Has anyone experimented with pulling commits from an external ikiwiki into your own?
+
+I ask because I've just read a great article about Federated Wikis.
+
+Here's the link.  http://hapgood.us/2014/11/06/federated-education-new-directions-in-digital-collaboration/
+
+...I probably won't be able to post this because of the link.  Let's see.
+
+Anyway, the author opens with the idea that good ideas are often lost or delayed for years because of we don't communicate as well as we could.  He presents an example: Arthur C. Clarke speculating about GPS over a decade before Sputnik.
+
+He goes on to present the idea of a federation of wikis.  Note: 'federation' is used as a technical term here: cf. email or Google Wave.
+
+I for one am persuaded by his article, because wiki federation is an idea I've had before!
+
+With ikiwiki, couldn't it work just by adding external wikis as remotes and selectively merging from them?
+
+Cheers,
+
+--Dave

Fixes perl-magick link #2
diff --git a/doc/plugins/img.mdwn b/doc/plugins/img.mdwn
index f23409a..9eadb65 100644
--- a/doc/plugins/img.mdwn
+++ b/doc/plugins/img.mdwn
@@ -8,7 +8,7 @@ easily scale down an image for inclusion onto a page, providing a link to a
 full-size version.
 
 This plugin uses the [ImageMagick](http://www.imagemagick.org/) tools via
-[PerlMagick](http://www.imagemagick.org/script/perl-magick.html).
+[PerlMagick](http://www.imagemagick.org/script/perl-magick.php).
 
 Note that this is a stripped down version of Christian Mock's
 [[original_img_plugin|contrib/img]].

Fixes perl-magick link
diff --git a/doc/plugins/img.mdwn b/doc/plugins/img.mdwn
index a6cd90f..f23409a 100644
--- a/doc/plugins/img.mdwn
+++ b/doc/plugins/img.mdwn
@@ -8,7 +8,7 @@ easily scale down an image for inclusion onto a page, providing a link to a
 full-size version.
 
 This plugin uses the [ImageMagick](http://www.imagemagick.org/) tools via
-[PerlMagick](http://www.imagemagick.org/www/perl-magick.html).
+[PerlMagick](http://www.imagemagick.org/script/perl-magick.html).
 
 Note that this is a stripped down version of Christian Mock's
 [[original_img_plugin|contrib/img]].

typos
diff --git a/doc/plugins/contrib/compile/discussion.mdwn b/doc/plugins/contrib/compile/discussion.mdwn
index c2d2f6c..fbf9f22 100644
--- a/doc/plugins/contrib/compile/discussion.mdwn
+++ b/doc/plugins/contrib/compile/discussion.mdwn
@@ -43,7 +43,7 @@ command...
 >       like `latex foo.tex && dvipdf foo.dvi`).
 >   - the `compile_unsecure` would:
 >     - forbid commands to be strings (thus, forbidding shell commands, and preventing command injections);
->     - forbid compilation using Makefile or executable prevent in the wiki (to prevent users from modifying those files, and executing arbitrary commands);
+>     - forbid compilation using Makefile or executable present in the wiki (to prevent users from modifying those files, and executing arbitrary commands);
 >     - forbid directive argument `build`.
 >
 >

How signinview handles the goto leak
diff --git a/doc/todo/Zoned_ikiwiki.mdwn b/doc/todo/Zoned_ikiwiki.mdwn
index c2dfb7a..76b2b69 100644
--- a/doc/todo/Zoned_ikiwiki.mdwn
+++ b/doc/todo/Zoned_ikiwiki.mdwn
@@ -128,15 +128,12 @@ Note that not all of these issues will be problems for all **zoned ikiwiki use c
 An unauthorized client can use a `do=goto` request to find out whether a
 page exists (will be forbidden to view it) or not (will be forbidden to create it).
 
-My first idea was to fix this all within [[plugins/contrib/signinview]] by hooking
-`cgi` first and checking for `goto` and an unauthorized page. But checking authorization
-requires session info, not loaded at `cgi` hook time. Next idea was to somehow skip the rest of
-the chain of `cgi` hooks, preventing `goto` from handling the request, and handling
-it again in `sessioncgi`. But 'skip the rest of this chain' doesn't seem to be something
-a hook can return.
-
-Hmm, maybe change the `do` parameter to something other than `goto` before the `goto` hook
-can see it, _then_ handle it later in `sessioncgi`?
+In [[plugins/contrib/signinview]] this is handled by hooking
+`cgi` first and checking for `goto` and a non-public page. If the requested page
+(existing or not) matches the `public_pages` PageSpec, it is handed off for the `goto`
+plugin to handle normally. Otherwise, the `do` parameter is changed to `signingoto`
+so the `goto` plugin's `cgi` hook will _not_ handle it, and the `sessioncgi` hook
+takes care of it when the user's identity is available.
 
 ### Backlinks
 

Answer
diff --git a/doc/plugins/contrib/compile/discussion.mdwn b/doc/plugins/contrib/compile/discussion.mdwn
index 96269d4..c2d2f6c 100644
--- a/doc/plugins/contrib/compile/discussion.mdwn
+++ b/doc/plugins/contrib/compile/discussion.mdwn
@@ -14,3 +14,39 @@ script specified in setup file - then e.g. you can choose which commands are all
 What do you think?
 
 -- [[fr33domlover]]
+
+> The problem you mention is known, and is not a problem for me, since I am the
+only user of the wiki. However, if we need a *secure* version of this
+command...
+>
+> Imagine we have a setup option `compile_unsecure`.
+>
+> The directive takes the following arguments 
+>
+> - filetype: No problem.
+> - build: Forbidden.
+> - source: No problem.
+> - template: No problem.
+> - destname and files: The problem is that right now, the command is run using a shell
+>   call. Thus, a user can easily use this argument to inject malicious
+>   commands (something like \[[!compile files=";rm -fr *"]] (well, this
+>   actually would not work, but you get the idea)). I do want to keep the
+>   ability to use shell commands, for the flexibility it provides, but I imagine
+>   we can:
+>   - interpret the `build` command depending on its type:
+>     - if it is a string, it is interpreted as a shell command;
+>     - if it is a list of strings, the first one is the command to execute,
+>       the following ones are the arguments. If I am not wrong, this should
+>       prevent command injection.
+>     - if it is a list of lists of strings, it is a list of commands to
+>       execute (execution being stopped on the first error; usefull for stuff
+>       like `latex foo.tex && dvipdf foo.dvi`).
+>   - the `compile_unsecure` would:
+>     - forbid commands to be strings (thus, forbidding shell commands, and preventing command injections);
+>     - forbid compilation using Makefile or executable prevent in the wiki (to prevent users from modifying those files, and executing arbitrary commands);
+>     - forbid directive argument `build`.
+>
+>
+> Any thoughts?
+>
+> -- [[Louis|spalax]]

do=goto leaks page existence
diff --git a/doc/todo/Zoned_ikiwiki.mdwn b/doc/todo/Zoned_ikiwiki.mdwn
index 6b56221..c2dfb7a 100644
--- a/doc/todo/Zoned_ikiwiki.mdwn
+++ b/doc/todo/Zoned_ikiwiki.mdwn
@@ -123,6 +123,21 @@ but I'll begin it here.
 
 Note that not all of these issues will be problems for all **zoned ikiwiki use cases**.
 
+### Leakage of page existence by `do=goto`
+
+An unauthorized client can use a `do=goto` request to find out whether a
+page exists (will be forbidden to view it) or not (will be forbidden to create it).
+
+My first idea was to fix this all within [[plugins/contrib/signinview]] by hooking
+`cgi` first and checking for `goto` and an unauthorized page. But checking authorization
+requires session info, not loaded at `cgi` hook time. Next idea was to somehow skip the rest of
+the chain of `cgi` hooks, preventing `goto` from handling the request, and handling
+it again in `sessioncgi`. But 'skip the rest of this chain' doesn't seem to be something
+a hook can return.
+
+Hmm, maybe change the `do` parameter to something other than `goto` before the `goto` hook
+can see it, _then_ handle it later in `sessioncgi`?
+
 ### Backlinks
 
 What is problematic is when you link a public page in a private page : 

Patch submitted for contrib/ymlfront sticky-metadata issue.
diff --git a/doc/plugins/contrib/ymlfront/discussion.mdwn b/doc/plugins/contrib/ymlfront/discussion.mdwn
index 868e9cd..15f2cf8 100644
--- a/doc/plugins/contrib/ymlfront/discussion.mdwn
+++ b/doc/plugins/contrib/ymlfront/discussion.mdwn
@@ -1,3 +1,5 @@
+**Update:** I've submitted a patch, [rubykat/ikiplugins pull request #5](https://github.com/rubykat/ikiplugins/issues/5).
+
 I have just opened [rubykat/ikiplugins issue #4](https://github.com/rubykat/ikiplugins/issues/4)
 regarding the fact that ymlfront doesn't seem to delete any old pagestate when fields have been
 removed in an edit. The fields are stuck there with their old values until a full rebuild. Seems

Update comment
diff --git a/doc/plugins/contrib/compile/discussion.mdwn b/doc/plugins/contrib/compile/discussion.mdwn
index 7777750..96269d4 100644
--- a/doc/plugins/contrib/compile/discussion.mdwn
+++ b/doc/plugins/contrib/compile/discussion.mdwn
@@ -7,7 +7,9 @@ Problem: Any user can change the command to something dangerous that deletes fil
 causes irreversible damage to the system. I can even happen by mistake.
 
 Suggestion: Add an option to the setup file that forbids to override the build command in the
-directive, and then only the setup file can configure build commands (if you want).
+directive, and then only the setup file can configure build commands (if you want). Another
+idea, an option to validate the build command, either against a regex or using an arbitrary
+script specified in setup file - then e.g. you can choose which commands are allowed.
 
 What do you think?
 

Command on compile plugin
diff --git a/doc/plugins/contrib/compile/discussion.mdwn b/doc/plugins/contrib/compile/discussion.mdwn
new file mode 100644
index 0000000..7777750
--- /dev/null
+++ b/doc/plugins/contrib/compile/discussion.mdwn
@@ -0,0 +1,14 @@
+This plugin sounds exactly like what I need! I too have sources I want to compile on the fly,
+such as diagrams made with Dia and perhaps API reference manuals made with Doxygen.
+
+I'd like to use it, but -
+
+Problem: Any user can change the command to something dangerous that deletes file and
+causes irreversible damage to the system. I can even happen by mistake.
+
+Suggestion: Add an option to the setup file that forbids to override the build command in the
+directive, and then only the setup file can configure build commands (if you want).
+
+What do you think?
+
+-- [[fr33domlover]]

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

file bug
diff --git a/doc/bugs/po_plugin_config_change_can_lead_to_refresh_bugs.mdwn b/doc/bugs/po_plugin_config_change_can_lead_to_refresh_bugs.mdwn
new file mode 100644
index 0000000..c8ce4f4
--- /dev/null
+++ b/doc/bugs/po_plugin_config_change_can_lead_to_refresh_bugs.mdwn
@@ -0,0 +1,25 @@
+I have here a site that uses the po plugin, and recently had this change
+committed to its setup:
+
+<pre>
+ po_slave_languages:
+ - de|Deutsch
+ - fr|Français
+-- ja|日本語
+-- tr|Türkçe
+</pre>
+
+The change was made by the web UI, so it must have involved a site rebuild
+at the time, as that configuration item has `rebuild => 1`.
+
+Some days after that config change, a push caused ikiwiki refresh to fail:
+
+    remote: /home/b-udm/public_html/Discussion/index.ja.html independently created, not overwriting with version from Discussion.ja
+
+Rebuilding the wiki cleared that up, but it seems that po plugin config
+changes can lead to follow-on problems of this sort.
+
+The site still has a `source/index.ja.po`. And it has
+`public_html/index.ja.html`, as well as `public_html/index.ja/index.html`.
+
+--[[Joey]]

Forgot download link
diff --git a/doc/plugins/contrib/compile.mdwn b/doc/plugins/contrib/compile.mdwn
index 7ae4968..564f7f6 100644
--- a/doc/plugins/contrib/compile.mdwn
+++ b/doc/plugins/contrib/compile.mdwn
@@ -206,3 +206,7 @@ For instance, if you have a `.tiff` file you want to convert to png before
 displaying it on your website, you can use as a template:
 
     <img src="<TMPL_VAR DESTURL>">
+
+# Download
+
+Code and documentation can be found here : [[https://atelier.gresille.org/projects/gresille-ikiwiki/wiki/Compile]].

Typos...
diff --git a/doc/todo/MUA-like_access_to_forum__47__blog.mdwn b/doc/todo/MUA-like_access_to_forum__47__blog.mdwn
index d61aac5..4468a65 100644
--- a/doc/todo/MUA-like_access_to_forum__47__blog.mdwn
+++ b/doc/todo/MUA-like_access_to_forum__47__blog.mdwn
@@ -34,4 +34,4 @@ done with mailing lists?
 (I don't mind a hacked solution that solves the problem for me, but if it's not just
 me being crazy, I prefer a general-purpose solution that helps everyone)
 
--- [[fr3domlover]]
+-- [[fr33domlover]]

diff --git a/doc/todo/MUA-like_access_to_forum__47__blog.mdwn b/doc/todo/MUA-like_access_to_forum__47__blog.mdwn
index 8d11a55..d61aac5 100644
--- a/doc/todo/MUA-like_access_to_forum__47__blog.mdwn
+++ b/doc/todo/MUA-like_access_to_forum__47__blog.mdwn
@@ -33,3 +33,5 @@ done with mailing lists?
 
 (I don't mind a hacked solution that solves the problem for me, but if it's not just
 me being crazy, I prefer a general-purpose solution that helps everyone)
+
+-- [[fr3domlover]]

diff --git a/doc/todo/MUA-like_access_to_forum__47__blog.mdwn b/doc/todo/MUA-like_access_to_forum__47__blog.mdwn
index 54cc8e8..8d11a55 100644
--- a/doc/todo/MUA-like_access_to_forum__47__blog.mdwn
+++ b/doc/todo/MUA-like_access_to_forum__47__blog.mdwn
@@ -33,41 +33,3 @@ done with mailing lists?
 
 (I don't mind a hacked solution that solves the problem for me, but if it's not just
 me being crazy, I prefer a general-purpose solution that helps everyone)
-
-
-
-[[!tag wishlist]]
-
-Maybe I'm not using ikiwiki right, and I'll appreciate any advice on this, but
-it seems to me that using ikiwiki instead of a mailing lists has some major
-weaknesses which I fail to overcome, but which may be possible to fix, maybe
-using some client-side software.
-
-The problem: Mailing lists give me things I need but can't find here, so I'm
-failing to track the [[/forum]], [[/todo]] and so on:
-
-- With MLs I can easily see what I read, to what I replied, mark things with
-  colors and labels if my MUA supports it
-- With MLs I can easily send a reply, without going through git. Reading and
-  writing happen together in the same dedicated UI
-
-I know I can subscribe to [[forum]] and to individual posts' comment feeds, but
-it's not the same - I don't see the tree of comments like in e-mail. Either I
-sort by creation time (not seeing evidence of more recent replies) or by
-last-edited time, or perhaps by last comment (then busy pages cause less busy
-ones quickly go deep into the list and are never seen by the user).
-
-Is there an existing solution to this?
-
-Random ideas, maybe direction for a solution:
-
-- Make client software which takes a local git clone of a wiki and operates on
-  it, while the user sees an MUA-like interface
-- Add some plugin to ikiwiki that can cooperate with an MTA: listen to e-mail
-  on a mailing list with specific formatting and put the content into a wiki.
-
-What do you think? How do you keep track of the forum etc. in the same way it's
-done with mailing lists?
-
-(I don't mind a hacked solution that solves the problem for me, but if it's not just
-me being crazy, I prefer a general-purpose solution that helps everyone)

wishlist: ask about using ikiwiki as ML
diff --git a/doc/todo/MUA-like_access_to_forum__47__blog.mdwn b/doc/todo/MUA-like_access_to_forum__47__blog.mdwn
index 8d11a55..54cc8e8 100644
--- a/doc/todo/MUA-like_access_to_forum__47__blog.mdwn
+++ b/doc/todo/MUA-like_access_to_forum__47__blog.mdwn
@@ -33,3 +33,41 @@ done with mailing lists?
 
 (I don't mind a hacked solution that solves the problem for me, but if it's not just
 me being crazy, I prefer a general-purpose solution that helps everyone)
+
+
+
+[[!tag wishlist]]
+
+Maybe I'm not using ikiwiki right, and I'll appreciate any advice on this, but
+it seems to me that using ikiwiki instead of a mailing lists has some major
+weaknesses which I fail to overcome, but which may be possible to fix, maybe
+using some client-side software.
+
+The problem: Mailing lists give me things I need but can't find here, so I'm
+failing to track the [[/forum]], [[/todo]] and so on:
+
+- With MLs I can easily see what I read, to what I replied, mark things with
+  colors and labels if my MUA supports it
+- With MLs I can easily send a reply, without going through git. Reading and
+  writing happen together in the same dedicated UI
+
+I know I can subscribe to [[forum]] and to individual posts' comment feeds, but
+it's not the same - I don't see the tree of comments like in e-mail. Either I
+sort by creation time (not seeing evidence of more recent replies) or by
+last-edited time, or perhaps by last comment (then busy pages cause less busy
+ones quickly go deep into the list and are never seen by the user).
+
+Is there an existing solution to this?
+
+Random ideas, maybe direction for a solution:
+
+- Make client software which takes a local git clone of a wiki and operates on
+  it, while the user sees an MUA-like interface
+- Add some plugin to ikiwiki that can cooperate with an MTA: listen to e-mail
+  on a mailing list with specific formatting and put the content into a wiki.
+
+What do you think? How do you keep track of the forum etc. in the same way it's
+done with mailing lists?
+
+(I don't mind a hacked solution that solves the problem for me, but if it's not just
+me being crazy, I prefer a general-purpose solution that helps everyone)

wishlist
diff --git a/doc/todo/MUA-like_access_to_forum__47__blog.mdwn b/doc/todo/MUA-like_access_to_forum__47__blog.mdwn
new file mode 100644
index 0000000..8d11a55
--- /dev/null
+++ b/doc/todo/MUA-like_access_to_forum__47__blog.mdwn
@@ -0,0 +1,35 @@
+[[!tag wishlist]]
+
+Maybe I'm not using ikiwiki right, and I'll appreciate any advice on this, but
+it seems to me that using ikiwiki instead of a mailing lists has some major
+weaknesses which I fail to overcome, but which may be possible to fix, maybe
+using some client-side software.
+
+The problem: Mailing lists give me things I need but can't find here, so I'm
+failing to track the [[/forum]], [[/todo]] and so on:
+
+- With MLs I can easily see what I read, to what I replied, mark things with
+  colors and labels if my MUA supports it
+- With MLs I can easily send a reply, without going through git. Reading and
+  writing happen together in the same dedicated UI
+
+I know I can subscribe to [[forum]] and to individual posts' comment feeds, but
+it's not the same - I don't see the tree of comments like in e-mail. Either I
+sort by creation time (not seeing evidence of more recent replies) or by
+last-edited time, or perhaps by last comment (then busy pages cause less busy
+ones quickly go deep into the list and are never seen by the user).
+
+Is there an existing solution to this?
+
+Random ideas, maybe direction for a solution:
+
+- Make client software which takes a local git clone of a wiki and operates on
+  it, while the user sees an MUA-like interface
+- Add some plugin to ikiwiki that can cooperate with an MTA: listen to e-mail
+  on a mailing list with specific formatting and put the content into a wiki.
+
+What do you think? How do you keep track of the forum etc. in the same way it's
+done with mailing lists?
+
+(I don't mind a hacked solution that solves the problem for me, but if it's not just
+me being crazy, I prefer a general-purpose solution that helps everyone)

Added a comment
diff --git a/doc/forum/PO_and_RTL_support/comment_13_ebe1c390b478bb87021850ea019a8194._comment b/doc/forum/PO_and_RTL_support/comment_13_ebe1c390b478bb87021850ea019a8194._comment
new file mode 100644
index 0000000..9c167f8
--- /dev/null
+++ b/doc/forum/PO_and_RTL_support/comment_13_ebe1c390b478bb87021850ea019a8194._comment
@@ -0,0 +1,18 @@
+[[!comment format=mdwn
+ username="smcv"
+ ip="81.100.115.242"
+ subject="comment 13"
+ date="2014-10-23T08:06:48Z"
+ content="""
+> I was told here that there is a patch already
+
+That patch is for the po plugin, which is specifically designed for a wiki
+in which every page `foo` is written in a \"master language\" (often English)
+in a file like `/foo.mdwn`, and then translated into secondary languages
+via translation files like `/foo.ar.po`.
+
+If that doesn't describe your wiki, then the po plugin is not intended
+for you, and you would be better off with a change to the meta plugin
+to make it possible to emit the same language and/or direction
+attributes in the HTML, but triggered by different source code.
+"""]]

Added a comment
diff --git a/doc/forum/Right-to-left_support/comment_3_49f82c1d9bfb460c1a468e66c9acf97b._comment b/doc/forum/Right-to-left_support/comment_3_49f82c1d9bfb460c1a468e66c9acf97b._comment
new file mode 100644
index 0000000..f1e6487
--- /dev/null
+++ b/doc/forum/Right-to-left_support/comment_3_49f82c1d9bfb460c1a468e66c9acf97b._comment
@@ -0,0 +1,33 @@
+[[!comment format=mdwn
+ username="smcv"
+ ip="81.100.115.242"
+ subject="comment 3"
+ date="2014-10-23T07:57:39Z"
+ content="""
+> The Arabic pages on your wiki seem to have the Arabic in LTR, instead of the intended RTL
+
+As I said on the other forum thread, it does look to me as though it is RTL;
+the display bug is that it's left-justified (text-align: left) because the
+blueview stylesheet explicitly (and unnecessarily?) left-aligns text.
+
+You can test RTL/LTR in English by putting a distinctive directionless punctuation
+character at the beginning and end of a paragraph like this:
+
+    <p dir=\"ltr\">• This renders with a bullet on the left and an ellipsis on the right…</p>
+    <p dir=\"rtl\">• This renders with a bullet on the right and an ellipsis on the left…</p>
+
+The actual text still goes left-to-right because Latin characters are known
+to be left-to-right by the Unicode bidi algorithm, but the punctuation moves
+around, and in ikiwiki themes other than blueview and goldtype, the alignment
+changes too:
+
+<p dir=\"ltr\">• This renders with a bullet on the left and an ellipsis on the right…</p>
+<p dir=\"rtl\">• This renders with a bullet on the right and an ellipsis on the left…</p>
+
+More test-cases:
+
+* <http://actiontabs.hosted.pseudorandom.co.uk/rtl/>
+* <http://blueview.hosted.pseudorandom.co.uk/rtl/>
+* <http://goldtype.hosted.pseudorandom.co.uk/rtl/>
+* <http://unthemed.hosted.pseudorandom.co.uk/rtl/>
+"""]]

Added a comment
diff --git a/doc/forum/Problems_with_img_directive_on_nearly_free_speech/comment_1_c66ef7bcfd45cab29453cd0a17d71ea1._comment b/doc/forum/Problems_with_img_directive_on_nearly_free_speech/comment_1_c66ef7bcfd45cab29453cd0a17d71ea1._comment
new file mode 100644
index 0000000..82ede67
--- /dev/null
+++ b/doc/forum/Problems_with_img_directive_on_nearly_free_speech/comment_1_c66ef7bcfd45cab29453cd0a17d71ea1._comment
@@ -0,0 +1,13 @@
+[[!comment format=mdwn
+ username="openmedi"
+ ip="91.65.196.164"
+ subject="comment 1"
+ date="2014-10-22T22:01:41Z"
+ content="""
+Okay. I figured it out with help from the nearlyfreespeech forum. It had nothing to do with ikiwiki. Nonetheless here's the solution, for posterity: You can check, if PerlMagick is installed by running ```perl -MImage::Magick -e \"print $Image::Magick::VERSION\"```.  If it isn't, you will get an error that looks like this:
+
+>```Can't locate Image/Magick.pm in @INC (@INC contains: /usr/local/lib/perl5/5.16/BSDPAN /usr/local/lib/perl5/site_perl/5.16/mach /usr/local/lib/perl5/site_perl/5.16 /usr/local/lib/perl5/5.16/mach /usr/local/lib/perl5/5.16 .). 
+BEGIN failed--compilation aborted. ```
+
+If that's the case, you might have to upgrade/switch to a new \"realm\". As of the time of this writing PerlMagick is installed in the realms \"indigo\" and \"white\". How this is done, is described in the members only FAQ of nfs.
+"""]]

Added a comment
diff --git a/doc/forum/PO_and_RTL_support/comment_12_75d3bc373e8d3877ce2cb1f974abaf18._comment b/doc/forum/PO_and_RTL_support/comment_12_75d3bc373e8d3877ce2cb1f974abaf18._comment
new file mode 100644
index 0000000..93328f2
--- /dev/null
+++ b/doc/forum/PO_and_RTL_support/comment_12_75d3bc373e8d3877ce2cb1f974abaf18._comment
@@ -0,0 +1,16 @@
+[[!comment format=mdwn
+ username="fr33domlover"
+ ip="46.117.109.179"
+ subject="comment 12"
+ date="2014-10-22T16:46:01Z"
+ content="""
+As to exposing the language tag, I was told here that there is a patch already:
+
+[[/forum/Right-to-left_support/]]
+
+The CSS should requires that I modify my local.css to use the conditional
+instead of an \"rtl\" class. For that I need to understand on which items it
+affects (and just insert direction=rtl there, like I'm doing now with the class).
+
+When I make the changes in my wiki and test them, I'll send you a patch.
+"""]]

New wishlist item - put /tags page in the basewiki?
diff --git a/doc/todo/tags_in_basewiki.mdwn b/doc/todo/tags_in_basewiki.mdwn
new file mode 100644
index 0000000..7292748
--- /dev/null
+++ b/doc/todo/tags_in_basewiki.mdwn
@@ -0,0 +1,7 @@
+[[!tag wishlist]]
+
+Maybe I'm missing something, but... is there a reason the [[/tags]] page is not
+in the basewiki? Also, maybe it should move to be under [[/ikiwiki]], since
+unlike [[/templates]] and [[/shortcuts]] there's no special reason to edit it.
+
+--[[fr33domlover]]

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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