response

1 files changed, 26 insertions, 0 deletions

diff --git a/doc/todo/aggregate_to_internal_pages.mdwn b/doc/todo/aggregate_to_internal_pages.mdwn
index b7b77fc03..8b848093b 100644
--- a/doc/todo/aggregate_to_internal_pages.mdwn
+++ b/doc/todo/aggregate_to_internal_pages.mdwn
@@ -5,3 +5,29 @@ 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](http://git.debian.org/?p=users/smcv/ikiwiki.git;a=commit;h=01d7ae803710bb0d84fc8d172fd98fd57fb77e9d). --smcv.pseudorandom.co.uk
+
+> Thanks for working on this, it doesn't solve the transition problems, but
+> at least the feature is implemented.
+> 
+> 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]]