1 For some time now, in circumstances that I've had enormous troubles
2 trying to track, I've seen feeds getting removed by ikiwiki when
3 apparently unrelated pages got changed, with the message:
5 > removing somepath/somepage/somefeed, no longer built by some/unrelated/page
7 I've finally been able to find how and why it happens. The situation is
10 * page A has an inline directive that (directly) generates a feed F
11 * page B inlines A, thus (indirectly) generating F again
12 * page B is rendered after page A
14 The feed removal happens when changes are made to prevent B from
15 inliningĀ A; for example, because B is a tag page and A is untagged B, or
16 because B includes A through a pagespec that no longer matches A. In
17 this case, this happens:
19 * page A is built, rendering F
20 * page B is built, _not_ rendering F, which it used to render
21 * F is removed because it is not built by B anymore
23 Note that although this issue is triggered (for me) from the changes I
24 proposed last year to allow feed generation from nested inlines
25 coalescing it to be page-based instead of destpage-based
26 (bb8f76a4a04686def8cc6f21bcca80cb2cc3b2c9 and
27 72c8f01b36c841b0e83a2ad7ad1365b9116075c5) there is potential for it
28 popping up in other cases.
30 Specifically, the logic for the removal of dependent pages currently
31 relies on the assumption that each output has a single generator. My
32 changes caused this assumption to be violated, hence the error, but
33 other cases may pop up for other plugins in the future.
35 I have a [patch] fixing this issue (for feeds specifically, i.e. only
36 the problem I am actually having) on top of my `mystuff` branch, but
37 since that also has heaps of other unrelated stuff, you may want to just
38 [pick it from my gitweb][gw].
40 [gw]: (http://git.oblomov.eu/ikiwiki/patch/671cb26cf50643827f258270d9ac8ad0b1388a65)
42 The patch changes the `will_render()` for feeds to be based on the page
43 rather than on the destpage, matching the fact that for nested inlines
44 it's the inner page that is ultimately responsible for generating the
47 I've noticed that it requires at least _two_ full rebuilds before the
48 index is again in a sensible state. (On the first rebuild, all feeds
49 from nested inlines are actually _removed_.)
51 While the patch is needed because there are legitimate cases in which
52 nested feeds are needed (for example, I have an index page that inlines
53 index pages for subsection of my site, and I want _those_ feed from
54 being visible), there are other cases when one may want to skip feed
55 generation from nested inlines.