Last modified: 2011-04-14 15:10:39 UTC
I would change the wording here to something other than "periodically" as random is rather opposite of periodically: Article.php-2221- if ( 0 == mt_rand( 0, 999 ) ) { Article.php-2222- # Periodically flush old entries from the recentchanges table. Article.php:2226: $cutoff = $dbw->timestamp( time() - $wgRCMaxAge ); Article.php-2228- $sql = "DELETE FROM $recentchanges WHERE rc_timestamp < '{$cutoff}'"; Here too: DefaultSettings.php-1515- /** DefaultSettings.php-1516- * Recentchanges items are periodically purged; entries older than this many DefaultSettings.php-1517- * seconds will go. DefaultSettings.php-1518- * For one week : 7 * 24 * 3600 DefaultSettings.php-1519- */ DefaultSettings.php:1520: $wgRCMaxAge = 7 * 24 * 3600; RecentChange.php-158- # Don't bother looking for entries that have probably RecentChange.php-159- # been purged, it just locks up the indexes needlessly. RecentChange.php:160: global $wgRCMaxAge; RecentChange.php-161- $age = time() - wfTimestamp( TS_UNIX, $lastTime ); RecentChange.php:162: if( $age < $wgRCMaxAge ) { RecentChange.php-163- # live hack, will commit once tested - kate RecentChange.php-164- # Update rc_this_oldid for the entries which were current Sure hope in Special:Recentchanges you then consider $wgRCMaxAge before offering all of the presently hardwired "1 | 3 | 7 | 14 | 30 days". I.e., rcDayLimitLinks() should consider $wgRCMaxAge. Currently it seems according to the code that 14, 30 results will one day get truncated unexpectedly on smaller wikis out of the blue, slowly growing back until one day truncated again. Just another case of assuming big busy wikis. Smaller wikis must set $wgRCMaxAge = 30 * 24 * 3600; or else users will wonder why suddenly one day 14, 30 results become 7.
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));