Add simple patch to silence a warning when using monotone
[ikiwiki.git] / doc / bugs / recentchanges_feed_links.mdwn
1 (Moved from [[plugins/recentchanges/discussion]])
2
3 I've just upgraded to ikiwiki 2.50 with the `recentchanges` plugin enabled, and
4 figured out that I have to turn on `rss` in `ikiwiki.setup` in order to get the
5 recentchanges feed. Now the feed shows up, but the links in the feed go to the
6 change pages, e.g. `recentchanges/change_1700.html`.  I can see a `recentchanges`
7 directory created in the working copy, containing files like `change_1700._change`
8 but for some reason they are not getting htmlized and carried over. I can see
9 in `recentchanges.pm` that it explicitly registers an `htmlize` hook for the
10 `_change` type, but something isn't happening. I also see `return if $type=~/^_/;` in
11 `render()` in `Render.pm` so I guess the upshot is I'm not sure how this is
12 supposed to work; is there a bug here or just something I overlooked that I need
13 to turn on? --Chapman Flack
14
15 > It's a (minor) bug that recentchanges optimises away generating the
16 > change pages, but that the rss/atom feed still links to them. --[[Joey]]
17
18 >> Hmm, ok, what's the intended correct behavior? To really generate the
19 >> change pages, or to change the links in the feed to point somewhere else that's
20 >> not missing? If you can easily point me to the right neighborhood in the code
21 >> I might work on a patch for this. It may be a (minor) bug in the grand scheme
22 >> of things, but it does seem pretty goofy if you've just clicked an RSS link. :)
23 >> --Chap (p.s. should this be moved to bugs?)
24
25 >>> The latter -- I think making the permalink point to
26 >>> "recentchanges#someid" will probably work. Probably first by addressing the
27 >>> todo about [[todo/ability_to_force_particular_UUIDs_on_blog_posts]],
28 >>> and then by just using that new ability in the page. --[[Joey]]
29
30 >>>> <del title="Prerequisite done now?">Ah. The prerequisite todo looks like more than I'd like to take on.
31 >>>> In the meantime, would it be very involved to change whatever bug now
32 >>>> optimizes away the change pages, or to simply have all the links in the
33 >>>> feed point to the recentchanges page itself, with no fragment id?
34 >>>> Either would be a bit nicer than having broken links in the feed. --Chap</del>
35
36 >>>> Does the completion of that todo mean it would be straightforward to get
37 >>>> recentchanges working now?  Is it just that the recentchanges plugin
38 >>>> needs to generate `\[[!meta guid=something]]` into the internal files,
39 >>>> and the inline plugin would then generate working links in feeds?  How should
40 >>>> the guid be constructed? Something based on the rcs revision number?  I guess
41 >>>> I'm still not completely clear on your vision for how it ought to work. --Chap
42
43 >>>> My idea is to use `\[[meta guid="http://url/recentchanges#rev"]]`, with the
44 >>>> `#rev` anchor also included in the change file, and being the rcs's
45 >>>> internal revision id. Then the guid is globally unique, and actually
46 >>>> links to the change in the recentchanges page. And, when the change
47 >>>> has fallen off the page, the link will still go to the recentchanges page.
48 >>>> 
49 >>>> First, need to check that guids in rss and atom feeds can have anchors in
50 >>>> them, and that the anchor is treated as part of the guid. (If the guid
51 >>>> is interpreted as just "http://url/recentchanges", then it's
52 >>>> not a very good guid.) If using an anchor for a guid is a problem,
53 >>>> it could instead generate a random uuid, and use `\[[meta
54 >>>> guid="urn:uuid:<foo>" permalink="http://url/recentchanges"]]`