pagespec_match_list() makes the current page depend on the pagespec
being matched, so if you use [[!trailoptions sort="..."]] to force
a sort order, the trail ends up depending on internal(*) and is
rebuilt whenever anything changes. Add a new sort_pages() and use that
instead.
In the scan phase, it's too early to match pagespecs or sort pages;
in the render phase, both of those are OK.
It would be possible to add phases later, renumbering them if necessary
to maintain numerical order.
Whenever I look at dependency calculation, it takes me a while to get my
head round the concept of influences. If what I've written here is
accurate, maybe the next person to look at this (or my future self)
will need less of a run-up.
Package: ikiwiki
Version: 3.20140125
Severity: wishlist
By default, LWP::UserAgent used by IkiWiki to perform outbound HTTP
requests sends the string "libwww-perl/<version number>" as User-Agent
header in HTTP requests. Some blogging platforms have blacklisted the
user agent and won't serve any content for clients using this user agent
string. With IkiWiki configuration option "useragent" it's now possible
to define a custom string that is used for the value of the User-Agent
header.
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.
Simon McVittie
Joey Hess
Tuomas Jormola
Antoine Beaupré
Amitai Schlair
Giuseppe Bilotta
Timo Paulssen
intrigeri