Last modified: 2010-05-15 15:37:46 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 782 - User option "show only the current revisions of pages" suppresses listing of all older revisions of pages in recent changes view
User option "show only the current revisions of pages" suppresses listing of ...
Product: MediaWiki
Classification: Unclassified
Special pages (Other open bugs)
All All
: Normal enhancement with 1 vote (vote)
: ---
Assigned To: T. Gries
: patch
Depends on:
Blocks: 1932
  Show dependency treegraph
Reported: 2004-10-26 07:01 UTC by T. Gries
Modified: 2010-05-15 15:37 UTC (History)
1 user (show)

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

missing codelets for the patch (4.46 KB, patch)
2005-01-04 20:37 UTC, T. Gries

Description T. Gries 2004-10-26 07:01:35 UTC
The other UseMod Wiki software (PERL script) comes with a RC view which shows
for any changed only the most recent changed version link followed by a
(hist=versions) link showing directly the *number* of available versions.

A similar proposal was launched as from which this bugzilla
differs only in the feature:

- fully UseMod compliant due to view of the *number* of available versions in
the page history.

The UseModStyle differs from enhanced recent changes view in that

- every changed page is appears only once
(the enhanced RC view lists - in folded view - changed pages at least once per
day, when it was changed)

I propose the above as a third user option for UseModStyle.

Alternatively, the third option could suppress listings of page titles for
changes on past days, so that only the first listed line bears information about
*all* available changes (number of versions, number of page editors for *all*
days in history).
Comment 1 Brion Vibber 2004-10-26 07:04:29 UTC
There is so little difference, I can't imagine the purpose of this.
Comment 2 T. Gries 2004-10-26 07:13:45 UTC
Sorry, please do me a favour and try it once.
The screen layout is much clearer, and faster.

