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." http://atompub.org/2005/07/11/draft-ietf-atompub-format-10.html#rfc.section.4.2.6 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.: http://en.wikipedia.org/w/index.php?title=London_International_Airport&diff=28149850&oldid=26980942 Instead of: http://en.wikipedia.org/wiki/London_International_Airport
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: http://en.wikipedia.org/w/index.php?title=Chinese_American_history&diff=453233702&oldid=prev So this bug has been fixed, even if it wasn't by my hand. :-)
