Since trail members are explicitly rebuilt if the information used for
their prev/up/next boxes changes, they don't need another dependency
on the trail itself. (If the trail disappears, it will disappear from
the member's member_to_trails entry, causing a rebuild; so the add_depends
is redundant.)
Similarly, since trail members are explicitly rebuilt if their next
or previous item, or its title, changes, the presence dependencies on the
next and previous items are redundant.
If the title of a trail changes, each member of that trail must be
rebuilt, for its prev/up/next box to reflect the new title.
If the title of a member changes, its next and previous items (if any)
must be rebuilt, for their prev/up/next boxes to reflect the new title.
In the unlikely event that the ordered contents of a trail have changed
without the TRAILS or TRAILLOOP template variables being evaluated
(for instance, all trail directives are removed from a former trail
that uses a custom pagetemplate that doesn't contain TRAILS), we might
get here without having already called prerender.
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.
this simplifies the code, make the configuration more intuitive, at
the cost of making the labels on the layers automatically generated
and therefore less customizable
When set to true, let each mirror's ikiwiki CGI find out the correct target page
url themselves.
This resolves the usecase described on
[[todo/mirrorlist_with_per-mirror_usedirs_settings]].
Signed-off-by: intrigeri <intrigeri@boum.org>
At some point I changed the storage of trail members' membership
and forgot to update this use.
(It turns out to be rather difficult to reach this code, possibly even
impossible: it only applies if a member somehow ceases to match the
trail's pagespec without either the trail or the member changing.)
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.
Previously, prune("wiki/srcdir/sandbox/test.mdwn") could delete srcdir
or even wiki, if they happened to be empty. This is rarely what you
want: there's usually some base directory (destdir, srcdir, transientdir
or another subdirectory of wikistatedir) beyond which you do not want to
delete.
Joey Hess
Simon McVittie
Shlomi Fish
Antoine Beaupré
Geneviève Bastien
Philippe Gauthier
intrigeri