Last modified: 2014-06-05 09:54:03 UTC
On Special:Recentchanges one sees a link "Show new changes starting from 10:51, 2 March 2009" so one clicks it, and notices that it puts a from=20090302025155 in one's browsers' URL bar. So, one thinks, "we can just adjust the URL, to get different result, (as the authors don't give us any way to adjust the time by just clicking on something.)" So one tries from=20070301000000 i.e., two whole years back. But no results are forthcoming! It turns out there is still a hidden parameter at work behind the scenes: days. Default 7 I bet. So to fix this bug: please ignore days= if you find you have been given a from=, (unless days= is also present in the query string.) How did I discover this bug? Well I have an 1.14 wiki, but with few changes (as it is a offline test wiki.) On a busy wiki, nobody probably would have discovered this bug. Proof: k=\&uselang=en u="http://MY_OFFLINE_WIKI/index.php?title=Special:Recentchanges" for b in \ "&from=20070301000000&days=777" \ "&from=20090301000000&days=777" \ "&from=20070301000000&days=77" \ "&from=20090301000000&days=77" \ ;do echo $b; lynx -width=111 -nolist -dump $u\&$b$k|perl -nwle 'print if /^\d/' done GIVES: &from=20070301000000&days=777 31 May 2007 26 May 2007 &from=20090301000000&days=777 &from=20070301000000&days=77 &from=20090301000000&days=77 P.S., note also Bug #17749#c1 .
Note: this condition can only be reached while tampering the url manually. It might be possible to argue that the suggested solution is do-what-i-mean in most cases, but not all.
Have you verified that the days parameter is the problem? From your description of the problem, it sounds like you're speculating. The real problem is most likely that recent changes entries are deleted after 30 days.
> tampering the url manually. The user is very much led to tampering with the URL, as there is no other way of adjusting the date produced by the click, other than the juicy URL sitting there waiting to be tampered with. > verified that the days parameter is the problem? As you can see from the above output &from=20070301000000&days=777 produced output, but &from=20070301000000&days=77 didn't. > recent changes entries are deleted after 30 days. Ah, but only perhaps when a new change is made. And even then, it would only be polite if Recentchanges took a lesson from the last(1) command: $ last jidanni jidanni pts/0 122-127-32-142.d Tue Mar 3 10:18 still logged in jidanni pts/0 122-127-39-141.d Mon Mar 2 15:22 - 17:25 (02:03) wtmp begins Sun Mar 1 22:28:19 2009 I.e., it tells the user why he didn't login last month... the records are gone, so it admits it doesn't know. For the MediaWiki case this is hard to test, as most wikis are very busy. However, for the case where the listing ends, and it is not because we have reached limit=, nor days=, nor due to from=, well, in this case it is because we have reached the end of the available data, and a message about that fact should be appended to the bottom, so the user can distinguish the case of no activity, vs. possible gone activity. Maybe that should be a separate bug. Sorry I don't have any diffs for you, I would probably just make things worse.