The difference is explained in my report and fully took into account your
comments (that the NUMBER wasn't shown, as mentioned by you). Have you ever user
UseMod ? It is incredible faster in RC views. 

The other difference is already in 756: no more listings of older changes in
sections for past days (for a certain page), if that page was already listed on
a more recent day.

For test purposes, I recommend that you apply my tiny patch as listed in and measure the time of
getting the data. And the screen layout is much clearer ! Even when you have
"Enhanced RC View" enabled - because the patch skips the second (and so on)
older recent changes. I admit, that all skipped data should be then in the first
(folded) view, but this can be implemented as mentioned in this bugzilla.

Why exactly don't you want such a UseMod-Style view as a third alternative,
there are no more lurking.
Comment 3 T. Gries 2004-12-19 08:29:30 UTC
Brion, you have invested time to remove my code for RCUseModStyle, even when it
could be disabled fully by a "master" setting for the Sysop in
DefaultSettings.php and an accompanying user option (which is only shown, when
the Sysop setting allowed this).

However, I know of many users test installations who like that code and the
possibility to select one or the other view preference.

I deeply wish to re-request the implementation of RCUSeModSytle, as it gives
much clearer RC views:

   when only one (the last) change of a page is shown.

Admittedly, not everyone will like that, but think (please) of the other users,
who do.

In my opinion, there was not any impact on performance when the "master"
settings disabled that feature, because the only change was a tiny conditional
addition to the select statement - so no performance drawback. It seems to me,
that we both are of a diverging opinion, so I kindly ask you to talk about this
patch, which I pray to have, in Berlin.

It can be used with or without the enhanced RC view.
Comment 4 T. Gries 2004-12-19 23:14:43 UTC
Added a screenshot of RCUseModStyle view of Recent Changes (remember what it
does: it only shows the most recent change (one entry) of a page - any user has
an option to opt-out from this, so that s/he get the full view: any change of a

I personally do prefer th RCUseModStyle and will give convincing arguments (i.e.
"fight") to have this option in 1.5 . Let me know your opinion. I admit, that
any single change might need to be patrolled; but some more reluctant users do
not need to see any single change of a page. This is, where my proposed patch
helps, as it suppresses "older" changes than the recent one), Brion has already
said. that he do not see an advantage, but I am of a diverging opinion.

How does the community of developers deal with such a problem ?
Comment 5 T. Gries 2005-01-04 20:37:09 UTC
Created attachment 197 [details]
missing codelets for the patch


I upload here the diff (Diff between the current CVS as of 04.01.2005, 20:26
UTC) which reestablishes the UseModStyle View. I really would like to suggest
to have this in the CVS 1.5.

My patch makes it a "UPO" (user preference option) when a Sysop has decided to
allow UseModStyle View (switch $wgRCUseModStyle in DefaultSettings.php =
true;), so any user can opt-in or opt-out.

Later (to do):

I will modify it according to what we have discussed in Berlin (to show the
number of versions) OR to modify the enhanced recent changes view, so that all
changes of a certain page are mapped to the one (most recent change) entry.
Comment 6 T. Gries 2005-01-04 20:39:45 UTC
Remark: the texts are already (still) in Language.php (see rcusemodstyle and tog-rcusemod ). 
Comment 7 T. Gries 2005-02-03 02:12:33 UTC

please can you fix the missing things - see patch - to re-enable my
Pseudo-Usemod style for the recent changes view ?

As discussed with you in December in Berlin, this step of you would enable me to
resume my work towards the display of the real number of changes coming with the
one only entry of a changed page (in RC view).

At the moment, as you know, the enhanced RC view (w/ or w/o $wgUseModStyle=true)
still shows a changed page on every day when it was changed. Exactly this
problem needs to be overcome, so that all instances are put into the folded view
on the last recent change entry of a certain page, if a user opted for enhanced
RC view or UseMod-style.

For the other readers: with UseModStyle it is meant, that the wiki software
first creates and sends only the information about the (one) recent change of a
page, rather than sending all change information falling into the selected
interval (e.g. 500 changes in last 7 days). This saves transmission bandwidth;
users, who wish to patrol can still click onto (diff) and (hist) links to get
the missing data or simply to permanently opt-out from the UseMod-style ... ...
... Brion has stated in 2004 to be against this UseMod-style, but I am in favour
of having this and I programmed it as option (= Sysop option and user option in
preferences). A preview can be seen on screenshots on my [sic] pages. What else can I do than to ask it
again and again, this is a very difficult situation and I can only pray again to
let me fully implement this in CVS and THEN to see the developers' opinion.
Comment 8 Brion Vibber 2005-02-03 02:16:26 UTC
Tom, why don't you go ahead and make the fix to enhanced recent changes mode and post a patch for that? As I 
understood it, this was what we agreed to in December.
Comment 9 T. Gries 2005-02-03 02:38:56 UTC
(In reply to comment #8)
> Tom, why don't you go ahead and make the fix to enhanced recent changes mode
and post a patch for that? As I 
> understood it, this was what we agreed to in December.

Because I need your commitment to my idea, not a butchering of it and lengthy
discussions about a feature which can be disabled by sysop and user options. I
hardly saw a commitment of developers to my several hundreds of hours program
efforts, which makes me more and more reluctant to do anything more. (I am *not*
saying, that I resign)

Why don't you re-enable what I have programmed first, than fine-tuning is easy
business for me and everyone can help to improve the code again. This would show
me your commitment.
Comment 10 Brion Vibber 2005-02-03 03:27:53 UTC
What we discussed is a specific change to the behavior of enhanced recent changes, which is 
in no way dependent on the patch attached to this bug. This patch is for the old hack you 
submitted, which as you agreed during our discussion would be unnecessary if the agreed-
upon change to enhanced recent changes was made.
Comment 11 T. Gries 2005-02-03 07:40:48 UTC
(In reply to comment #10)
> What we discussed is a specific change to the behavior of enhanced recent
changes, which is 
> in no way dependent on the patch attached to this bug. This patch is for the
old hack you 
> submitted, which as you agreed during our discussion would be unnecessary if
the agreed-
> upon change to enhanced recent changes was made.

If there is a commitment lurking, I can barely see it.


so the only thing which you miss from my patch as attached is the display and
link to the number of available changes (of a certain page in RC view) in the
wiki history - am I right ?

Please can you confirm this to avoid an only potential misunderstanding.
Comment 12 Brion Vibber 2005-02-03 07:52:06 UTC
In Berlin you suggested, and I agreed, that the enhanced recent changes mode 
should sort all changes for a page under its most recent edit instead of splitting 
them across days. You represented that this would be a sufficient change for 
your requirements, and I agreed it would be acceptable and would be accepted.

This patch does not cause enhanced recent changes display to sort all changes 
to a given page under its most recent change instead of splitting them across 
days. This patch just adds another user option (to a sea of user options which 
should not be increased lightly) which ignores everything but the most recent 

The patch attached to this bug will not help to perform the change that you 
suggested and we agreed on, so I don't see why you would ask now for it to be 
Comment 13 T. Gries 2005-04-20 06:18:02 UTC
I renamed my bugzilla title to better reflect the current implementation of it
in Enotif 3.x for MediaWiki REL1_4 (1.4.1/pre-1.4.2) as published .

The function can be configured by sysops, i.e.totally disabled or enabled. 

In the latter case, the user gets a new option in user preferences and can
decide at her discretion to enable or disable the 

- suppressed view:
  to list only the current revision of any changed page, or 

- standard view (standard):
  to list every single page revision in recent changes view.
Comment 14 T. Gries 2005-04-27 23:27:01 UTC
Oops, here we have a real clash between Brion and me.

It is *implemented* as a user option(!) in ENotif/EConfirm v3.16, see and sysops can fully disable it.

So Brion: be relaxed and make a concession

I cannot say, whether this will be implemented in public release version or not,
but I fully support it.
Comment 15 T. Gries 2010-02-13 21:25:06 UTC
Solution for MediaWiki 1.15+ using a hook:

// see
function onlyRecentRecentChanges( &$conds, &$tables, &$join_conds, $opts, &$query_options = array() ) {
	$tables[] = 'page';
	$conds[] = 'rc_this_oldid=page_latest';
        return true;
$wgHooks['SpecialRecentChangesQuery'][] = 'onlyRecentRecentChanges';

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