blob: 614407c9dc3a759674b181f7ea3fa2c290a72efe (
plain)
The new internal page feature is designed for something like
[[plugins/aggregate]].
How to transition to it though? inlines of aggregated content would need to
change their pagespecs to use internal() .
[[patch]] in git://git.debian.org/git/users/smcv/ikiwiki.git, branch "aggregate"; see also gitweb. --smcv.pseudorandom.co.uk
Migration is a two-step process: first change all your pagespecs to use internal() , then add internalize="yes" to all your aggregate invocations. --smcv.pseudorandom.co.uk
Thanks for working on this.
I see one problem, if internalize is flipped on and there are existing
aggregated pages, htmlfn will not return the right filename for those
pages when expiring them. Seems that $was_internal (or just the full
source filename) should be recorded on a per-guid basis. Could you do
that?
I'm weighing the added complexity of having an internalize option
(which people would have to add, and would probably forget), with just
making aggregate create all new pages as internal, and having a flag day
where all inlines and other uses of aggregated pages have to change
pagespecs to use isinternal() .
There are real bugs that are fixed by making
aggregated plugins internal, including:
- Avoids web edits to aggregated pages. (Arguably a security hole;
though they can be locked..)
- Significant speed improvements.
- Less disk use.
If internal has to be manually enabled, people will forget to. I'd rather
not have to worry about these bugs in the future. So, I'm thinking flag
day. --[[Joey]]
[[patch]]
|