Page MenuHomePhabricator

RSS feed for recent changes should have its result limit applied after filtering not before
Open, LowPublic

Description

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...


Version: 1.16.x
Severity: minor

Details

Reference
bz19330

Event Timeline

bzimport raised the priority of this task from to Low.Nov 21 2014, 10:38 PM
bzimport set Reference to bz19330.
bzimport added a subscriber: Unknown Object (MLST).

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.

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.

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

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.