Check Encode version, not Perl version
Merge branch 'master' into sipb Conflicts: po/Makefile templates/page.tmpl
Merge branch 'ready/html5'
Call CGI->param_fetch instead of CGI->param in array context CGI->param has the misfeature that it is context-sensitive, and in particular can expand to more than one scalar in function calls. This led to a security vulnerability in Bugzilla, and recent versions of CGI.pm will warn when it is used in this way. In the situations where we do want to cope with more than one parameter of the same name, CGI->param_fetch (which always returns an array-reference) makes the intention clearer. [commit message added by smcv]
Now that we're always using HTML5, <base href> can be relative
In html5 mode, generate a host- or protocol-relative <base> for the CGI This increases the number of situations in which we do the right thing.
Add reverse_proxy option which hard-codes cgiurl in CGI output This solves several people's issues with the CGI trying to be too clever when IkiWiki is placed behind a reverse-proxy.
Force use of $config{url} as top URL in w3mmode
do not double-decode unicode in CGI forms this works around a behavior change introduced in Encode.pm 2.53 shipped with the Perl 5.20 release described here: http://ikiwiki.info/bugs/garbled_non-ascii_characters_in_body_in_web_interface/
protect $@ whenever a block using $@ is non-trivial As noted in the Try::Tiny man page, eval/$@ can be quite awkward in corner cases, because $@ has the same properties and problems as C's errno. While writing a regression test for definetemplate in which it couldn't find an appropriate template, I received <span class="error">Error: failed to process template <span class="createlink">deftmpl</span> </span> instead of the intended <span class="error">Error: failed to process template <span class="createlink">deftmpl</span> template deftmpl not found</span> which turned out to be because the "catch"-analogous block called gettext before it used $@, and gettext can call define_gettext, which uses eval. This commit alters all current "catch"-like blocks that use $@, except those that just do trivial things with $@ (string interpolation, string concatenation) and call a function (die, error, print, etc.)
Merge commit '1a8cbf526cdc7e77bfa084e266b8633858b68a09' into sipb Conflicts: templates/page.tmpl
Merge commit 'd4a0732752e79b57509cee33001ab757132366c5' into sipb Conflicts: IkiWiki/Wrapper.pm
Merge commit '4dbb8120f760d9009f0c2639f2ccb9808150aed5' into sipb Conflicts: IkiWiki/Wrapper.pm
Merge commit 'ecdfd1b8644bc926db008054ab6192e18351afed' into sipb Conflicts: IkiWiki/Plugin/git.pm
Merge commit 'ffcd2da8274b44663207bb866007ee3bc8d8a15f' into sipb Conflicts: templates/page.tmpl
Merge commit 'c3e9215e1fcb604c3ee01119fdf7cf13724c3812' into sipb Conflicts: IkiWiki/CGI.pm
save whole form state, not just QUERY_STRING, for postsignin Normally, needsignin is called when there is a QUERY_STRING, not when a form is posted. However, it's certianly possible, and should be supported, to make a form that invokes an ikiwiki action that checks needsignin. I encountered this when posting ?do=rename&page=foo. The form is displayed without checking needsignin, for complicated reasons. Posting the form is when the true authentication happens.
record email of new users in userinfo for userlist
let's assume some web server will think OFF is a good idea..
Support the Hiawatha web server which sets HTTPS=off rather than not setting it. (There does not seem to be a standard here.)