Last modified: 2014-06-05 09:54:03 UTC

Wikimedia Bugzilla is closed!

Wikimedia has migrated from Bugzilla to Phabricator. Bug reports should be created and updated in Wikimedia Phabricator instead. Please create an account in Phabricator and add your Bugzilla email address to it.
Wikimedia Bugzilla is read-only. If you try to edit or create any bug report in Bugzilla you will be shown an intentional error message.
In order to access the Phabricator task corresponding to a Bugzilla report, just remove "static-" from its URL.
You could still run searches in Bugzilla or access your list of votes but bug reports will obviously not be up-to-date in Bugzilla.
Bug 17750 - Special:Recentchanges should ignore 'days=' if 'from=' is specified
Special:Recentchanges should ignore 'days=' if 'from=' is specified
Status: NEW
Product: MediaWiki
Classification: Unclassified
Recent changes (Other open bugs)
All All
: Low minor (vote)
: ---
Assigned To: Nobody - You can work on this!
Depends on:
  Show dependency treegraph
Reported: 2009-03-02 06:27 UTC by Dan Jacobson
Modified: 2014-06-05 09:54 UTC (History)
2 users (show)

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


Description Dan Jacobson 2009-03-02 06:27:16 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
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 \
"&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/'
31 May 2007
26 May 2007

P.S., note also Bug #17749#c1 .
Comment 1 Niklas Laxström 2009-03-02 07:38:48 UTC
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.
Comment 2 Andrew Garrett 2009-03-02 07:39:49 UTC
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.
Comment 3 Dan Jacobson 2009-03-03 02:27:55 UTC
> 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

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.

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