Merge branch 'master' of ssh://git.ikiwiki.info/srv/git/ikiwiki.info

doc/plugins/contrib/imailhide.mdwn

@@ -1,7 +1,7 @@
-[[!template id=plugin name=imailhide author="Peter Vizi"]]
+[[!template id=plugin name=imailhide author="Peter_Vizi"]]
 [[!tag type/widget type/html]]
 
-# Mailhide plugin for Ikiwiki
+# Mailhide Plugin for Ikiwiki
 
 This plugin provides the directive mailhide, that uses the [Mailhide
 API][1] to protect email addresses from spammers.
@@ -53,8 +53,13 @@ will result in `joh<a href="...">...</a>@example.com`.
 *Optional.* You can set the style parameter individually for each
  `mailhide` call. See `mailhide_default_style` for details.
 
+## Known Issues
+
+1. [opening new window when displaying email address][6]
+
 [1]: http://www.google.com/recaptcha/mailhide/
 [2]: http://search.cpan.org/perldoc?Captcha::reCAPTCHA::Mailhide
 [3]: http://github.com/petervizi/imailhide
 [4]: http://www.google.com/recaptcha/mailhide/apikey
 [5]: http://code.google.com/apis/recaptcha/docs/mailhideapi.html
+[6]: http://github.com/petervizi/imailhide/issues#issue/1

doc/todo/want_to_avoid_ikiwiki_using_http_or_https_in_urls_to_allow_serving_both.mdwn

@@ -60,7 +60,6 @@ becoming a problem for me. Is there anything I can do here? --[[Perry]]
 ----
 
 [[!template id=gitbranch branch=smcv/https author="[[smcv]]"]]
-[[!tag patch]]
 
 For a while I've been using a configuration where each wiki has a HTTP and
 a HTTPS mirror, and updating one automatically updates the other, but
@@ -140,3 +139,34 @@ you don't like my approach:
 >> Yes, that's a problem with this approach (either way round). Perhaps
 >> making it easier to run two mostly-synched copies like I was previously
 >> doing is the only solution... --s
+
+----
+
+**warning: untested branch ** [[!template id=gitbranch branch=smcv/localurl author="[[smcv]]"]]
+
+OK, here's an alternative approach, closer in spirit to what was initially
+requested. I haven't tested this at all (it's getting rather late in UK time)
+and it will probably be rebased later, but I've referenced it here as a proof of
+concept.
+
+The idea is that in the common case, the CGI and the pages will reside on the
+same server, so they can use "semi-absolute" URLs (`/ikiwiki.cgi`, `/style.css`,
+`/bugs/done`) to refer to each other. My branch adds config options which
+could be set as follows for ikiwiki.info or any branchable.com site:
+
+* local_url: /
+* local_cgiurl: /ikiwiki.cgi
+
+Most redirects, form actions, links etc. can safely use this form rather than
+the fully-absolute URL. If not configured, these options default to the
+corresponding absolute URL, which is would also be correct for unusual sites
+where the CGI and the pages aren't on the same server.
+
+(In theory you could use things like `//static.example.com/wiki/` and
+`//dynamic.example.com/ikiwiki.cgi` to preserve choice of http/https
+while switching server, but I don't know how consistently browsers
+suppot that.)
+
+"local" here is short for "locally valid", because these URLs are neither
+fully relative nor fully absolute, and there doesn't seem to be a good name
+for them...

doc/todo/web_reversion.mdwn

@@ -24,13 +24,16 @@ Implementation plan:
   and refresh site.
 
 Peter Gammie has done an initial implementation of the above.
-[[!template id=gitbranch branch=peteg/master author="[[peteg]]"]]
+[[!template id=gitbranch branch=peteg/revert author="[[peteg]]"]]
+
+>> It is on a separate branch now. --[[peteg]]
 
 > Review: --[[Joey]] 
 > 
 > The revert commit will not currently say what web user did the revert.
 > This could be fixed by doing a --no-commit revert first and then using
 > rcs_commit_staged.
+>> Fixed, I think. --[[peteg]]
 >
 > So I see one thing I completly forgot about is `check_canedit`. Avoiding users
 > using reverting to make changes they would normally not be allowed to do is