Last modified: 2011-03-13 18:06:17 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 756 - Significantly speeding up Recent Changes (RC): show only last revision
Significantly speeding up Recent Changes (RC): show only last revision
Status: RESOLVED WONTFIX
Product: MediaWiki
Classification: Unclassified
Special pages (Other open bugs)
1.3.x
All All
: Lowest normal (vote)
: ---
Assigned To: Nobody - You can work on this!
http://meta.wikimedia.org/wiki/Email_...
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2004-10-21 16:27 UTC by T. Gries
Modified: 2011-03-13 18:06 UTC (History)
0 users

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


Attachments
screenshot of RC UseMod style view showing only the recent version (28.06 KB, image/png)
2004-10-30 08:52 UTC, T. Gries
Details

Description T. Gries 2004-10-21 16:27:29 UTC
I loved the way, UseMod-Wiki software displays Recent Changes: you see each page
only ONCE, ie. the last and most recently changed version.

After my analysis of the big WikiPedias - standard and enhancement RC view - I
found, that the "UseMod-RC-style" could significantly save processing time and
bandwidth (for current MediaWiki software, a lot of usually
not-at-the-first-view interesting information is sent to the client: date and
time of ALL pages ***and their older revisions*** until the cut-off condition is
met.

So, I found a tiny patch to significantly speed-up the RC view:

In module SpecialRecentchanges.php change the line (about line #100)

      WHERE rc_timestamp > '{$cutoff}' {$hidem} ".
to
      WHERE rc_timestamp > '{$cutoff}' {$hidem} AND rc_this_oldid=0 ".

This has the side effect, that enhance RC views do not have the older revisions
transmitted to the clients browser. But  who actually has needed these ? You can
always click on "hist" link to get the older revisions sent to your client.

My goal was, to quicken the RC view significantly. The patch saves bandwidth, as
users who are interested in older revisions can simply click on hist links to
get these.

Remark:
A new, forthcoming Enotif patch revision will enable each user to have ONE
additional link "lastvisited" for WATCH-LISTED pages

     (bold, because watchlisted)page title (diff)(hist)(lastvisited)

on which he/she can click to get immediately the diff between the current
version and THE LAST VISITED ONE.
Comment 1 Rowan Collins [IMSoP] 2004-10-21 19:48:30 UTC
The big disadvantage of hiding all but the most recent change from RC is that it
provides a neat way of slipping vandalism past anyone watching: vandalise one
section of an article, then quickly make a valid and minor edit to a different
section. If only the second edit shows up on RC, people "patrolling" will check
the diff and assume the edit is sound; whereas currently, *both* edits will show
up, and be checked seperately by patrollers.

Perhaps there could be a *option* to simply hide all but one edit per page, but
I'm not sure how useful this would be, since we'd want it turned off by default
because people wouldn't know it was there to turn off (if they wanted to go on
patrol, and avoid the scenario above).
Comment 2 Brion Vibber 2004-10-21 20:33:29 UTC
I agree with Rowan's comments; I don't see how this would be any faster either.
Comment 3 T. Gries 2004-10-21 20:36:35 UTC
(In reply to comment #2)
> I agree with Rowan's comments; I don't see how this would be any faster either.
> 

PLEASE: Try it first, to see how it works. Then comment. Thank you,
(I came from UseMod, and the RC view is quicker there: you save all the (first)
not needed revision data)
Comment 4 Brion Vibber 2004-10-21 20:54:12 UTC
UseMod's RecentChanges display also shows the number of changes so you can directly see that there have been multiple changes that need to be 
reviewed -- an important part that making this change would lose, but which is already included in our 'enhanced recent changes' mode.

Can you explain what you mean by 'quicker'? As far as I can see it will pull and format the same number of rows, so what's the difference? If anything, 
hopping about through the indexes more might make the query slower. Have you benchmarked it?
Comment 5 Rowan Collins [IMSoP] 2004-10-22 12:48:52 UTC
I presume the assumption was that by excluding all but one revision in the
actual SQL query, it would be retrieving less info from the DB. But this would,
of course, exclude even the "X changes have been made" labels, since the query
would have no idea of any but the most recent change per article.
Comment 6 T. Gries 2004-10-22 12:59:50 UTC
(In reply to comment #5)
> I presume the assumption was that by excluding all but one revision in the
> actual SQL query, it would be retrieving less info from the DB. But this would,
> of course, exclude even the "X changes have been made" labels, since the query
> would have no idea of any but the most recent change per article.

Your are right. However, for me, the past does not count. What counts, is the
current version. The enotif patch comes with an advanced method of having a
direct link to the last visited page version (diff between current and last
visited version). This additional link is much more sexier than to see hundreds
of "edit wars" on an article.

But I will definitely pay attention to your remark and I *will COUNT and show
the available recent VERSIONS. By the way, I already show the number of watching
users.

If you have access to the source of your wiki, it's worth to apply my patch for
a while and to see the difference in the output. Most of my colleagues do like it.

For the MediaWiki Software CVS version, I already programmed a global variable,
with which the Admin can enable or disable ($wgRCUseModStyle = true | false) the
here proposed feature.

That you anyway for your contributions.
Tom
Comment 7 Rowan Collins [IMSoP] 2004-10-22 15:19:52 UTC
(In reply to comment #6)
> If you have access to the source of your wiki, it's worth to apply my patch for
> a while and to see the difference in the output. Most of my colleagues do like it.

I admit, I haven't tried making the change mentioned in comment #0, but as far
as I can make out, the result will be something similar to the "enhanced recent
changes" when all the multiples are collapsed. Correct me if I'm wrong, and
indeed I apologise if this assumption is wrong enough to invalidate any of my
comments below.

> Your are right. However, for me, the past does not count. What counts, is the
> current version. The enotif patch comes with an advanced method of having a
> direct link to the last visited page version (diff between current and last
> visited version). This additional link is much more sexier than to see hundreds
> of "edit wars" on an article.

Just to clarify, this isn't about the importance of "the past", it's about the
fact that diffs only highlight what has been changed in a particular revision.
So if you show only one change to a large article, other changes will simply
disappear; people patrolling RecentChanges to spot vandalism do *not* read the
whole of every article that has been changed, to check for *old* vandalism, they
check the diff of each change to see if *it* is vandalism. I do think the "(last
visited)" link for watchlisted pages is a very good idea, but it is the solution
to a different problem: how to keep track of an article that you have read and
understand the whole of, and make sure no vandalism or dodgy edit slips through
on a longer timescale.

I note that the "parent" of each group of edits on enhanced recent changes
already has a link labelled "changes" that shows a diff incorporating all the
collapsed changes, so you don't even have to look at each one individually and
trawl through edit wars etc.

As an example, look at
http://en.wikipedia.org/w/wiki.phtml?title=User:IMSoP/sandbox&action=history As
I understand it, your proposed RecentChanges view would only list the most
recent change, which is
http://en.wikipedia.org/w/wiki.phtml?title=User:IMSoP/sandbox&diff=0&oldid=6772150
- a perfectly valid edit, no vandalism here. What won't be spotted is that a
short time before there was another edit (which in reality would probably be an
unlabelled contribution from a non-registered user):
http://en.wikipedia.org/w/wiki.phtml?title=User:IMSoP/sandbox&diff=6772150&oldid=6772102
Thus the one-change-only view severely compromises one of the main roles of the
RecentChanges page: spotting vandalism. 

As you say, if I had the page on my watchlist, a "last visited" link might point
to
http://en.wikipedia.org/w/wiki.phtml?title=User:IMSoP/sandbox&diff=0&oldid=6772102
and I would spot the problem, but this is no good if no-one happens to be
actively watching it (i.e. checking their watchlist, or recentchanges where it
is bolded, at that particular moment). The current "enhanced recent changes"
would have a link pointing to that diff anyway, comparing <oldest version at
$cutoff> with <version now>, but if you're not pulling old edits from the
database, you can't have this, either.

> But I will definitely pay attention to your remark and I *will COUNT and show
> the available recent VERSIONS. By the way, I already show the number of watching
> users.

The thing with this is, that in order to count the number of changes, you will
be pulling exactly the same information out of the database as the current
version, but just not transmitting all of it to the client. So essentially
you'll have something like the current "enhanced recent changes", but without
the JavaScript that lets you expand the multiples. Personally, I'm not sure the
bandwidth involved in transmitting this extra information is significant enough
to bother about, but that's to some extent a matter of opinion.
Comment 8 T. Gries 2004-10-22 15:32:47 UTC
(In reply to comment #7)

Thank you for your really ***valuable comments*** !

> The thing with this is, that in order to count the number of changes, you will
> be pulling exactly the same information out of the database as the current
> version, but just not transmitting all of it to the client.

Regarding your last paragraph, exactly, you've got it, it was my intention to
save bandwidth. (Wikipedians have told me ugly things, when I introduced SOME
more bytes with a visible NEW marker, but that's history). 

Everyone who wants to patrol (with my RCUseModStyle=true) can click on (hist) to
pull the history of a single article. For small scale wikis, the RCUseModStyle
view seems to fit better, for big scale, perhaps you are right. This is, why I
have the patch indeed configurable: Admins may switch the feature on or off.

It would be perhaps better to have this as a (third) USER PREFERENCE option,
like this:

User Preferences:

RC View:
1- Standard = Every recent change shown on a separate line (*)
2- Enhanced RC View = recent changes of a page are hidden per day (JavaScript
fold view) (*)
3- UseMod Style View = only one (the recent) change of a page is shown (**)

(*) already possible options now
(**) new as proposed herein

Tom
Comment 9 Brion Vibber 2004-10-26 01:47:15 UTC
I've already explained how the proposed mode would be significantly 
different from UseMod's RecentChanges view, while the enhanced 
recent changes view by default provides an almost identical view to 
UseMod's (with extra detail if you click the arrow).

If you'd like to improve the compatibility and bandwidth usage of the 
enhanced mode, please file that as a separate request.
Comment 10 T. Gries 2004-10-26 06:50:24 UTC
(In reply to comment #9)
> I've already explained how the proposed mode would be significantly
> different from UseMod's RecentChanges view,
UseMod shows .... ( 3 versions ) after the paeg title, indicating, that 3
versions are still kept in the database for retrieval on users' demand.

> while the enhanced recent changes view by default provides an almost identical
view to 
> UseMod's (with extra detail if you click the arrow).

It is not the same. It messes the screen up, because pages with many changes
appear on several days even in folded view. My bugreport aimed indeed more to
hide these (plenty) "changed pages appear every day when they were changed even
in folded enhanced view" lines.

I have nothing against - and I am in favour as already mentioned - in signalling
the number of versions available (as in UseMod), but I guess the superfluous
view of page changes in the past can be avoided. This is why I still propose to
implement "RCUseMod-Style (exactly)" as a THIRD option for users.
Comment 11 T. Gries 2004-10-26 07:04:17 UTC
(In reply to comment #9)
> If you'd like to improve the compatibility and bandwidth usage of the 
> enhanced mode, please file that as a separate request.

Yes, thanks for suggestion.
I filed this as http://bugzilla.wikipedia.org/show_bug.cgi?id=782 "Third user
option for Recent Changes View: UseMod-Style" taking your valuable comments into
consideration.

I did not declare "dependency" between the both bugzillas.

Comment 12 T. Gries 2004-10-30 08:50:57 UTC
http://meta.wikimedia.org/wiki/Email_notification_versions#Recent_Changes_view:_UseMod_style
shows a *screenshot* of the implementation of the alternative RC view in Enotif
versions > 1.32 .


The UseMod style can be globally disabled by an Admin setting in
DefaultSettings.php. If this is enabled, users get a third alternative on their
user preference page and can decide to haev RC views in "UseMod" style (to see
only the recent changed version including the standard (diff) and (hist) links)
or not. This feature can advantageously be combined with Enhanced RC view, as it
the suppresses the listing of older revisions than the recent changed one.
Comment 13 T. Gries 2004-10-30 08:52:17 UTC
Created attachment 116 [details]
screenshot of RC UseMod style view showing only the recent version

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


Navigation
Links