Last modified: 2014-06-05 09:56:27 UTC

Wikimedia Bugzilla is closed!

Wikimedia migrated from Bugzilla to Phabricator. Bug reports are handled in Wikimedia Phabricator.
This static website is read-only and for historical purposes. It is not possible to log in and except for displaying bug reports and their history, links might be broken. See T21330, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 19330 - RSS feed for recent changes should have its result limit applied after filtering not before
RSS feed for recent changes should have its result limit applied after filter...
Status: REOPENED
Product: MediaWiki
Classification: Unclassified
Recent changes (Other open bugs)
1.16.x
All All
: Low minor (vote)
: ---
Assigned To: Nobody - You can work on this!
:
Depends on:
Blocks: feeds
  Show dependency treegraph
 
Reported: 2009-06-22 00:10 UTC by Dan Jacobson
Modified: 2014-06-05 09:56 UTC (History)
1 user (show)

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


Attachments

Description Dan Jacobson 2009-06-22 00:10:40 UTC
Users accessing
title=Special:RecentChanges
will always get
$wgDefaultUserOptions['rclimit']=50 items.
(execpt in the rare case that there really isn't that many items yet
in the recentchanges table.)

In contrast, users accessing
title=Special:RecentChanges&feed=rss (or feed=atom)
will get an inconsistent number of <item>s, only rarely all
$wgFeedLimit=$wgDefaultUserOptions['rclimit']=50.

The problem lies in
SpecialRecentchanges.php's function feedSetup().

It causes the steps
"1. filter, 2. limit"
to become the incorrect
"0. limit, 1. filter, 2. limit".

However it also has some other considerations mentioned... so I dare not tamper...
Comment 1 Brion Vibber 2009-06-23 01:56:43 UTC
This is presumably due to consolidation of adjacent entries for the same page. We're fetching that many items, then consolidating them. Shouldn't be terribly unpleasant. :) You perhaps want something like bug 3998 -- cleaning up the way the feed is generated to go with item-per-change rather than attempting to consolidate.
Comment 2 Dan Jacobson 2009-06-23 18:07:31 UTC
> You perhaps want something like bug 3998 -- cleaning up the way
> the feed is generated to go with item-per-change rather than attempting to
> consolidate.

It is none of my business what content you want to deliver in the feed.
Compact all you want. Just do it with the "bus door" open, not already
closed (see below.)
All I am concerned about is that you use the correct algorithm, and not
one with "infighting", causing what should be a full feed to act like
someone is stepping on the garden hose:

$ for i in en.wikipedia.org zh.wikipedia.org www.mediawiki.org
> do GET "http://$i/w/index.php?title=Special:RecentChanges&feed=rss"|grep -c '<item>'; done
50
48
37

We see that only on the world's biggest wiki does one get all 50.
For the others the "feed bus" with its 50 seats leaves the station with
many of those seats empty, despite the long lines of qualified passengers
screaming in the background.

Every morning I open up my feed reader. Other sites are brimming at
their predefined defaults, 50, 30, 10, etc.
This says to me that if I really don't want to miss any articles, then I
had better install rss2email etc. because each of those feeds have
already spilled over their top.

Now let's turn to Mediawiki feeds. Well, with their surely
infighting-like algorithm, they look on the surface like feeds that
haven't filled to their capacity the last time I looked at them, so I
must be seeing the full feed with nothing spilling over --- but in fact
there's plenty of good articles that should have occupied those empty
seats at the end, if only the ticket-taker lady hadn't slammed the door
in their face.

Anyway, you must admit to existence of constipation if all that one can
squeeze out of the feed for www.mediawiki.org is 37 <item>s.

All the other leading brands of software are able to operate their feeds
at full capacity, even Special:RecentChanges is full capacity.
Comment 3 Dan Jacobson 2009-06-28 20:38:50 UTC
Compare the reliable links offered on e.g.,
http://groups.google.com/group/kml-support-getting-started/feeds :
  Atom 1.0          RSS 2.0
  15 New messages   15 New messages
  50 New messages   50 New messages
  15 New topics     15 New topics
  50 New topics     50 New topics
Comment 4 Krinkle 2014-06-05 09:56:27 UTC
The limit being applied first seems like a bug, not a lacking feature. limit=20 should yield in 20 results (unless there aren't that many recent changes of course). We do this correctly already on Special:RecentChanges and in the API.

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


Navigation
Links