Last modified: 2012-11-21 14:30:16 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 9605 - Add "hide minor edits" option to Special:Contributions
Add "hide minor edits" option to Special:Contributions
Product: MediaWiki
Classification: Unclassified
Special pages (Other open bugs)
All All
: Lowest enhancement with 1 vote (vote)
: ---
Assigned To: Nobody - You can work on this!
: schema-change
Depends on:
  Show dependency treegraph
Reported: 2007-04-17 11:30 UTC by Jonathan Métillon
Modified: 2012-11-21 14:30 UTC (History)
4 users (show)

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


Description Jonathan Métillon 2007-04-17 11:30:44 UTC
There's an option available at the Special:Recentchanges page that allows to
hide minor changes. The parameter is hideminor=1.

But on Special:Contributions/User, the parameter is not available. I think it
would be helpful to hide minor changes in user contributions page also.

Thank you.
Comment 1 Rob Church 2007-06-07 20:17:11 UTC
Note that we don't have an index on revision.rev_minor_edit at the moment; we'll want to include it in the relevant indices.
Comment 2 Aryeh Gregor (not reading bugmail, please e-mail directly) 2007-12-16 20:57:34 UTC
I don't think an extra index is useful, unless a large percentage of rows are minor edits.  It would probably be better to scan twice as many rows, rather than add an entire extra index.
Comment 3 Brion Vibber 2007-12-18 01:08:31 UTC
(In reply to comment #2)
> I don't think an extra index is useful, unless a large percentage of rows are
> minor edits.

Well, that might be fairly likely for maintenance bots that make large numbers of minor edits.
Comment 4 Aryeh Gregor (not reading bugmail, please e-mail directly) 2007-12-18 02:50:26 UTC
Hmm, true, that would scan all of that user's contribs, since this is per-user.  But I'm not sure where we'd add the column to the index.  usertext_timestamp is (rev_user_text, rev_timestamp).  If we make it (rev_user_text, rev_minor_edit, rev_timestamp) that breaks ordering by rev_timestamp for when we don't specify rev_minor_edit: we'd have to do rev_minor_edit IN (0,1) for other queries, and range scans break ordering, it would be a filesort.  It would be better in MySQL 4 to rewrite as a UNION, but then you need to query twice the rows anyway.  Whereas if we do (rev_user_text, rev_timestamp, rev_minor_edit), it can't use the index to retrieve by rev_minor_edit while ordering by rev_timestamp, which defeats the point.

I would ask Domas.  :)  I suspect this is impractical without adding an entirely separate index for it, since as you point out we can't rely on scanning rows here.  If he doesn't have any bright ideas, I guess this is WONTFIX, at least for Wikipedia.  This is the kind of thing it would be nice for smaller sites to have, though, which don't mind scanning a whole bunch of rows, if it really isn't possible to get this to work reasonably on the large sites.  So maybe this should still be done for $wgMiserMode = false by just scanning the rows, icky though that may be.
Comment 5 Aaron Schulz 2009-01-03 13:55:42 UTC
Comment 6 Nemo 2010-06-07 12:48:17 UTC
This would be very useful in page histories, too. 
It could be implemented as an option (to be disabled for very large wikis), couldn't it? Nobody has more efficient ways than the ones found three years ago? 
Marking it as LATER.
Comment 7 Nemo 2012-11-14 12:23:53 UTC
Switching from LATER to the second most relevant resolution for fear of information loss.

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