Merge remote branch 'upstream/master' into prv/po

doc/bugs/po:_plugin_should_not_override_the_title_on_the_homepage.mdwn

@@ -0,0 +1,19 @@
+The po plugin systematically overrides the title of the homepage with the wikiname. This prevents explicitly changing it with a meta directive. It should rather check whether it was overridden before setting it back.
+
+Here is a simple patch for that:
+
+    diff --git a/Plugin/po.pm b/Plugin/po.pm
+    index 6395ebd..a048c6a 100644
+    --- a/Plugin/po.pm
+    +++ b/Plugin/po.pm
+    @@ -333,7 +333,7 @@ sub pagetemplate (@) {
+                && $masterpage eq "index") {
+                    $template->param('parentlinks' => []);
+            }
+    -       if (ishomepage($page) && $template->query(name => "title")) {
+    +       if (ishomepage($page) && $template->query(name => "title") && !$template->query(name => "title_overridden")) {
+                    $template->param(title => $config{wikiname});
+            }
+     }
+
+Thanks.

doc/bugs/urlto_API_change_breaks_wikis_with_po_plugin.mdwn

@@ -0,0 +1,27 @@
+The po plugin needs to be updated to match the urlto sub API and
+signature changes. Else a wiki with the po plugin enabled cannot be
+refreshed / rebuilt because of (correct) Perl errors.
+
+My po branch contains a fix.
+--[[intrigeri]]
+
+> The commit looks sane to me, for what it's worth. Joey, please
+> consider merging? --[[smcv]]
+
+Also, I fear the lack of any useful `$from` parameter might break some
+l10n'd link niceness when using `po_link_to = current` but I have not
+investigated this yet.
+--[[intrigeri]]
+
+> If `urlto` is called without a second parameter, it means we need
+> a URL valid from either the CGI URL or any page in the wiki,
+> (so we'd previously have set the third parameter true), but we
+> don't *necessarily* need an absolute URL - so return what you'd
+> have returned if asked for an absolute URL, but looking like
+> `/bugs/` rather than `http://ikiwiki.info/bugs/` if possible.
+>
+> It looks as though `beautify_urlpath` under `po_link_to = current`,
+> and 3-argument `urlto`, aren't tested by `t/po.t` - perhaps you
+> could add some test cases there? To test 3-argument `urlto` you'd
+> need to add `$config{baseurl} = "http://example.com"` or
+> something. --[[smcv]]

doc/ikiwikiusers.mdwn

@@ -61,6 +61,7 @@ Projects & Organizations
 * [Apua IT](http://apua.se/)
 * [PDFpirate Community](http://community.pdfpirate.org/)
 * [Banu](https://banu.com/) uses Ikiwiki for its website, to convert static Markdown pages into PHP scripts which are served along with non-Ikiwiki PHP generated contents. The static contents benefit from use of Ikiwiki's plugins. Ikiwiki is purely used as a CMS and no wiki or web-based editing is allowed. Ikiwiki is run offline, and the resulting scripts are uploaded using rsync to the website.
+* [Software in the Public Interest](http://spi-inc.org/)
 
 Personal sites and blogs
 ========================

doc/sandbox.mdwn

@@ -1,5 +1,7 @@
 Hello, world!
 
+test...id
+
 This is the [[SandBox]], a page anyone can edit to try out ikiwiki
 (version [[!version  ]]).
 

doc/todo/mirrorlist_with_per-mirror_usedirs_settings.mdwn

@@ -72,3 +72,14 @@ and decided this time it was really needed to implement this feature.
 >>>> Have to wonder if it wouldn't perhaps be better to do something
 >>>> using the goto plugin and cgiurl, so that the mirror doesn't have
 >>>> to know about the configuration of the other mirror. --[[Joey]]
+
+>>>>> I have implemented something using the cgi + goto in my (history
+>>>>> rewrite warning) mirrorlist branch. Please review, please pull.
+>>>>> --[[intrigeri]]
+
+>>>>> concerning goto/cgiurl, what about having that as the default in
+>>>>> mirrorlist, but keeping ``nousedirs|file:///home/intrigeri/wiki`` and
+>>>>> ``usedirs|http://example.com/wiki`` valid for cgi-less cases?
+>>>>> that would keep typical installation with a clutter-less configuration,
+>>>>> and support more individual setups too.
+>>>>> --[[chrysn]]

doc/todo/transient_pages.mdwn

@@ -56,6 +56,9 @@ of directories that become empty aren't deleted.
 Recent changes and aggregated files could conceivably go in the transient
 underlay too.
 
+> I can confirm that the behavior of autoindex, at least, is excellent.
+> Haven't tried tag. Joey, can you merge transient and autoindex? --JoeRayhawk
+
 --------------------------
 
 ## An earlier version