mediawiki's Special: Recent Changes bug · 30 November 2009, 15:04
It turns out that mediawiki’s “Special:RecentChanges” does not, by default, offer the functionality it promises to. Specifically, prior to mediawiki 1.16.0, if you were trying to run mediawiki out of the box, the links ‘14’ and ‘30’ days were entirely useless.
Why is this? Because DefaultSettings.php includes this line:
$wgRCMaxAge = 7 * 24 * 3600;
Seven days. 7 days. That’s all there is. Changes older than that are purged from the recentchanges database.
The solution is, of course, simple:
$wgRCMaxAge = 30 * 24 * 3600;
Or, if you want to be ‘forward-compatible’ with 1.16.0+, the new default value is:
$wgRCMaxAge = 13 * 7 * 24 * 3600;
Just tack it into your LocalSettings.php and you’re good to go.
I noticed this morsel while trying to make the slow-paced discussion namespace of a project more accessible to the project’s team and added a “Last 500 changes in the last 30 days” discussion-namespace-filtered recentchanges link to the navigation. For some reason, things were dropping off it faster than 30 days. After some watching over time, I suspected 7 because it was one of the options, and sifted through mediawiki code, suspecting a proper bug in coding related to the namespace.
Nuh.
By perusing the code, though, I noticed that the data was being pulled from a table called recentchanges – and that finally tipped me into the right direction. One google search later brought me to the ‘Recentchanges table’ manual page on mediawiki.org, which in its very first paragraph mentions $wgRCMaxAge.
The revision I found read 13 * 7 * 24 * 3600 as default. I checked my file. Nope. 7 days. I fixed it on mediawiki – which prompted a helpful soul to fix it properly.
So, now you know.
— Neike Taika-Tessaro
Comment
| Categories: | bugisms, knowledge |
|---|---|
| Related: | Apache & PHP: Headache with POST / GET · 10 December 2011, 02:43JavaScript and CSS Block Encoding: Broken by design · 1 September 2010, 14:44Dear Google · 15 April 2010, 16:27Extending phpDocumentor with custom tags · 23 October 2009, 19:36PHP loose type comparison: Arrays · 18 September 2009, 13:30 |
The Recent Changes page worked fine for me in 1.14.0. By manually editing the days= field in the URL, I could go back as far as I needed to, sometimes several months. I didn’t notice any problems until I tried doing the same thing in 1.15.5. In 1.15.5, I only had 3 weeks of Recent Changes.
I found the wgRCMaxAge page that you edited, and at first I didn’t believe that it was correct. It said that the default before 1.16.0 was 7 days, but my personal observations showed that Recent Changes held 3 weeks in 1.15.5, and more in 1.14.0. However, after running rebuildrecentchanges.php without editing wgRCMaxAge in LocalSettings.php, I noticed the output line that said $wgRCMaxAge = … (7 days).
Something screwy is going on. The Recent Changes page does not actually conform to the wgRCMaxAge environment variable. I can’t even get my older pages back by setting wgRCMaxAge to 6 months and running rebuildrecentchanges.php.
— Bob · 13 November 2010, 07:11 · #
Bob, that’s really strange – I’d have to check what version it was we were running, but it was definitely cutting off pages older than seven days for us, by default. We had enough traffic that no one really noticed until we permalinked to a RecentChanges parametrised to one namespace only (‘Discussion’), because no one ever wanted to go back that far.
On the other hand I’d very much not be surprised if that issue was version-specific, and former versions didn’t honour the setting right, and once the software did, they adjusted it, and we managed to get the one version that exhibited the bug. After all, mediawiki is a fairly commonly used software, so you’d think a bug like this would be more obvious on the internet at large.
Thank you for sharing your observations, though! Very strange. I wish I could explain the discrepancy.
— Neike Taika-Tessaro · 14 November 2010, 13:17 · #