Last modified: 2011-04-14 15:10:39 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 T11257, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 9257 - Consider $wgRCMaxAge when generating limit links for recent changes
Consider $wgRCMaxAge when generating limit links for recent changes
Status: NEW
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:
  Show dependency treegraph
 
Reported: 2007-03-11 20:19 UTC by Dan Jacobson
Modified: 2011-04-14 15:10 UTC (History)
3 users (show)

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


Attachments

Description Dan Jacobson 2007-03-11 20:19:48 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.
Comment 1 Daniel Friesen 2008-05-17 16:10:02 UTC
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 );
Comment 2 Brion Vibber 2008-05-19 16:11:10 UTC
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
Comment 3 Daniel Friesen 2008-05-19 16:51:02 UTC
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.
Comment 4 Brion Vibber 2008-05-19 17:34:10 UTC
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. :)
Comment 5 Dan Jacobson 2009-03-18 06:06:00 UTC
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;
Comment 6 Niklas Laxström 2009-05-23 08:43:12 UTC
(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.

Comment 7 Dan Jacobson 2009-06-19 01:14:24 UTC
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.
Comment 8 Dan Jacobson 2009-06-19 01:49:23 UTC
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 );
Comment 9 Dan Jacobson 2009-06-21 23:49:23 UTC
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));

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


Navigation
Links