614407c9dc3a759674b181f7ea3fa2c290a72efe
[ikiwiki.git] / doc / todo / aggregate_to_internal_pages.mdwn
1 The new internal page feature is designed for something like
2 [[plugins/aggregate]].
3
4 How to transition to it though? inlines of aggregated content would need to
5 change their pagespecs to use `internal()`.
6
7 > [[patch]] in git://git.debian.org/git/users/smcv/ikiwiki.git, branch "aggregate"; [see also gitweb](http://git.debian.org/?p=users/smcv/ikiwiki.git;a=commit;h=01d7ae803710bb0d84fc8d172fd98fd57fb77e9d). --smcv.pseudorandom.co.uk
8 > 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
9
10 > Thanks for working on this.
11
12 > I see one problem, if internalize is flipped on and there are existing
13 > aggregated pages, htmlfn will not return the right filename for those
14 > pages when expiring them. Seems that `$was_internal` (or just the full
15 > source filename) should be recorded on a per-guid basis. Could you do
16 > that?
17
18 > I'm weighing the added complexity of having an internalize option
19 > (which people would have to add, and would probably forget), with just
20 > making aggregate create all new pages as internal, and having a flag day
21 > where all inlines and other uses of aggregated pages have to change
22 > pagespecs to use `isinternal()`.
23
24 > There are real bugs that are fixed by making
25 > aggregated plugins internal, including:
26 > - Avoids web edits to aggregated pages. (Arguably a security hole;
27 >   though they can be locked..)
28 > - Significant speed improvements.
29 > - Less disk use.
30
31 > If internal has to be manually enabled, people will forget to. I'd rather
32 > not have to worry about these bugs in the future. So, I'm thinking flag
33 > day. --[[Joey]]
34
35 [[patch]]