diff options
| -rw-r--r-- | doc/bugs/recentchanges_feed_links.mdwn | 28 | ||||
| -rw-r--r-- | doc/plugins/recentchanges/discussion.mdwn | 22 |
2 files changed, 28 insertions, 22 deletions
diff --git a/doc/bugs/recentchanges_feed_links.mdwn b/doc/bugs/recentchanges_feed_links.mdwn new file mode 100644 index 000000000..32073415f --- /dev/null +++ b/doc/bugs/recentchanges_feed_links.mdwn @@ -0,0 +1,28 @@ +(Moved from [[plugins/recentchanges/discussion]]) + +I've just upgraded to ikiwiki 2.50 with the `recentchanges` plugin enabled, and +figured out that I have to turn on `rss` in `ikiwiki.setup` in order to get the +recentchanges feed. Now the feed shows up, but the links in the feed go to the +change pages, e.g. `recentchanges/change_1700.html`. I can see a `recentchanges` +directory created in the working copy, containing files like `change_1700._change` +but for some reason they are not getting htmlized and carried over. I can see +in `recentchanges.pm` that it explicitly registers an `htmlize` hook for the +`_change` type, but something isn't happening. I also see `return if $type=~/^_/;` in +`render()` in `Render.pm` so I guess the upshot is I'm not sure how this is +supposed to work; is there a bug here or just something I overlooked that I need +to turn on? --Chapman Flack + +> It's a (minor) bug that recentchanges optimises away generating the +> change pages, but that the rss/atom feed still links to them. --[[Joey]] + +>> Hmm, ok, what's the intended correct behavior? To really generate the +>> change pages, or to change the links in the feed to point somewhere else that's +>> not missing? If you can easily point me to the right neighborhood in the code +>> I might work on a patch for this. It may be a (minor) bug in the grand scheme +>> of things, but it does seem pretty goofy if you've just clicked an RSS link. :) +>> --Chap (p.s. should this be moved to bugs?) + +>>> The latter -- I think making the permalink point to +>>> "recentchanges#someid" will probably work. Probably first by addressing the +>>> todo about [[todo/ability_to_force_particular_UUIDs_on_blog_posts]], +>>> and then by just using that new ability in the page. --[[Joey]] diff --git a/doc/plugins/recentchanges/discussion.mdwn b/doc/plugins/recentchanges/discussion.mdwn index dae4b5919..a16cb5217 100644 --- a/doc/plugins/recentchanges/discussion.mdwn +++ b/doc/plugins/recentchanges/discussion.mdwn @@ -15,25 +15,3 @@ this should be a rather uncommon thing. > And fixed this, by making it look at all *._change pages, not just > those in a specific directory, when deciding which to expire. --[[Joey]] - -I've just upgraded to ikiwiki 2.50 with the `recentchanges` plugin enabled, and -figured out that I have to turn on `rss` in `ikiwiki.setup` in order to get the -recentchanges feed. Now the feed shows up, but the links in the feed go to the -change pages, e.g. `recentchanges/change_1700.html`. I can see a `recentchanges` -directory created in the working copy, containing files like `change_1700._change` -but for some reason they are not getting htmlized and carried over. I can see -in `recentchanges.pm` that it explicitly registers an `htmlize` hook for the -`_change` type, but something isn't happening. I also see `return if $type=~/^_/;` in -`render()` in `Render.pm` so I guess the upshot is I'm not sure how this is -supposed to work; is there a bug here or just something I overlooked that I need -to turn on? --Chapman Flack - -> It's a (minor) bug that recentchanges optimises away generating the -> change pages, but that the rss/atom feed still links to them. --[[Joey]] - ->> Hmm, ok, what's the intended correct behavior? To really generate the ->> change pages, or to change the links in the feed to point somewhere else that's ->> not missing? If you can easily point me to the right neighborhood in the code ->> I might work on a patch for this. It may be a (minor) bug in the grand scheme ->> of things, but it does seem pretty goofy if you've just clicked an RSS link. :) ->> --Chap (p.s. should this be moved to bugs?) |