Open anarcat opened 5 months ago
Well this is just a bad situation all around, not sure what we can do. Feedburner needs to keep working in any case.
let's break it down.
wallabag does this:
<link>
: good<link rel="alternate" type="text/html">
: not great<link rel="via">
: goodfeedburner does this:
<link rel="self">
: broken?<link rel="alternate" >
: goodit also has rel=replies
and rel=edit
which i'll ignore here.
Could we prioritize the plain <link>
without any rel
tag, then fallback to alternate
then self
? that would make both feeds work.
I think this is fundamentally an interoperability problem between RSS (which doesn't specify a rel
attribute, which Wallabag seems to do here) and Atom (which does). According to RFC4287 section-4.2.7.2, Atom feeds without rel
attributes are considered to have rel=alternate
so it seems to me the above algorithm would be standards-compliant for both feed formats.
Feed URL Please specify the feed URL: private URL, but an example would be:
This is a feed generated by Wallabag.
Add-on version Add-on version: 3.8
Describe the bug
With the above feed, livemarks now links to (e.g.)
https://lib3.net/wallabag/view/38722
instead of the canonicalhttps://gitlab.torproject.org/groups/tpo/tpa/-/boards?scope=all&utf8=%E2%9C%93&state=opened
. This means an extra click to actually get to the article.This is, from my perspective, a regression that was introduced in response to #34, in 345156efc889393f7c08f76afffe0039e710c085, which deliberately prioritised the alternate links to "fix" feedburner feeds, but from my perspective, this is actually inaccurate: the "alternate" is a fallback, well, an alternative in any case... Certainly not the best link for wallabag!
To Reproduce Steps to reproduce the behavior:
Expected behavior
Before the above change, the bookmarks were pointing to the right place, which is the article itself, not the wallabag link.
Thanks!