Last modified: 2011-03-30 22:42:16 UTC

Wikimedia Bugzilla is closed!

Wikimedia migrated from Bugzilla to Phabricator. Bug reports are handled in Wikimedia Phabricator.
This static website is read-only and for historical purposes. It is not possible to log in and except for displaying bug reports and their history, links might be broken. See T3558, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 1558 - Special:Export does not support IfModifiedSince
Special:Export does not support IfModifiedSince
Product: MediaWiki
Classification: Unclassified
Export/Import (Other open bugs)
All All
: Normal enhancement with 2 votes (vote)
: ---
Assigned To: Nobody - You can work on this!
Depends on:
  Show dependency treegraph
Reported: 2005-02-18 09:51 UTC by Osric Wilkinson
Modified: 2011-03-30 22:42 UTC (History)
2 users (show)

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

Adds IfModifiedSince support to Special:Export (1.15 KB, patch)
2005-02-18 09:53 UTC, Osric Wilkinson

Description Osric Wilkinson 2005-02-18 09:51:31 UTC
Special:Export does not support the HTTP header IfModifiedSince, even in single page mode.
Comment 1 Osric Wilkinson 2005-02-18 09:53:01 UTC
Created attachment 295 [details]
Adds IfModifiedSince support to Special:Export

Patch against 1.4beta6 to add IfModifiedSince support to Special:Export.
Nothing fancy
Comment 2 Tomer Chachamu 2005-06-14 12:49:00 UTC
If this were done,
would be easier for external sites to implement. (I want to make such a site if
MediaWiki will not take this suggestion)

The proposal follows because things come and go on the pump, although it will be
filed on bugzilla at some point.

It struck me that to speed the discovery of vandalism, pumping out diffs at a
high rate on a specific page, thereby getting rid of the Recentchanges
middleman, may be a good idea.

It would be similar in structure to Slashdot's Meta Moderation
( system: a designated page, perhaps
Special:Monitor, would pump out X number of recent diffs made within the last Y
days, on one single page, for the purpose of fast eyeballing.

This would cut out the "middleman" of Recentchanges for those on janitorial
duty; only the refresh button needs to be repeatedly abused in order to view
massive amounts of diffs and scan for vandalism at a very fast rate.

The details of the method by which diffs are chosen for display can be left to
peoplewith more expertise, but I'll offer up some suggestions:

    * The number of diffs and timerange to pull from can be
          o user customisable, or
          o fixed at say, 10 diffs per page, pulled from diffs made within the
last 5 days
    * The choosing of whether a diff displays on Monitor can be
          o completely random, or
          o completely random, but "viewed" diffs are never viewed again, or
          o use a probability system.
                + a more frequently edited/viewed article, the diffs of the
article will appear on Monitor more frequently
                + an already viewed diff would have its probability of being
chosen for Monitor cut, to say, 1/1000th of the original probability

Only suggestions, I don't know enough about the throughput of changes and the
number of janitors on duty at any given time to know which method is more
feasible. But I believe a Monitor page would greatly facilitate the speedy
discovery of vandalism.

Znode 05:40, 2005 Jun 14 (UTC)

    Now, there's something for me to consider... r3m0t talk 12:07, Jun 14, 2005
Comment 3 Tomer Chachamu 2005-06-14 12:49:31 UTC
Oh... has anyone checked this on 1.5? Maybe somebody fixed it without knowing
about this bug report.
Comment 4 Brion Vibber 2005-07-10 22:52:05 UTC
A few notes:
* SpecialExport.php has changed quite a bit in 1.5, this patch won't apply
* You need to use the page_touched time, not the revision edit timestamp; renames, undeletes, and such wacky things 
might make the last edit timestamp inconsistent.
* The check is happening in the wrong place -- multiple pages may be exported, or we might be exporting to a file with no 
web server in sight. Since this will only be meaningful for single-page GET requests, the check should probably happen 
higher up in the code before the exporter gets involved.
Comment 5 Brion Vibber 2005-10-22 21:44:33 UTC
Removing need-review, patch keywords as patch failed review.
Comment 6 Siebrand Mazeland 2008-08-18 18:47:27 UTC
Mass compoment change: <some> -> Export/Import
Comment 7 Happy-melon 2011-03-30 22:42:16 UTC
Special:Export has changed its behaviour completely over the intervening six years; the functionality desired here is probably best found in the API or the RecentChanges Atom/RSS feeds; file appropriate new bugs if more functionality is desired there.

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