Last modified: 2013-09-19 13:16:14 UTC
Problem: each new user signing up creates an entry in recentchanges. This might be hardly noticeable on larger wikis, but on smaller wikis this quickly becomes the main content of recentchanges, which thus becomes useless to monitor anymore due to distraction. In fact it might invite vandalism, "let's create fun names so everybody can see." We want them logged, but not also in recentchanges. Solution: an simple array in DefaultSettings.php, containing what events that should be added to recentchanges. No need to install extensions. New user creation would still be 'on' in it by default, but at least the administrator could now easily turn it off if desired... along with any other events he no longer wished to show up in recentchanges! This array could also be used in maintenance/rebuildrecentchanges.php eliminating the need for the hard-to-maintain list currently there. Hmmm, it seems this array be an initially empty list of event types to exclude. Assign this bug to me if you think it is worthwhile, and I'll come up with a patch, if nobody better skilled would rather. One worry is "hey, your wiki is broken, new users don't show up". Perhaps at the bottom of recentchanges there could be "Only ..., ..., ..., events are listed. See the [[Special:Log]] for other information".
Indeed, http://techblog.wikimedia.org/2009/04/planning-to-tighten-torblock-restrictions/ mentions "a rash of abuse ...in the form of account creations with abusive names". There would be little thrill if they didn't show up in recentchanges.
Note that this is already done for patrol log entries, so there is precedent (although 'patrol' is just hardcoded right now IIRC). There's also a boolean parameter to the LogPage constructor (IIRC) that suppresses creation of an RC entry.
The solution should be to add an option for RecentChanges to hide account creations, hide blocks... Hardcoding 'things that are distracting for small wikis' to hide them is too subjective and won't scale.
What feeds and vandalism/activity monitoring bots and software would be broken or impaired by this, due to relying on RC feed to spot new usernames etc?
Nothing need be broken, just make the current behavior the default in the new array there in DefaultSettings.php. We small wiki owners would now have a tool to move the focus of our wikis back to content, not personal networking, like it used to be before recentchanges suddenly started advertising new account creation (it seems, or my wiki got popular?) With this array, no more hardwiring need be done in all the various places that access the recentchanges table, including rebuildrecentchanges.php. It's darn frightening to see those new accounts pop up one after another, with the only non-hack solutions available being 1. Turn off new account creation. 2. Remove recent changes from the sidebar.
(In reply to comment #4) > What feeds and vandalism/activity monitoring bots and software would be broken > or impaired by this, due to relying on RC feed to spot new usernames etc? > FWIW, SULWatcher relies on CentralAuth's IRC feed, not RecentChanges, so it'd be unaffected. (In reply to comment #1) > Indeed, > http://techblog.wikimedia.org/2009/04/planning-to-tighten-torblock-restrictions/ > mentions > "a rash of abuse ...in the form of account creations with abusive names". > > There would be little thrill if they didn't show up in recentchanges. > If we're talking about the same thing, accounts are generally hidden within a minute - there would be no significant change in the "trill level". That said, there are other vandals, and it's worth considering for other reasons as well.
Well imagine a wiki where no pages usually change much more than a bimonthly meeting announcement. There recentchanges just fill up with the kiddies to the point where you can forget about finding the announcement, nor anybody coming to the meetings. No need to clamp off new accounts. Just make them not have advertising value, just as they don't on most BBSs, forums, UNIX, you name it.
(In reply to comment #7) > No need to clamp off new accounts. Just make them not have advertising > value, just as they don't on most BBSs, forums, UNIX, you name it. > Call me when we're a BBS, forum, or UNIX. Now, a way to hide it from view might be useful yes.
Some findings when looking for a workaround to showing new account creation: $wgNewUserLog=false will stop new entries from being added, but won't clean up the present ones. And one doesn't want to disable logging of new users just to keep them out of RC. So one turns to $wgLogRestrictions['newusers']='editinterface' just to keep them out of RC, but this does not clean up the present ones, nor does rebuildrecentchanges.php (Bug #18441) help. Probably must resort to a hook...
(In reply to comment #2) > Note that this is already done for patrol log entries, so there is precedent > (although 'patrol' is just hardcoded right now IIRC). There's also a boolean > parameter to the LogPage constructor (IIRC) that suppresses creation of an RC > entry. > I don't think that it is hardcoded, though I can't find the commit presently. IIRC, Aaron added that, so I've CCed him.
By the way, import a new page with Special:Import, In Recentchanges one only sees (Import log); 12:06 . . WikiSysop (Talk | contribs | block) imported UUU by file upload (1個修訂) After using rebuildrecentchanges.php one sees two entries, (Import log); 12:06 . . WikiSysop (Talk | contribs | block) imported UUU by file upload (1個修訂) (diff) (hist) . . m UUU; 12:06 . . (0) . . WikiSysop (Talk | contribs | block) (1個修訂) [rollback] Now set $wgLogRestrictions['import']='editinterface'; and run rebuildrecentchanges.php again. Now one only sees (diff) (hist) . . m UUU; 12:06 . . (0) . . WikiSysop (Talk | contribs | block) (1個修訂) [rollback] There is too many combinations to test. My head is spinning. All I can say is that regular and rebuilding RC should go thru the same function...
Today at r49455, with $wgLogRestrictions['import']='editinterface'; I imported some revisions to some existing pages. Nothing changed at all in RecentChanges. So I ran rebuildrecentchanges.php. I got the familiar double entries: each with one for the revision, and one minor one for the import. As this is tolerable (the user can exclude seeing minor edits) I'll no longer use $wgLogRestrictions['import']='editinterface'; as it makes RecentChanges act differently than rebuildrecentchanges (BUG), and wipes out both lines in RecentChanges until one runs rebuildrecentchanges.
OK, one can get grudgingly by with e.g., $wgLogRestrictions['newusers']='editinterface' to keep things also out of recentchanges. however, rebuildrecentchanges still needs to act the same as plain recentchanges. Hence I'm changing the Summary.
This issue also affects any extensions which build on the LogPage class. For example, http://www.mediawiki.org/wiki/Extension:UserLoginLog instantiates a child of LogPage with parameters ( * , false ). It succeeds in avoiding the recentchanges table when it initially adds items to the logging table. After you run rebuildrecentchanges, all those items are added to the log. In this instance, $wgLogRestrictions['userlogin']='read' would I guess work just as well. In terms of a fix, I'm having trouble figuring out how to fix this without changing database table layouts (i.e. adding a true/false field for rc/no-rc). It might also be possible if you cached new log entries to be added to RC and then have rebuildRC read the cache into the DB. I have no idea how you would cache that information without, again, database rewrite. -Ed
Rephrasing bug summary. Especially annoying for patrol edits. I just rebuilt recentchanges for a wiki I maintain and it added 1000s of patrol events to Special:RecentChanges that don't belong there. Especially silly because patrol is to work and reduce unpatrolled recent changes, doesn't make sene that such an event results in an entry being added.
Even autopatrol events are included, which means every single edit done by a user who has the autopatrol right will get 2 entries in recentchanges after this script is ran (one for the edit, one for the autopatrol).
It looks like this is your culprit: <code> // Some logs don't go in RC. This should check for that $basicRCLogs = array_diff( $wgLogTypes, array_keys( $wgLogRestrictions ) ); </code> And, here's the definition of $wgLogRestrictions from DefaultSettings.php: $wgLogRestrictions = array( 'suppress' => 'suppressionlog' ); Maybe the code should be using this array instead? $wgFilterLogTypes = array( 'patrol' => true );
