Last modified: 2011-09-30 16:37:08 UTC
The Recent Changes atom feed sets each entry's "id" element to the URL of the
page being changed, which means that multiple changes to the same page show up
in the feed as multiple entries with the same ID. According to the Atom 1.0
draft spec, however, "the 'atom:id' element conveys a permanent, universally
unique identifier for an entry or feed" and "the content of an atom:id element
MUST be created in a way that assures uniqueness."
So the current feed violates the spec, but more importantly, because feed
readers that follow the spec assume ID uniqueness, when they encounter two
entries with the same ID they may ignore one or merge it with the other,
corrupting or omitting the information the feed reader provides to its users.
I think the problem is partly due to a misconception about what this feed
syndicates. It's the "Recent Changes" feed, and each entry in it represents a
change, not a page, so the ID element should uniquely identify the change
itself, not the page to which that change applies.
For that matter, the link element should also probably point to the change
itself (even if the diff is included in the content), since by far the most
common use of the "link" element in feeds is as a reference to the permanent
representation of the entry. But this issue is bug 522.
Fortunately, unique URLs already exist for changes, so fixing this bug should be
as simple as using them as the values of the ID elements, f.e.:
The feed does not violate the spec and does pass the feed validator.
Check the spec again: entries may have the same ID (as long as they belong to
the same entry; they are just different versions of it which have ended up in
the same feed).
The feed is meant to show changes to recent pages, and *pages* are the
emphasis. Links are to pages, not to diffs.
It's true that the spec allows multiple entries to have the same ID if they
represent the same entry, so if the Recent Changes feed is really syndicating
pages, not changes, then it's doing the right thing. But this behavior is
inconsistent with the title of the feed, and it's not what I and other users on
our MediaWiki installation wiki.mozilla.org (plus the guy who filed bug 522)
expect when we subscribe to a feed presenting one entry for each change.
Perhaps the feed could be made to support two modes of behavior: the current
mode, in which the feed syndicates pages that have recently changed; and a
second mode, in which it syndicates recent changes to pages. The second mode
would certainly satisfy the expectations of my users, who are used to this
behavior when browsing changes to multiple files via other interfaces.
Reopening as an enhancement request for this additional behavior.
Created attachment 1130 [details]
patch v1: implements global option for specifying preferred mode
This patch adds a wgFeedChangesMode setting to DefaultSettings.php which allows
site admins to specify their preferred mode (page-centric or change-centric).
The default is "page", which results in the current behavior. If set to
"change", the Recent Changes feeds will use a link to the specific change as
the value of the link and id tags in the Atom and RSS feeds.
Changed component to "RecentChanges"
Myk Melez: could you take a look at MediaWiki's current behavior in Subversion trunk, and see whether (a) the current functionality suits you, and (b) how much your current patch applies? Thanks for writing the patch! It's appreciated.
A blast from the past! I haven't been hacking on wikis and feed readers for a few years now, and I don't have a setup to check MediaWiki's current behavior in Subversion, but I did take a look at its behavior on wikipedia.org, which presumably isn't too far behind, and it now appears to implement my suggestion from comment 0 of this bug. For example, the ID of the first entry for the feed when I loaded it a few minutes ago is:
So this bug has been fixed, even if it wasn't by my hand. :-)