Revision: 48735
Author: midom
Date: 2009-03-24 10:44:24 +0000 (Tue, 24 Mar 2009)
Log Message:
change limit to reflect one in interface. :)
Modified Paths:
trunk/phase3/includes/specials/SpecialRecentchanges.php
Modified: trunk/phase3/includes/specials/SpecialRecentchanges.php
===================================================================
--- trunk/phase3/includes/specials/SpecialRecentchanges.php 2009-03-24 09:59:13 UTC (rev 48734)
+++ trunk/phase3/includes/specials/SpecialRecentchanges.php 2009-03-24 10:44:24 UTC (rev 48735)
@@ -55,7 +55,7 @@
$this->parseParameters( $parameters, $opts ); }
- $opts->validateIntBounds( 'limit', 0, 5000 );
$opts->validateIntBounds( 'limit', 0, 500 );
return $opts;
}
Was this necessary for performance reasons? A lot of people were using
500 recentchanges lists, some wikis even had them as options on the
RC interface (see http://hu.wikipedia.org/wiki/MediaWiki:Recentchangestext for example). If it was only changed for aesthetic purposes, please change it back, or make it a site option.
On Fri, Mar 27, 2009 at 12:55 PM, Tisza Gergő gtisza@gmail.com wrote:
Was this necessary for performance reasons?
That was his motivation, yes. It takes a ludicrous amount of time for a single recentchanges row to render: last I checked, multiple queries per row (!) and a really unreasonable number of milliseconds rendering the links.
Paging links would probably be fine to add if people want access to older rows.
Helloes,
If it was only changed for aesthetic purposes, please change it back, or make it a site option.
It wouldn't be aesthetic change, if it didn't change anything in how things look like. No, it was performance change. I did rework _some_ of the RC code, reducing at least 30% of costs involved. Still, it is way way too expensive - complex display logic is used for something very simple. Probably it would be best to have simple paging and/or AJAX RC browser (just take a look at http://toolserver.org/~river/recentchanges/ ;-)
BR,
wikitech-l@lists.wikimedia.org