If someone has explicitly disabled the postform, it seems reasonable
from a least-astonishment point of view for that to take precedence
over rootpage, even though that makes rootpage useless.
Also add a regression test; so far, this is all it tests.
After this change autoindex creates index pages also for empty directories
included in underlays, but only if it isn't going to commit them to the
srcdir ($config{autoindex_commit} = 0).
Inspired by a patch from Tuomas Jormola.
Bug-Debian: http://bugs.debian.org/611068
It's not clear that the transient underlay should be excluded from
indexing; see [[bugs/transient autocreated tagbase is not transient
autoindexed]].
In any case, the code that checks what directories might need indexes
specifically checks for the srcdir anyway, so the only effect this extra
check can have is negative (it could fail to notice files in the
transient underlay and attempt to recreate them unnecessarily).
this allows picking a page from a pdf. also, this enhances performance
greatly when rendering pdfs, as only the first page is rasterized.
(otherwise, imagemagick would treat the pdf as a list of images, work
with all of them, until finally only the first page gets saved). the
default parameter of 0 will select the single image contained in typical
image files anyway, so no specialcasing between single- and multifile
containers is needed.
imagemagick, when reading an image, sets its magick parameter to
indicate the file type, overriding the explicitly set file type for
output if it is set at creation.
as a result, previously (with graphicsmagick-libmagick-dev-compat
1.3.18-1 providing Image::Magick), svg output files were not png,
neither svg, but mvg (imagemagick vector graphics).
This doesn't prevent memory from being used to track what we have
and haven't scanned, but it does make it temporary. The existing
%rendered hash, which is filled afterwards, will be larger than %scanned
in practice anyway: %scanned will contain an entry for each page
that changed, plus an entry for each template used by templatebody,
whereas %rendered will contain an entry for each page that changed
plus an entry for each page rendered due to links or dependencies.
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.
If it does nothing when a page has already been scanned, we can use it
at any time to force a page to be scanned. In particular, the
templatebody plugin is going to need this.
Previously, if a page like `plugins/trail` contained a conditional like
[[!if test="backlink(plugins/goodstuff)" all=no]]
(which it gets via `templates/gitbranch`), then the
[[plugins/conditional]] plugin would give `plugins/trail` a dependency on
`(backlink(plugins/goodstuff)) and plugins/trail`. This dependency is
useless: that pagespec can never match any page other than
`plugins/trail`, but if `plugins/trail` has been modified or deleted,
then it's going to be rendered or deleted *anyway*, so there's no point
in spending time evaluating match_backlink for it.
Conversely, the influences from the result were not taken into account,
so `plugins/trail` did not have the
`{ "plugins/goodstuff" => $DEPEND_LINKS }` dependency that it should.
Invert that, depending on the influences but not on the test.
Bug: http://ikiwiki.info/bugs/editing_gitbranch_template_is_really_slow/
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.)
git's behaviour when doing "git push origin" is configurable, and the
default is going to change in 2.0. In particular, if you've set
push.default to "nothing", the regression test will warn:
fatal: You didn't specify any refspecs to push, and push.default
is "nothing".
'git push origin' failed: at .../lib/IkiWiki/Plugin/git.pm line 220.
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.
While here, mollify http://validator.w3.org/feed/ and
s/dcterms:creator/dc:creator/g, which happens to make rss2email see
and do nice things with authors.
Not sure if this is needed to avoid it trying to run an editor. Probably
there is never a controlling terminal and probably git notices and does
nothing. But I'm just copying what I have in git-annex assistant here.
(Although with a much worse git version comparion, that only really works due
to luck.)
I saw this happen with calendar, when it wanted to update a page, that
had a calendar on it, but the page had just been deleted. This caused
srcfile_stat to crash.
RPC::XML uses ascii as default encoding, we have to tell it to use utf8.
Without this, ikiwiki returns "failed to get response from blogspam server"
every time a non-ascii character is used in a content that needs checking.
I want to write my blog posts in a convenient format (Emacs org mode)
but do not want commenters to be able to use this format for security
reasons. This patch allows to configure which formats are allowed for
writing comments.
Effectively, it restricts the formats enabled with add_plugin to those
mentioned in comments_allowformats. If this is empty, all formats are
allowed, which is the behavior without this patch.
This re-fixes the same bug as 2d5c2f30, but without introducing
malformed HTML in some situations. This is not a very elegant
solution, but it has the advantage of passing more tests.
This makes them easier to debug by showing the structure. Sample output
when $spaces is set to 4 spaces:
<div class='map'>
<ul>
<li>
<a href="../alpha" class="mapparent">alpha</a>
<ul>
<li>
<a href="../alpha/1" class="mapitem">1</a>
</li>
</ul>
</li>
<li>
<a href="../beta" class="mapitem">beta</a>
</li>
</ul>
</div>
Simple podcast feeds didn't have content tags and I made sure to
keep it that way. This may be unnecessarily conservative. Changing
the behavior to include empty content tags might be fine, but I
don't want to think about it right now, I just want my tests to
keep passing!
The new fancy-podcast tests are copy-pasted-edited from the
simple-podcast tests. These tests shall be refactored.
In test, set up the post-commit hook for more realism (and bugs!).
To make wrappers work in test, set PERL5LIB, and allow the wrappee's
path to be overridden. Meta-test that post-commit is really hooked
up by verifying that content is getting generated in destdir.
About the longstanding bug, which as far as I know was harmless:
CVS can't operate outside a srcdir, so we're always setting $CWD.
"local $CWD" restores the previous value when we go out of scope.
Usually that's correct. But if we're removing the last file from a
directory, the post-commit hook will exec in a working directory
that's about to not exist (CVS will prune it).
The fix: chdir() manually in cvs_runcvs(), so we can selectively
not chdir() back.
This seemed to be due to the pagetemplate hook calling prerender. I've
observed this making it take *minutes* for the signin page to be displayed.
ltracing ikiwiki showed it was matching pagespecs a lot.
It may be that this is still a speed pain point when rendering pages, not
just for CGI. So more work may be needed here.
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.
Technically, when the user does this, a passwordless account is created
for them. The notify mails include a login url, and once logged in that
way, the user can enter a password to get a regular account (although
one with an annoying username).
This all requires the passwordauth plugin is enabled. A future enhancement
could be to split the passwordless user concept out into a separate plugin.
The plan is to use this for accounts that are created implicitly, as when
a non-logged-in user subscribes to notifyemail. Such an account has no
password, and login can be accomplished by way of a url that is sent to
them in email.
When the user sets a password, the passwordless login token is disabled.
Louis
Simon McVittie
chrysn
Joey Hess
Tuomas Jormola
intrigeri
Mesar Hameed
Amitai Schlair
Changaco
Michal Sojka
Shlomi Fish
Antoine Beaupré
Geneviève Bastien
Philippe Gauthier