Last modified: 2014-06-05 09:54:03 UTC
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
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.
for b in \
;do echo $b; lynx -width=111 -nolist -dump $u\&$b$k|perl -nwle 'print if /^\d/'
31 May 2007
26 May 2007
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
> 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
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.