I have benchmarked the pagename() call this avoids taking up to 2 seconds
for a loadindex in a large wiki. The total loadindex for that wiki was
6.46s, so this is a significant improvment.
Even on a smaller site, this reduces the refresh time from 1.69 to 1.52
seconds.
The only breakage risk here is that pagename() can change the page name
it calculates due to setup changes. But in the case of a setup change, the
whole site is rebuilt. So the cached page name is not used in that
case.
I *think* this is ok, at least it results in close to the same index being
saved as before. The difference is that plugins that have a pagestate of {}
have that recorded this way, while with the tight loop, the key for the
plugin in not copied in that case. I cannot see how this could matter.
Try to avoid a situation in which so many ikiwiki cgi wrapper programs are
running, all waiting on some long-running thing like a site rebuild, that
it prevents the web server from doing anything else. The current approach
only avoids this problem for GET requests; if multiple cgi's run GETs on a
site at the same time, one will display a "please wait" page for a
configurable number of seconds, which then redirects to retry. To enable
this protection, set cgi_overload_delay to the number of seconds to wait.
This is not enabled by default.
strftime is a C function, it does not return decoded utf8.
Several places in ikiwiki manually decoded it, but at least two
forgot to.
Also, strftime might not return even encoded utf8, if LC_TIME is set
to a non-utf8 value. Went ahead and supported decoding whatever encoding
it uses.
The remaining direct calls to strftime() are all ones that first set
LC_TIME=C, in order to get times that are not for human display.
Since commit c4d4cad3be, the single dot in
a pagespec can be used to mean the current page. While this worked
correctly in link() it didn't work in backlink(). Fix this by explicitly
checking the testpage in backlink against . and replacing it with the
current location if necessary.
This has been a while coming. It turns out that non-excutable setup files
have a number of benefits. Also, I find YAML setup files easier to edit
myself, and I suspect many users will prefer not needing to deal with
perl syntax.
This brings back the old behavior before urlto changes for this case.
It will generate a path like "/foo", which is not right, but is
the same as is generated by urlto($page, "", 1) -- which is what
the code that now uses 1-parameter urlto used to use.
To get an absolute version you can use cgiurl(cgiurl => $config{cgiurl}).
The only place in IkiWiki that seems to actually need an absolute URL
is the openid plugin, and that already uses the named parameter.
"local" here is short for "locally valid" - the idea is that we can use
URLs that are relative in the sense of only having the path part, but
absolute in the sense that they start from '/', such as
'/~smcv/ikiwiki.cgi'. There's no particularly good name that I can find
for these between-relative-and-absolute URLs.
They're useful because in the common case where the pages and the CGI
script have the same scheme and authority component, each page is
identified by the same locally-valid URL when linking from any page or
from the CGI, without hard-coding a choice between HTTP and HTTPS, or
between multiple virtual hostnames with the same path layout. As such,
we can use them in many situations that previously used an absolute URL.
If there's no suitable semi-absolute value for local_url (for instance,
if your pages and your CGI reside on different servers), we can just fall
back to using the absolute URL. I append '/' because $config{url} doesn't
end with '/', but the common case for local_url (on all branchable.com
sites, for instance) is that it's just '/'.
Joey Hess
Amitai Schlair
Giuseppe Bilotta
Simon McVittie
Timo Paulssen
intrigeri
Craig Lennox
Kathryn Andersen