Last modified: 2010-05-15 15:37:46 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 http://bugzilla.wikipedia.org/show_bug.cgi?id=756 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).
There is so little difference, I can't imagine the purpose of this.
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 http://bugzilla.wikipedia.org/show_bug.cgi?id=756 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.
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.
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 page). 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 ?
Created attachment 197 [details] missing codelets for the patch Brion, 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.
Remark: the texts are already (still) in Language.php (see rcusemodstyle and tog-rcusemod ).
Brion: 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 http://meta.wikipedia.org/Enotif [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.
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.
(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.
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.
(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. Brion: 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. Tom
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 edit. 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 committed.
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 http://bugzilla.wikipedia.org/show_bug.cgi?id=454 . 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.
Oops, here we have a real clash between Brion and me. It is *implemented* as a user option(!) in ENotif/EConfirm v3.16, see http://bugzilla.wikipedia.org/show_bug.cgi?id=454 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.
Solution for MediaWiki 1.15+ using a hook: // see http://www.mediawiki.org/wiki/Manual:Hooks/SpecialRecentChangesQuery function onlyRecentRecentChanges( &$conds, &$tables, &$join_conds, $opts, &$query_options = array() ) { $tables[] = 'page'; $conds[] = 'rc_this_oldid=page_latest'; return true; } $wgHooks['SpecialRecentChangesQuery'][] = 'onlyRecentRecentChanges';
