git.oblomov.eu Git - ikiwiki/blob - 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"]]`
  55
  56 >>>>> I had a quick look into this after fixing the "prerequisite", but got
  57 >>>>> bogged down in minor details. Anyway, I'd be happy to help.
  58 >>>>> I think the guid stuff is actually fairly irrelevant, you just need
  59 >>>>> `\[[!meta permalink]]` (and in fact you're using guid incorrectly, by
  60 >>>>> expecting it to be treated as a link).
  61 >>>>>
  62 >>>>> My advice would be: first, fix the bug as reported, by
  63 >>>>> using `\[[!meta permalink="http://blah/blah/blah#change-$rev"]]` (starting
  64 >>>>> anchor names with a number isn't syntactically valid, if I remember
  65 >>>>> correctly, so do have a prefix like "change-" or "rev-" or something).
  66 >>>>>
  67 >>>>> Then, optionally, force the guid too (although it defaults to the permalink
  68 >>>>> anyway, so this shouldn't actually be necessary).
  69 >>>>>
  70 >>>>> Some more explanation of how guids work: it's actually easier to think
  71 >>>>> about them in Atom terms than in RSS terms, since Atom has a clearer
  72 >>>>> conceptual model.
  73 >>>>>
  74 >>>>> The `\[[!meta permalink]]` becomes the `<link>`
  75 >>>>> element in Atom, which contains a link that users can follow; if it's not
  76 >>>>> explicitly given, ikiwiki uses its idea of the page's URL.
  77 >>>>>
  78 >>>>> The `\[[!meta guid]]` becomes the `<id>` element in Atom, which contains an
  79 >>>>> opaque, not-necessarily-resolvable identifier; if it's
  80 >>>>> not explicitly given, ikiwiki uses the same URL as the `<link>`.
  81 >>>>>
  82 >>>>> In RSS the semantics aren't so clear-cut (which is part of why Atom exists!),
  83 >>>>> but the way ikiwiki interprets them is:
  84 >>>>>
  85 >>>>> * `<link>` is the same as in Atom
  86 >>>>> * if `\[[!meta guid]]` is explicitly given, put it in `<guid permalink="no">`
  87 >>>>>   (the assumption in this case is that it's a UUID or something)
  88 >>>>> * if `\[[!meta guid]]` is not explicitly given, copy the `<link>` into the `<guid>`
  89 >>>>>
  90 >>>>> I believe RSS aggregators (are meant to) compare `<guid>`s as opaque
  91 >>>>> strings, so using an anchor there should be fine. Atom aggregators are certainly
  92 >>>>> required to compare `<id>`s as opaque strings.
  93 >>>>>
  94 >>>>> --[[smcv]]
  95
  96 >>>>>> Here's my attempt at a [[patch]] for anchor-based change permalinks:
  97 >>>>>> <http://pastie.org/295016>.
  98 >>>>>> --[[JasonBlevins]], 2008-10-17
  99
 100 [[JasonBlevins]] nailed it, [[done]] --[[Joey]]
 101
 102 > Thanks for applying the patch (and improving it).  There's still one small issue:
 103 > the old opening div tag still needs to be removed (it's hard to see the removed line
 104 > with the pastie color scheme).
 105 > --[[JasonBlevins]], 2008-10-18
 106
 107 >> Thanks, missed that when I had to hand-apply the patch. --[[Joey]]