The input to filter hooks is meant to be the content of a source file
on disk. If we only filter once per (page, destpage) pair, and a page
is inlined into the same destpage more than once, then the second
occurrence will render as the result of htmlizing .po source as if
it was Markdown (or whatever the type of the corresponding master page
is), which is never going to end well.
The alreadyfiltered mechanism was added in commit 1e874b3f to avoid
preprocessing loops, but I'm not sure where it could lead to a loop:
filter hooks are only called from IkiWiki::filter, which is only called
on page content from disk or on proposed content being previewed.
According to <https://bugs.debian.org/911356#41>, deleting the
alreadyfiltered mechanism resolves the problem, as well as simplifying
the code.
Closes: #911356
Tested-by: intrigeri
As index.{es,fr} don't exist, po::refreshpofiles copies them from the basewiki
underlay before running msgmerge. msgmerge marks as obsolete the translation
strings that came from the basewiki po files, but the link plugin
does not make the difference between obsolete and up-to-date links.
$links{'index.fr'} and $links{'index.es'} are therefore expected to contain
SandBox and ikiwiki.
I want to have an easy way to know if I break something when I'll convert custom
added hooks to the new "inject" feature. It will also be useful after this
conversion, to trigger an alert when IkiWiki's internals change enough to break
my wrapper functions.
Signed-off-by: intrigeri <intrigeri@boum.org>
Simon McVittie
Joey Hess
intrigeri