From 8c8856601f76c16b2be51b16c095a276f9c9a9b5 Mon Sep 17 00:00:00 2001 From: tschwinge Date: Sun, 19 Sep 2010 06:17:01 +0000 Subject: [PATCH] Back to Joey. --- doc/bugs/cutpaste.pm:_missing_filter_call.mdwn | 14 ++++++++++++++ 1 file changed, 14 insertions(+) diff --git a/doc/bugs/cutpaste.pm:_missing_filter_call.mdwn b/doc/bugs/cutpaste.pm:_missing_filter_call.mdwn index 475880f0a..f7138cba0 100644 --- a/doc/bugs/cutpaste.pm:_missing_filter_call.mdwn +++ b/doc/bugs/cutpaste.pm:_missing_filter_call.mdwn @@ -39,3 +39,17 @@ function. > constraints, without removing cutpaste's ability to have forward pastes > of text cut laster in the page. (That does seems like an increasingly > bad idea..) --[[Joey]] + +> > OK -- so the FOO/BAR thing was only a very stripped-down example, of +> > course, and the real thing is being observed with the +> > *[[plugins/contrib/getfield]]* plugin. This one needs to run *before* +> > `preprocess`ing, for its `{{$page#field}}` syntax is (a) meant to be usable +> > inside ikiwiki directives, and (b) the field values are meant to still be +> > `preprocess`ed before being embedded. That's why it's using the `filter` +> > hook instead of `sanitize`. + +> > Would adding another kind of hook be a way to fix this? My idea is that +> > *cut* (and others) would then take their data not during `scan`ning, but +> > *after* `filter`ing. + +> > --[[tschwinge]] -- 2.26.2