Last modified: 2014-06-05 09:56:27 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...
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.