In r34983 the limits and days are now customizable.
There is also a configuration option that will trim the list of days by what $wgRCMaxAge says will be stored.

/**

• Filter $wgRCLinkDays by $wgRCMaxAge to avoid showing links for numbers higher than what will be stored.
• Note that this is disabled by default because we sometimes do have RC data which is beyond the limit
• for some reason, and some users may use the high numbers to display that data which is still there. */

$wgRCFilterByAge = false;

/**

• List of Days and Limits options to list in the Special:Recentchanges and Special:Recentchangeslinked pages. */

$wgRCLinkLimits = array( 50, 100, 250, 500 );
$wgRCLinkDays = array( 1, 3, 7, 14, 30 );

I'd recommend a couple further changes:

• Enforce the maxage cutoff in the RecentChanges queries so behavior is consistent

• Dump $wgRCFilterByAge as unnecessary

• Bump the default maxage to at least 30 days (maybe even 90) to be more appropriate for smaller sites out of the box

For the first point, do you mean improving how the purging is done for old entries. Or by including an actual WHERE into the SQL query that will enforce the age?
Or, perhaps use a min to enforce that the maximum user input does not go over $wgRCMaxAge.

I'd be happy to drop the variable if things were made consistent.

I didn't bump up the age limit cause of Wikimedia and other high activity wiki which use the default 7 afaik for performance. But I'd be happy to bump that limit if you say it's ok.

I'd say including the minimum timestamp cutoff in the query should be just fine.

(It might also be nice to improve the purging, but that's really a totally separate issue!)

We currently have our $wgRCMaxAge explicitly set to 30 days on all Wikimedia sites.

Of course, on busier sites you'll never be able to *reach* 30 days' worth of edits in one go from Special:RecentChanges. :)

Please reconsider the value of

/**

• Filter $wgRCLinkDays by $wgRCMaxAge to avoid showing links for numbers higher than what will be stored.
• Note that this is disabled by default because we sometimes do have RC data which is beyond the limit
• for some reason, and some users may use the high numbers to display that data which is still there. */

$wgRCFilterByAge = false;

Consider that now that $wgRCMaxAge = 7 * 24 * 3600,
the user will discover that the "14" and "30" day links malfunction.
Worse is on smaller wikis. The user cannot tell if there really was no
activity or not!

That "we sometimes do have RC data which is beyond the limit" sounds
like a bug that was fixed. And "some users may use the high numbers"
sounds like power users who probably have other ways to get the data.

So I would change the comment too.

Please just use:

/**

• Filter $wgRCLinkDays by $wgRCMaxAge to avoid showing links for numbers higher than what will be stored. */

$wgRCFilterByAge = true;

(In reply to comment #2)

I'd recommend a couple further changes:

• Bump the default maxage to at least 30 days (maybe even 90) to be more

appropriate for smaller sites out of the box

r50930.

By the way, how homely to generate this by hand when one can do
foreach(range(0,5)as $i){$wgRCLinkDays[]=pow(2,$i);}print_r($wgRCLinkDays);'
Array
(

[0] => 1
[1] => 2
[2] => 4
[3] => 8
[4] => 16
[5] => 32

)
True, you don't get exact week and "30 day months" divisions.
P.S., see also bug 17867.

Say, also
foreach(range(0,3)as $i){$wgRCLinkLimits[]=60*pow(2,$i);}print_r($wgRCLinkLimits);
Array
(

[0] => 60
[1] => 120
[2] => 240
[3] => 480

)
Anyways, both come close to the current hardwired
$wgRCLinkLimits = array( 50, 100, 250, 500 );
$wgRCLinkDays = array( 1, 3, 7, 14, 30 );

Actually for my http://www.mediawiki.org/wiki/Manual:Wiki_family , in LocalSettings.php I now use

switch($wgSitename){case 'ABJ':$i=14;break;default:$i=9;}
unset($wgRCLinkDays);foreach(range(0,$i)as $j){

$z=pow(2,$j);printf("2^%2d, %5d days, %6.1f months, %3.1f years\n",$j,$z,$z/30,$z/365);if($j==$i){die();}else{continue;}

$wgRCLinkDays[]=pow(2,$j);}

$wgRCMaxAge=3600*24*($wgDefaultUserOptions['rcdays']=end($wgRCLinkDays));