Last modified: 2011-09-30 16:37:08 UTC

Wikimedia Bugzilla is closed!

Wikimedia has migrated from Bugzilla to Phabricator. Bug reports should be created and updated in Wikimedia Phabricator instead. Please create an account in Phabricator and add your Bugzilla email address to it.
Wikimedia Bugzilla is read-only. If you try to edit or create any bug report in Bugzilla you will be shown an intentional error message.
In order to access the Phabricator task corresponding to a Bugzilla report, just remove "static-" from its URL.
You could still run searches in Bugzilla or access your list of votes but bug reports will obviously not be up-to-date in Bugzilla.
Bug 3998 - support change-centric in addition to page-centric behavior mode for Recent Changes Atom feed
support change-centric in addition to page-centric behavior mode for Recent C...
Status: RESOLVED FIXED
Product: MediaWiki
Classification: Unclassified
Recent changes (Other open bugs)
1.6.x
All All
: Normal enhancement (vote)
: ---
Assigned To: Myk Melez
: patch, patch-need-review
Depends on:
Blocks: feeds
  Show dependency treegraph
 
Reported: 2005-11-16 22:22 UTC by Myk Melez
Modified: 2011-09-30 16:37 UTC (History)
2 users (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Attachments
patch v1: implements global option for specifying preferred mode (3.76 KB, patch)
2005-12-03 02:56 UTC, Myk Melez
Details

Description Myk Melez 2005-11-16 22:22:05 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
Comment 1 Brion Vibber 2005-11-16 22:28:31 UTC
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.
Comment 2 Myk Melez 2005-11-16 22:49:22 UTC
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.
Comment 3 Myk Melez 2005-12-03 02:56:16 UTC
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.
Comment 4 Siebrand Mazeland 2009-02-02 12:43:16 UTC
Changed component to "RecentChanges"
Comment 5 Sumana Harihareswara 2011-09-30 14:17:43 UTC
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.
Comment 6 Myk Melez 2011-09-30 16:37:08 UTC
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. :-)

Note You need to log in before you can comment on or make changes to this bug.


Navigation
Links