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/
Foo->Bar->can("method") works just as well, even if Foo::Bar is not
loaded. Using UNIVERSAL::can is deprecated.
But, I was unable to easily eliminate conditional.pm's use of UNIVERSAL::can
This better defines what the filter hook is passed, to only be the raw,
complete text of a page. Not some snippet, or data read in from an
unrelated template.
Several plugins that filtered text that originates from an (already
filtered) page were modified not to do that. Note that this was not
done very consistently before; other plugins that receive text from a
page called preprocess on it w/o first calling filter.
The template plugin gets text from elsewhere, and was also changed not to
filter it. That leads to one known regression -- the embed plugin cannot
be used to embed stuff in templates now. But that plugin is deprecated
anyway.
Later we may want to increase the coverage of what is filtered. Perhaps
a good goal would be to allow writing a filter plugin that filters
out unwanted words, from any input. We're not there yet; not only
does the template plugin load unfiltered text from its templates now,
but so can the table plugin, and other plugins that use templates (like
inline!). I think we can cross that bridge when we come to it. If I wanted
such a censoring plugin, I'd probably make it use a sanitize hook instead,
for the better coverage.
For now I am concentrating on the needs of the two non-deprecated users
of filter. This should fix bugs/po_vs_templates, and it probably fixes
an obscure bug around txt's use of filter for robots.txt.
I noticed that ikiwiki/formatting was beilg rebuilt when any page changed.
This turned out to be because it contained a complex conditional
"enabled(foo) or enabled(bar)", and the conditional plugin did not notice
that this consisted only of enabled() tests, and copied it unchanged into
add_depends. Thus, the page's dependencies were satisfied by any page
change.
The fix is to beef up the parser so that it can handle that and more
complex conditionals, and detect if they consist only of such tests.
(Get a good message when a PageSpec fails due to a negated success by
creating success objects with a reason string, which morph into failure
objects when negated.)
scalar context, evaluates to a reason why the match failed.
* Add testpagespec plugin, which might be useful to see why a pagespec isn't
matching something.
for extended pagespecs. The old calling convention will still work for
back-compat for now.
* The calling convention for functions in the IkiWiki::PageSpec namespace
has changed so they are passed named parameters.
* Plugin interface version increased to 2.00 since I don't anticipate any
more interface changes before 2.0.
that given link points based on the page doing the linking. Note that this
could make such PageSpecs match different things than before, if you
relied on the old behavior of them only matching the raw link text.
* This required changing the match_* interface, adding a third parameter.
* Allow link() PageSpecs to match relative, as is allowed with globs.a
* Add postform option to inline plugin.
* Add an bug tracker to the softwaresite example.
* Add a "conditional" plugin, which allows displaying text if a condition
is true. It is enabled by default so conditional can be used in the
basewiki.
* Use conditionals in the template for plugins, so that plugin pages
say if they're currently enabled or not, and in various other places
in the wiki.
Simon McVittie
Joey Hess
Joey Hess
Joey Hess
joey