summaryrefslogtreecommitdiff
path: root/doc/todo/aggregate_to_internal_pages.mdwn
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]]