Extension talk:UserMerge/LQT Archive 1

Instructions
For $wgUserMergeUnmergeable comment, don't you mean "Optional, prevents user_id 1 from being merged"?

Svanslyck 21:00, 9 February 2008 (UTC)
 * Well... Optional as in you don't have to set it for the extension to work. By default, user_id 1 can't be merged because $wgUserMergeUnmergable is initalized to array(1).  It's optional meaning you can change it's behavior if you want, but don't need to.  This was added as Simetrical pointed out that user_id 1 isn't always the admin/root user as MW has no concept of a 'root' user_id.  Tim Laqua talk 17:43, 10 February 2008 (UTC)

You cannot delete or merge from yourself!
What happened? I'm logged in as sysop and trying to merge two other users, deleting one of them. Svanslyck 21:05, 9 February 2008 (UTC)
 * Fixed in v1.4.2, r30803 Tim Laqua talk 17:39, 10 February 2008 (UTC)

No Logging?
Shouldn't there be log entries for merge&delete? --NoLuck 22:46, 13 November 2007 (UTC)
 * Dunno, should there be? I never really planned for it to be used frequently enough - but considering that one should be able to rebuild an entire system using Logs - if there's a User creation log, there should most definately be a user deletion log.  I'll take a look at how the User Creation logs are being done.
 * well, there doesn't seem to be a user creation log - maybe no real need for that as this is a pure constructive act done by the concerned person himself ... however, after a user merge/deletion it could be good to know when that happened and who enacted that function... Extension:Renameuser is using a "user rename" log for its own purposes - so I guess you're not restricted on the standard log entries. Thx for consideration btw :) --NoLuck 21:02, 19 November 2007 (UTC)
 * Yeah, similar f/ the User Creation log - there is one, but it's part of an extension. Still, I'll look in to it.  ;-)  Maybe even implement if it doesn't give me a headache.
 * Ok, v1.2 (r27730) now has a User Merge log. ;-)
 * cool, thx! :-) --NoLuck 16:23, 24 November 2007 (UTC)

User Pages
Would like to see this also deleting the User Page and User Discussion page for the deleted user.

Apart from that, works a treat - thanks for providing this.

BrillyuntWebby 18:20, 16 November 2007 (UTC)
 * What should it do in the case of a Merge? Append to the new user?  Or just flat out, always delete the old user's page?  Or maybe a checkbox?  But I agree, it should do *something* with the old user's page... but if you don't delete it... and you don't wanna append it... where should it go?
 * I'd go for having them deleted anyway with the option (checkbox) to append the content to the new users User and Discussion page. Wolverine 15:16, 9 January 2008 (UTC)
 * I would have it create sub-pages for the user and let the user decide what to do with them.. Simply prepend a link to the sub-page on the main page.. So, if you are merging UserA to UserB --- Create User:UserB/UserA & User_talk:UserB/UserA. Prepend a link to User:UserB/UserA on User:UserB & User_talk:UserB/UserA on User_talk:UserB. -- Technical 13 (talk) 14:39, 18 April 2012 (UTC)

Statistics
When deleting the old user the statistics counter (ss_users in table site_stats) remains unchanged. So Special:Statistics shows more registered users than really exist/are listed by Special:Listusers. I think it should be possible to decrement the value in the database when deleting an user. I fixed this manually in our wiki and so far it didn't seem to have side-effects (i.e. when a new user registers). Wolverine 15:20, 9 January 2008 (UTC)
 * good point - i'll decrement that in the next release. Tim Laqua talk 16:17, 10 January 2008 (UTC)
 * great,thx! :-) The extension was already quite useful against "I forgot my account, ah ... I just create another one" users. ;-) With that, and the above optional merge of User and Discussion page it becomes complete (for me). So it's just one action and no further manual work neccessary. Nice! :-) Wolverine 08:57, 11 January 2008 (UTC)
 * Recalucation of ss_users and ss_admins added in 1.3.2, r30181. Tim Laqua talk 03:55, 27 January 2008 (UTC)

Database
When i used the stable version of this extension on my 1.11.0 fresh wiki, i noticed it leaves residues of the removed users in the database, in places like searchindex and recentchanges (and many others). Shouldn't this be fixed?
 * I'll take a look - The true intent of the extension is to allow removal of users while maintaining the referential ingegrity of the database. Where exactly did you notice fragments?  Tim Laqua talk 12:20, 18 January 2008 (UTC)

MediaWiki 1.9.0
I'm running MediaWiki 1.9.0 and I'd like to install the User Merge extension. Is it definitely incompatible with 1.9 or has it simply never been tested? If I tried it, could it mess up my database?--Lorikeet 07:05, 24 January 2008 (UTC)
 * It was originally developed on 1.9.3 - however the curennt Special Page implementation may not be backwards compatible w/ the 1.9.3 core. If you can install it and view the special page, you shouldn't encounter any problems - but as usual, use at your own risk - I haven't tested the current revison on 1.9.3.  Tim Laqua talk 03:22, 27 January 2008 (UTC)

MediaWiki 1.10.2
On the Extension page it says 1.10+ however on 1.10.2 is spits out "Call to undefined function wfLoadExtensionMessages". Is this function 1.11+ only? If no, provide a solution, if yes correct the extension page to say 1.11+
 * Changed, thanks. Tim Laqua talk 23:51, 22 February 2008 (UTC)

Praise
Oh, thank you for this extention! I'm new to MediaWiki and I made some user accounts that I really didn't want (and made page edits with them, thus permeating the database!) ... and I was pulling my hair out trying to clean up behind myself. It's important that my user list be correct. This ext. did the trick! THANK YOU! -- toff@paleravens.com

"Undefined variable" error
I'm trying to get this extension working with MW 1.11.0. When I open Special:UserMerge page I'm getting this errors on the top of page:

Notice: Undefined variable: olduser_text in [strip]/extensions/UserMerge/UserMerge_body.php on line 89 Notice: Undefined variable: newuser_text in [strip]/extensions/UserMerge/UserMerge_body.php on line 93 Notice: Undefined variable: deleteUserCheck in [strip]/extensions/UserMerge/UserMerge_body.php on line 97 Notice: Undefined variable: validNewUser in [strip]/extensions/UserMerge/UserMerge_body.php on line 107


 * Fixed in r30180. Tim Laqua talk 03:32, 27 January 2008 (UTC)

Select the user instead of writing it?
Hi, Great work with this extension. I just wonder how can it be done so that when you use this extension you select the old username from a list instead of writting it in the box? And for using multiple selection of old users? The user list i'll manage won't exceed the 50 or 60 users, that's why i ask. Also... can you delete your own username being an admin using this extension? or has to be someone else the one who does it? Thanks -Juanan 10:53, 6 February 2008 (UTC)
 * Oh yes, you can delete yourself - however, I believe the next time you try to view a MW page - your session should expire as the user no longer exists. As far as selecting multiple users - It's certainly possible to make a multiple user selection dialog for the "old username" and make it support multiple entries - though I could almost see that being a separate Special page rather than an addition to the current one, indended for mass user deletion.  Maybe a feature for the next version - do you forsee needing to delete large numbers of users?  I noticed you mentioned integration of a CAS - what are you using and what are you trying to get User Merge and Delete to do?  I personally use LDAP Authentication against AD for a few Wikis at a university and I use the extension to clean up auto-created accounts for users that don't have read or write access (the simple act of logging in for most CAS implementations causes a MediaWiki account to be created).  Tim Laqua talk 14:46, 6 February 2008 (UTC)


 * Well it shouldn't let a user to delete itself, should it? Or at least it should issue a warning so that you accidentally don't delete yourself... also do you think it would be hard to implement a button that loads a list of users from the database and lets you select he ones that will be losing their contributuions (and probably ending deleted) and then merge them against one single user? About CAS, yes, I use it to autocreate/login users according to certain user type privileges and they won't be able to login when those privileges don't exist. (For example they don't study the subject this wiki is for). -Juanan 19:59, 6 February 2008 (UTC)


 * Not deleting yourself should be simple enough to check for (and it's debatable - I don't see any real harm in stopping it from deleting you). As far as the selection list - it wouldn't be hard so much as tedious - modal dialogs aren't very standardized between browsers (which is why scripts like ThickBox and Submodal exist) - I'm also not a fan of postbacks for trivial information.  I'll put some thought in to it - my main concern is that dropdowns and multiple selection options are not realistic in large wikis - really once the userlist gets larger than 50 users, the lists are out of control.  Tim Laqua talk 20:56, 6 February 2008 (UTC)
 * Blocking of self deletion implemented in v1.4, r30677. Tim Laqua talk 18:40, 7 February 2008 (UTC)


 * Anything new about the mass merge and delete feature? There have registered a lot of spam users in my wiki in the last half year and I'd like to merge them to a single user. --87.176.116.214 19:59, 12 November 2010 (UTC)
 * Ditto. I would like to see this developed if possible. I am on a wiki that 700 or so spam bots are registered to and am not looking forward to manually deleting them one by one. --(keeblerx)67.255.13.177 07:03, 19 April 2011 (UTC)
 * Ditto, ditto. I have the exact same problem and would really like to see this feature. Great work! --(cntrstrk14)
 * Me too (Tiggerjay)
 * Me too, thanks for the great piece! --(uwe_a)

Minor problem with international languages pack
I followed all the steps installing this extension. However I found that when changed the user's language at prefercences, the Name for the extension that appears on The special restricted pages changes but not the buttons and messages of this extension, even though it works, it doesn't seem to show the correct language. I downloaded the last version up to date. -Juanan 11:40, 7 February 2008 (UTC)
 * Fixed in v1.4, r30677. Tim Laqua talk 18:40, 7 February 2008 (UTC)

Call to undefined function wfLoadExtensionMessage
I get the following error when trying to use this extension: Fatal error: Call to undefined function wfLoadExtensionMessage in extensions\UserMerge\UserMerge.php on line 32 Using mediawiki 1.11.1 -Z
 * Line 32 is "wfLoadExtensionMessages('UserMerge');" - mw 1.11+ should support that function. Make sure you have the latest revision of this extension and verify that you are running MW 1.11+  Tim Laqua talk 17:36, 12 February 2008 (UTC)
 * Is there any way to get your extension working with MediaWiki version 1.10?
 * Yes, download an old revision like: http://svn.wikimedia.org/viewvc/mediawiki/trunk/extensions/UserMerge/?pathrev=27730
 * I have MediaWiki 1.6.10 and the SVN checkout of UserMerge, and I get this wfLoadExtensionMessages error too. 144.171.146.113 22:58, 20 February 2008 (UTC)
 * It doesn't work on 1.6.10 - I don't think it ever did or ever will. Tim Laqua talk 21:07, 21 February 2008 (UTC)

A simple question about the default used when "nonewuser"
Hi there, dear Tim. You are doing a wonderful work with this extension - wich I'm using to create a mod to delete all the users from the "student" type at user_groups table - In this last change you seem to have changed the behaviour of the newuser used when it's void. The version from before used the username with the id 1 (WikiSysop) and this newer version uses the username with id 0 (Anonymous). Why this change? -Juanan 23:05, 15 February 2008 (UTC)
 * Excellent question! Because a few other developers disagreed pretty adamently with merging users to "ID 1" as id 1 doesn't actually mean anything to MediaWiki.  In actuality user_id 1 could be a normal user!  The only time that user_id 1 is indeed the "admin" user is following a 100% default install, with no goofy merging or migrating going on.  Well, we don't like to assume around here.  So the merge to Anonymous is now allowed and enabled by default.  ;-) Tim Laqua talk 21:03, 21 February 2008 (UTC)

Newbie hack
I gotta echo Juanan's call above: "Select the user instead of writing it?" -- that would be handy!

In the absence of such a drop-down list, I added the following clumsy code to my installation of this awesome extention.

I did this because and The hack (obviously?) starts not far below the recognizable line "//NO POST data found" and stops at the line "<form id='usermergeform' ..."
 * First hack: I believe I will always want to merge-and-delete no-longer-wanted accounts into a user that I set up for the purpose, named (DeletedUser), so I prefilled the NewUserMergeTo with that named, and pre-CHECKED the DeleteUserbox ... note you have to have the user account (DeletedUser) already created! or you'd get an error(duh).
 * Second hack: having a lazy brain, I find it difficult to remember the username for the 2.5 seconds it takes me to click over to the UserMergeAndDelete page, so I stuck an iFrame into the page, sourced as my Special:Listusers URL, so I will always have a list of users handy on the page.

It's not pretty, but it helps. Thought I'd share, anyway. And I renew my "Praise" comment (from above). Cheers! --Töff 01:03, 16 February 2008 (UTC) //NO POST data found }               $action = $wgTitle->escapeLocalUrl; $token = $wgUser->editToken;

// ====================================== PaleRavens hack $newuser_text = "(DeletedUser)"; $deleteUserCheck = "CHECKED "; // ====================================== /hack

$wgOut->addHTML( "




 * Update: the hack actually generates a couple of harmless errors. They only show up if error reporting is turned on. The functionality seems to be still 100%.--Töff 04:56, 18 February 2008 (UTC)
 * Interesting... I'll see if I can get to this the first week of March.  Tim Laqua talk 20:59, 21 February 2008 (UTC)
 * Cool, an official version would be awesome. --Töff 01:51, 14 March 2008 (UTC)
 * I was curious about this, so I tried my own hack on this extension and it seems to work like a charm:

//NO POST data found }   // ============ Begin Verifex Hack $dbr = wfGetDB( DB_SLAVE ); $results = $dbr->select(     'user',      array( 'user_name' ),      '',      __METHOD__,      array('ORDER BY' => 'user_name ASC')        ); while( $x = $dbr->fetchObject ( $results ) ) { $userlist[] = get_object_vars($x); }   $builtSelect = ''; foreach ($userlist as $user) { $builtSelect.=' '.$user['user_name'].' '; }   // ============ End Verifex Hack $wgOut->addHTML(			Xml::openElement( 'form', array( 'method' => 'post', 'action' => $this->getTitle->getLocalUrl, 'id' => 'usermergeform' ) ) .			Xml::fieldset( wfMsg( 'usermerge-fieldset' ) ) .			Xml::openElement( 'table', array( 'id' => 'mw-usermerge-table' ) ) .			" 				" .					Xml::label( wfMsg( 'usermerge-olduser' ), 'olduser' ) .				" 				" .				 // ============ Begin Verifex Hack					Xml::input( 'olduser', 20, $olduser_text, array( 'id' => 'olduser', 'type' => 'text', 'tabindex' => '1', 'onFocus' => "document.getElementById('olduser').select;" ) ) . ' ' .					Xml::openElement('select', array('id' => 'olduser-list', 'onChange' =>"document.getElementById('olduser').value = document.getElementById('olduser-list').options[document.getElementById('olduser-list').selectedIndex].text" )).					$builtSelect.   					Xml::closeElement('select'). // ============ End Verifex Hack " 				". Xml::label( wfMsg( 'usermerge-newuser' ), 'newuser' ). " 				". // ============ Begin Verifex Hack Xml::input( 'newuser', 20, $newuser_text, array( 'id' => 'newuser', 'type' => 'text', 'tabindex' => '2', 'onFocus' => "document.getElementById('newuser').select;" ) ). Xml::openElement('select', array('id' => 'newuser-list', 'onChange' =>"document.getElementById('newuser').value = document.getElementById('newuser-list').options[document.getElementById('newuser-list').selectedIndex].text" )). $builtSelect. Xml::closeElement('select'). // ============ End Verifex Hack " --Verifex 19:03, 22 April 2011 (UTC)

Complete merge between user accounts
I was hoping that this extension could actually change all 'User:' references in the database to the new user. I really don't want any traces of the old user hanging around the database. Could this be added as an extra option? --AlissaHarrison 10:29, 17 February 2008 (UTC)
 * I thought that's what it does now. --Töff 04:54, 18 February 2008 (UTC)
 * Me too. Tim Laqua talk 20:57, 21 February 2008 (UTC)
 * Oh, are you talking about namespaces? Like the old User:Username articles exist in the database?  Tim Laqua talk 00:02, 23 February 2008 (UTC)
 * When he says all references to the user, I think he speaks about two places, which the extension does not yet consider:
 * The first one being log messages, which include the name and link to the user page. And the second being all wiki pages, on which a link to a user page might be placed as well (e.g. in signatures on talk pages, but basically just anywhere). --88.130.78.127 01:42, 29 January 2012 (UTC)
 * References to the old user name in articles are perhaps better fixed using Extension:Replace Text. — Kwi 14:33, 7 February 2012 (UTC)

Partial Logging
Hello again Tim. I have completely succeeded into creating the mass "students" deletion using your merge & delete (will post soon), but I noticed there's something that isn't working at this version yet. The logging! Since there appear only two lines in the all logs option, and none under the "User merge and delete" bar.

At the usermerge.php the two lines of code are
 * $wgLogActions['usermerge/mergeuser'] 	= 'usermerge-success-log';
 * $wgLogActions['usermerge/deleteuser']	= 'usermerge-userdeleted-log';

Assuming they refer to the internationalisation code.
 * 'usermerge-success-log' 	=> 'User $2 ($3) merged to $4 ($5)',
 * 'usermerge-userdeleted-log' 	=> 'Deleted user: $2 ($3)',

At the usermerge_body.php the two calls to the logging are:
 * In the merge function
 * $log = new LogPage( 'usermerge' );
 * $log->addEntry( 'mergeuser', $wgUser->getUserPage,'',array($olduser_text,$olduserID,$newuser_text,$newuserID) );
 * In the delete function
 * $log = new LogPage( 'usermerge' );
 * $log->addEntry( 'deleteuser', $wgUser->getUserPage,'',array($olduser_text,$olduserID) );

The thing is that I believe either the two lines on the UserMerge.php or the call to the log->adEntry... is not done correctly. Could it be also that the parsing at the internationalisation array is not done correctly? Since there only appear the two lines of the $log->addEntry in the Special:logs like this  => 16:02, 22 February 2008 Pau Fonseca (Talk | contribs | block) deleteuser ? and also 16:02, 22 February 2008 Pau Fonseca (Talk | contribs | block) mergeuser ?(and they only appear under the (all logs) option.

Man, I really seem to be pointing the errors all the time but it's not my intention to be annoying, besides you understand the insides of the mediawiki far better than I will ever know. --Juanan 16:49, 22 February 2008 (UTC)
 * Can't confirm. I checked on a current 1.12alpha wiki and a 1.11.1 wiki and am unable to reproduce.  It's most likely something that you changed in your implementation.

14:11, 6 February 2008 [snip] (Talk | contribs | block) User [snip] (130) merged to [snip] (1) ? 14:10, 6 February 2008 [snip] (Talk | contribs | block) Deleted user: [snip] (149) ? 14:10, 6 February 2008 [snip] (Talk | contribs | block) User [snip] (149) merged to [snip] (42) ?
 * All of my logs look fine (both the user merge log and listings under all logs). Tim Laqua talk 23:49, 22 February 2008 (UTC)
 * I see where the error was. i had the logType like this -> $wgLogTypes[]                 		= 'studentdelete';   and it seems that the database type for the variable log_type is a varbinary(10) so it saved only "studentdel" and never showed at logs. Problem solved thanks!

But now i have another question (i havent checked this exhaustively though). I noticed that when you create usernames a lot and delete them also, it gives the new users ids that were given before. For example an user has UID 10, i create 2 more users, so they use UID 11 and 12. But when I delete some of the middle.. for example the UID 10. is there any chance that when creating new users it tries to give the username a UID of 10 ? since its an incremental variable won't this mean that sometime later it will try to give the next UID the value 11, even though it's ocupied? (there goes my brick)--Juanan 20:10, 25 February 2008 (UTC)
 * No, that's not how it works:

mysql> desc user; +--+-+--+-+-++ +--+-+--+-+-++ +--+-+--+-+-++ 15 rows in set (0.01 sec)
 * Field                   | Type            | Null | Key | Default | Extra          |
 * user_id                 | int(5) unsigned | NO   | PRI | NULL    | auto_increment |
 * user_name               | varchar(255)    | NO   | UNI |         |                |
 * user_real_name          | varchar(255)    | NO   |     |         |                |
 * user_password           | tinyblob        | NO   |     |         |                |
 * user_newpassword        | tinyblob        | NO   |     |         |                |
 * user_email              | tinytext        | NO   |     |         |                |
 * user_options            | blob            | NO   |     |         |                |
 * user_touched            | char(14)        | NO   |     |         |                |
 * user_token              | char(32)        | NO   |     |         |                |
 * user_email_authenticated | char(14)       | YES  |     | NULL    |                |
 * user_email_token        | char(32)        | YES  | MUL | NULL    |                |
 * user_email_token_expires | char(14)       | YES  |     | NULL    |                |
 * user_registration       | char(14)        | YES  |     | NULL    |                |
 * user_newpass_time       | char(14)        | YES  |     | NULL    |                |
 * user_editcount          | int(11)         | YES  |     | NULL    |                |
 * auto_increment variables don't crash in to themselves - as a matter of fact, they don't re-use IDs once they have been issued - ever. You can technically reset the auto_increment counter, but there is virtually no reason to do so.  It'll just keep counting up and up until it runs out of space.  Then i'm honestly not sure what happens...  I would imagine it'd throw some sort of error - but it won't ever loop around.  If you were running out of space for IDs (i.e. you exceeded the size of field as defined) - you would most likely just alter the field to be larger.


 * Also, regarding your solution - please don't post it on the pages for this extension - post a fork extension or post it in a subpage of your user account. The reason for this is because I will not support the fork - so if you post it, you need to either stipulate that you are posting as is or you need to support it. Tim Laqua talk 22:29, 25 February 2008 (UTC)
 * http://dev.mysql.com/doc/refman/5.0/en/example-auto-increment.html further info - and a particular condition where an ID will be reused (if the highest value in a group is deleted) Tim Laqua talk 12:39, 26 February 2008 (UTC)

After deleting an user some logs remain
Hi there Tim, I noticed today that when you delete an username using your extension it doesn't delete some logs, so far ive just detected this on the permission changes logs for the user. This can be shown when you create an user with the same username, it shows the previous user permission changes logs. By the way, have you tried the extension with the last version 1.12? It seems that the parser has suffered dramatic changes. We'll see how this affects the other extensions. -Juanan 15:27, 26 March 2008 (UTC)
 * Interesting, I never really considered that people would re-create deleted users - I'll look in to clearing out the log entries next time I get a chance. I haven't tried specifically with the released 1.12 branch, but I do actively test on the SVN trunk (1.13alpha now).  Have you noticed any oddities?  The parser did indeed dramatically change, but I don't think it will effect this extension in particular.  Tim Laqua talk 17:09, 26 March 2008 (UTC)
 * I looked in to the logs more - logging.log_user is the user_id of the user who performed the logged action. I already merge that field - so what exactly are you referring to?  The text in the log comment? Tim Laqua talk 17:25, 26 March 2008 (UTC)
 * When i create the user Test3 (for example) and then go to User Rights Management I can see previous user changes that have relation to this user: For example: 10:49, 19 March 2008 Pau Fonseca (Talk | contribs | block) changed group membership for Usuari:Test3 from student to student, banned ?. I don't think it has to do with the user group they belong to (since it's a custom group) and it does not make sense that there is actual information (in a log ) about a user who has been deleted (well it's debatable too to keep the information on a log or not about this when the user has already been deleted :) ) . Also a bit of offtopic but do you know where to find a mediawiki databse schema updated (ver. 1.11 or 1.12)--Juanan 19:06, 26 March 2008 (UTC)
 * Eh, it's a matter of parsing out the comment text to weed out those references. I do have qualms about the fact that the link to the user page is embeded in those messages - but technically, it doesn't break referrential integrity, so I don't see any problems with it.  Not to mention that those logged actions did indeed occur - there's just more to the story... which is in a different log.  ;-)  Leaving it in lets the logs tell the story of the wiki - which is the goal.  As far as the schema, look at maintenance/tables.sql in whatever wiki version you need.  You won't always see hard FK constraints, but it's pretty self explanitory.  Also see Database, which hasn't been updated for 1.12 yet.  Tim Laqua talk 22:21, 26 March 2008 (UTC)

Another question
Hello Tim, I've noticed some interesting fact. When you do delete a user it doesn't completely delete the user_talk references. In mergeuser function you do this -> $dbw->delete( 'user_newtalk', array( 'user_ip' => $olduserID ));. But shouldn't you do this also in the delete function $dbw->delete( 'user_newtalk', array( 'user_id' => $olduserID ));. What do you think?--Juanan 17:32, 17 April 2008 (UTC)
 * Whoops, good catch. Not in addition, but instead of - looks like a typo, it always should have been deleting on user_id matches.  Fixed in v1.9.1, r33499. Tim Laqua talk 18:10, 17 April 2008 (UTC)

How to merge and delete a large list of users
Here's some code I used to merge and delete about 400 users. This was done under Windows because it's the OS I happened to be on at the time. This would be simpler directly under bash. This syntax is DOS/Batch not bash.

First I went to the "User List" page and copy and pasted the list of users into a text file called "users.txt". I removed the users I wanted to keep.

Next I created a user to merge all other users into, I called it "Merge-delete". I did this through the normal mediawiki web UI.

Next I logged in to the wiki from the command line, generating the authentication cookies and determining the edit token


 * ADMIN is your user account that can use the Merge and Delete extension
 * ADMINPASSWORD is the password for that user

d:\tools\curl\curl --location --cookie-jar cookie_jar.txt --cookie cookie_jar.txt -d wpName=ADMIN -d wpPassword=ADMINPASSWORD -d wpRemember=1 -d wpLoginattempt="Log in" http://www.example.com/wiki/index.php?title=Special:Userlogin^&action=submitlogin^&type=login

Next go to the UserMerge page to get the edit token

d:\tools\curl\curl --cookie-jar cookie_jar.txt --cookie cookie_jar.txt http://www.example.com/wiki/index.php?title=Special:Userlogin | find "token"

Next take this edit token and urlencode it (you can use a urlencoder out on the web if you need). This results in an edit token looking like "b817be56d8d14b680e01f114d198996a%2B%5C"

Finally put it all together into a loop that calls the UserMerge page and merges and deletes each user

for /f "tokens=*" %A IN (users.txt) DO d:\tools\curl\curl --cookie-jar cookie_jar.txt --cookie cookie_jar.txt -d olduser=%A -d newuser=Merge-delete -d deleteuser=on -d submit=Merge+user -d token=b817be56d8d14b680e01f114d198996a%2B%5C http://www.example.com/wiki/index.php/Special:UserMerge | find "to Merge-delete"

Careful not to Merge the "Merege-delete" user into the "Merge-delete" user like I did. =)

Cleanup of Additonal Tables (Extensions)
Bumped .. See below

Chris Wolcott 14:32, 10 June 2008 (UTC)

Token error?
I tried to delete a user(merge it to Anonymous, right?) and there is a token error: Invalid edit token.
 * Did you use the normal interface? Or were you trying the  curl commands above?  The edit token is generated as part of the process - the first form gives you your edit token and the rest of the time it should just come along for the ride.  Tim Laqua talk 20:48, 6 July 2008 (UTC)
 * Well, I think I am using the normal interface...

Merge IP edits?
At the current juncture, it isn't possible to merge IP edits. Would it be possible to make that happen, or does anyone have a quick suggestion on what to do in the database level to make this happen? I know it may seem strange, but the wiki I want to do this on is intranet access only, and there were some edits made w/o being logged in (but I know who made them) - so I'd like to get them put under that user for record keeping purposes. Thanks! -- Shakata Ga Nai ^_^ 00:32, 9 July 2008 (UTC)

I'm in that same situation. I too would like to merge IP edits.--Lorikeet 06:51, 14 December 2008 (UTC)

I would also like to have this functionality.


 * Last post on this function was 4 years ago. Status update please, was this ever implemented? -- Technical 13 (talk) 14:30, 18 April 2012 (UTC)

bug @loading messages?
I just installed this extension and found the following in the drop-down-list of logs (Special:Log): & l t ; usermerge-logpage & g t ; (without the spaces). when selecting that entry, I got to the list of usermerge-logs (as I expected), but next to the entries the text was:  - and not the actual text.

I browsed the svn a bit and found a revision that moved the loading of messages. Then I copypasted this line from UserMerge_body.php to the position it had before that revision, i.e. to UserMerge.php, at the beginning of the efUserMerge function (see this revision).

After that, I now see the correct message in the drop-down-menu on Special:Log ("User merge log"), and I see the correct log-text next to the entries ("user XY merged to ZZ"...).

Is it only me, or is that a bug? --Borp 12:09, 21 October 2008 (UTC)

I have the same problem with v1.6.1 on MediaWiki v1.15, here you need to patch:

diff -r 2d94b19d6494 -r 5693c1685d98 UserMerge/UserMerge_body.php --- a/UserMerge/UserMerge_body.php     Wed Feb 16 13:32:48 2011 +0100 +++ b/UserMerge/UserMerge_body.php     Wed Feb 16 13:33:22 2011 +0100 @@ -3,6 +3,14 @@ * \brief Contains code for the UserMerge Class (extends SpecialPage). */ +if ( !defined( 'MEDIAWIKI' ) ) { +       echo "UserMerge extension\n"; +       exit( 1 ); +} + +# Add messages +wfLoadExtensionMessages( 'UserMerge' ); + ///Special page class for the User Merge and Delete extension /**  * Special page that allows sysops to merge referances from one

five stars!
Does what it says on the tin! --134.36.64.135 16:10, 19 March 2009 (UTC)

undefined method / Xml::fieldset
Fatal error: Call to undefined method Xml::fieldset in /var/lib/mediawiki/extensions/UserMerge/UserMerge_body.php on line 115

Sorry - I've no idea what I'm missing...


 * tried it all again - same result :-(

I am having the same issue as the above user. My error is:

Fatal error: Call to undefined method Xml::fieldset in /var/www/public/extensions/UserMerge/UserMerge_body.php on line 115

What am I missing?

--24.176.16.143 00:23, 13 May 2009 (UTC)

Upgrading to Mediawiki 1.5 solved this issue for me

No success
Doesn't help here. I'm running Mediawiki 1.11.2 and UserMerge 1.6.1.

--84.61.151.149 16:17, 18 June 2009 (UTC)


 * Same problem here, using MediaWiki 1.12.0, PHP 5.2.4, UserMerge 1.6.1... On which MediaWiki version the Xml::fieldset method was added?
 * Problem solved updating to MediaWiki 1.15.1 Rafael Vargas 19:18, 14 July 2009 (UTC)

The fieldset method is missing, you need an MediaWiki update or you use the Version 1.6 (http://svn.wikimedia.org/viewvc/mediawiki/trunk/extensions/UserMerge/?sortby=rev&pathrev=48744)

--80.243.35.98 13:56, 20 October 2009 (UTC)

Cleanup of Additonal Tables (Extensions)
Great extension. A couple of things: watchlist/wl_user page_restrictions/pr_user (not sure what pr_id is)? protected_titles/pt_user $wgUserMergeIdUpdates = array; $wgUserMergeTextUpdates = array; If the Extension:DocumentApproval is added to the Wiki the administrator could then override these tokens rather than changing the code. $wgUserMergeIdUpdates = array(array('approval','user_id'),array('approval_request','user_id')); $wgUserMergeTextUpdates = array; Then the code UserMerge.php can be changed to initialize the variables if (!isset($wgUserMergeTextUpdates)) $wgUserMergeTextUpdates = array; if (!isset($wgUserMergeIdUpdates)) $wgUserMergeIdUpdates = array; Then the code UserMerge_body.php can be changed to merge the predefined array $textUpdateFields and $idUpdateFields. private function mergeUser ($newuser_text, $newuserID, $olduser_text, $olduserID) { global $wgOut, $wgUser, $wgUserMergeIdUpdates, $wgUserMergeTextUpdates;
 * The front page shows the code is at 1.5, but the discussion pages says "Fixed in v1.6.1".
 * To cleanup warnings line 53 and 82 need to test if it is an object before asking for the idForName.
 * Should the following tables/columns be added:
 * Because other extensions can add tables to the Wiki that contain a user_id and/or user_name two additional tokens should be allowed in the LocalSettings.php file

$textUpdateFields = array_merge(array(array('archive','ar_user_text'), array('revision','rev_user_text'), array('filearchive','fa_user_text'), array('image','img_user_text'), array('oldimage','oi_user_text'), array('recentchanges','rc_user_text'), array('ipblocks','ipb_address')), $wgUserMergeTextUpdates);

$idUpdateFields = array_merge(array(array('archive','ar_user'), array('revision','rev_user'), array('filearchive','fa_user'), array('image','img_user'), array('oldimage','oi_user'), array('recentchanges','rc_user'), array('logging','log_user')), $wgUserMergeIdUpdates);

... Wolcott 15:36, 19 May 2009 (UTC)

Relinking contributions to a user
What I want to do is link the contributions of a user that has been deleted to an existing user. Is there anyway to do this?
 * Since this extension does indeed link contributions of the deleted user to an existing user, I assume you mean a user deleted by some other means than this extension, e.g. by direct database manipulation or the broken Deleteuser extension. If you know both the username and numeric ID of the deleted user (perhaps by browsing the database), you can manually recreate the entry in the user table (E.g. INSERT INTO mw_user (user_id, user_name) VALUES (1234, "USER")), then proceed to merge and delete it using this extension. But you need the correct user_id. — Kwi 14:46, 7 February 2012 (UTC)

Add "merge" and "delete" tabs to user pages
Adding the below code to the end of UserMerge.php will add two convient tabs to any User page. Clicking these will allow you to merge or delete that user. Of course, the tabs are only added to user pages if you have the right permissions.

# 2009-07-23 SkyLined: Added "User:" page tabs. $wgExtensionFunctions[] = "UserMerge_Hooks"; function UserMerge_Hooks { global $wgHooks; $wgHooks['SkinTemplateContentActions'][] = 'UserMerge_SkinTemplateContentActions'; }  function UserMerge_SkinTemplateContentActions(&$content_actions){ global $wgUser, $wgRequest, $wgTitle; if ($wgTitle->getNamespace == NS_USER && $wgUser->isAllowed('usermerge')) { $user_merge = Title::newFromText('UserMerge', NS_SPECIAL); $user = $wgTitle->getDBkey; $content_actions['user_merge_tab'] = Array(       'text' => 'merge',        'href' => $user_merge->getLocalUrl(array('olduser' => $user))      ); $content_actions['user_delete_tab'] = Array(       'text' => 'delete',        'href' => $user_merge->getLocalUrl(array('olduser' => $user, 'deleteuser' => 'yes'))      ); }   return true; }

Doesn't merge watchlists
This extension works mostly perfect. Unfortunately, it doesn't merge watchlists. Can this be added? --Ryan lane 20:16, 12 August 2009 (UTC)
 * r89015 --Wikinaut 02:59, 28 May 2011 (UTC)
 * Thank you for including this feature! :-)
 * Note that it is not included in the 1.17 branch, but only in 1.18 and newer. However, I tested the extension for 1.18 in MW 1.17 and it works there as well. --88.130.64.63 15:35, 3 December 2011 (UTC)

Noob question
This is the first extension I've ever installed. I'm using MW v 1.11 and I followed the instructions exactly. I see the "Merge and delete users" page under Restricted special pages, but when I click on it I get "The website cannot display the page; HTTP 500; etc". This might not be enough information, but I'm struggling here. Any tips? (philld2 [at] gmail [dot] com) --169.130.16.130 19:02, 23 October 2009 (UTC)

Question about Signatures
When used, does this change signatures, as well? It could be really tedious to have to change all signatures manually. Neo (talk)20:53, 5 February 2010 (UTC)
 * I am guessing that this extension does not do that. That could probably be fixed with a python script that manually changes all the references... or a redirect from the merged user page.  Good luck. --LRG 06:02, 17 February 2010 (UTC)

Move User:Old to User:New?
I just deleted a user (merged with User:Anonymous) but the old user page stayed untouched. I had to manually move it to User:Anonymous. Is this intended? --Subfader 16:59, 14 February 2010 (UTC)

Thank you!
This works exactly as we wanted to get rid of obscene vandal names in the author footers. Thank you, --LRG 07:29, 17 February 2010 (UTC)

Good Results - Thanks for This Extension

 * MediaWiki 1.16alpha
 * PHP 5.2.12 (cgi-fcgi)
 * MySQL 5.0.88-userstats-log
 * URL DishiWiki

Bravo, Tim, for another useful contribution and extension. Our recipe wiki (DishiWiki) is small in terms of legitimate users. Eventually, there we had more spammy "users" such as "TodayWinningLottoNumbers" and "OnlineDataEntry" than we did legitimate users. Sure, other security measures are in place so that the spam-name-droppers can't cause any real harm, but we felt insulted to see their gross "usernames" on the Special:Users page. I understand the concept of database referential integrity, so I resisted just deleting the offenders from the db while I figured out what to do.

Your Extension:User Merge and Delete is simple to install and worked right out of the box. I copied the often long and cryptic text of the "bad" usernames from the userpage, pasted it into the extension-special-page username box, checked "Delete after Merge," and let the extension "assume Anonymous" as the user to merge with. I had to repeat this process with each bad username, but the merge/deletion was almost instantaneous on each round. I could tell from the output (nice touch) that the extension was tidying up the db nicely.

No more "PleaseYourWomanCompletelyTonight" users -- yipee! Thanks again, Tim. Brian7632416 05:37, 9 March 2010 (UTC)

Need check on merging the same user
By mistake, one may enter the same user name to both old and new user. As the result, the user would be deleted if the delete old user option is on. It would be really helpful if a check is done to prevent the case of merging on the same user since no one would intentionally do that.

Merging users with same name (but difference in upper/lowercase)
In my wiki, I use a custom extension to authenticate users automatically. When this happens, a wiki useraccount is automatically created. Due to a bug, when the user entered his name with the same characters but different case (all lowercase instead of uppercase first character), an extra account was automatically created. This account has the same name, but with differences in case.

I wanted to use this extension to merge these accounts (preserving the correct one), but this does not work. The accounts with the same (lowest as it seems) ID are merged (which does not really make sense) and then this account is deleted. The account with the highest ID is preserved, but this is often the wrong one.

Could this extension be modified to either check for an exact match or to make it possible to enter two ID numbers?


 * I had the same problem. The problem is that the username canonicalization rules are also applied for this extension, thus you need to temporarily disable those while using this extension to merge the users.Kwi 14:39, 7 February 2012 (UTC)
 * I also had this problem. Worked around it by creating some dummy accounts, merged with them, and then merged them to the final canonically named account.

Error in my installation
I am getting this error:

Fatal error: Call to undefined method Xml::fieldset in /home/holowiki/public_html/extensions/UserMerge/UserMerge_body.php on line 115

* MediaWiki: 1.11.0 * PHP: 5.2.5 (apache2handler) * MySQL: 4.1.22-standard-log
 * This extension requires MediaWiki 1.13+
 * The error should be resolved by updating the software, since includes/Xml.php contains

public static function fieldset( $legend = false, $content = false, $attribs = array )
 * in MediaWiki 1.16. Peter17 22:03, 13 November 2010 (UTC)

Database Error

 * filed as Bug 33414: Cannot delete users in block list

I'm running User Merge 1.6.1 on MediaWiki 1.16.1. I've successfully merged away over a hundred spam accounts, but several accounts users give me this database error:

A database query syntax error has occurred. This may indicate a bug in the software. The last attempted database query was: (SQL query hidden) from within function "Database::update". Database returned error "1062: Duplicate entry 'TestUser-55-0-0' for key 'ipb_address' (localhost)". TheAlmightyGuru 05:00, 19 January 2011 (UTC)

I'm running Mediawiki 1.15.1 I got very simular thing too:

A database query syntax error has occurred. This may indicate a bug in the software. The last attempted database query was: (SQL query hidden) from within function "Database::update". MySQL returned error "1062: Duplicate entry 'Anonymous-525-0-0' for key 'ipb_address' (localhost)".

Anybody willing to suggest a fix or even pay attention? Brothejr 00:53, 16 April 2011 (UTC)


 * I was able to move past this error by unblocking the desired user name. Seems that having a user blocked does not allow you to delete it, but you can merge.

The same kind of error appears (MediaWiki 1.17.0, PHP 5.2.17 (cgi-fcgi), MySQL 5.1.47-log); Installed extensions: User Merge and Delete (Version 1.6.31), SyntaxHighlight (Version 1.0.8.10), ConfirmEdit.

A database query syntax error has occurred. This may indicate a bug in the software. The last attempted database query was: (SQL query hidden) from within function "DatabaseBase::update". Database returned error "1062: Duplicate entry '0' for key 'PRIMARY' (localhost)".

I was trying to delete users already in the block list. I could only delete the first user (merge with Anonymous). I'm receiving this error, each time, when trying to delete any other user from the block list (didn't tried to delete not blocked user). Sincerely, ISCIX-Ex 06:30, 21 November 2011 (UTC)


 * I'm getting errors like this, too, on MediaWiki 1.18.0 Zazpot 18:23, 28 December 2011 (UTC)
 * The permanent fix for this particular error (Duplicate entry reported by ISCIX-Ex) is probably the one I posted in the liquidthreads (see discussion) below:

I guess this issue is because the admin/your IP itself is getting blocked while you merge the user. Here is one workaround to solve this issue. * Go to "Special pages" -> "Blocked users" * "Unblock" all the temporary blocks and admin user by clicking at each entry. (This has to be repeated even if the same entry(user/IP) listed more than once) * Go to "Special pages" -> "Merge and delete users" and merge/delete the users as usual. * Repeat from beginning in-case you get the same error again. Sincerely, Anooj 10:28 PM, January 28, 2012 (UTC)

Workaround
Hi guys,

I also had this problem and for me your solution did not work out. I have dug into this and realized that this problem cannot only be caused by entries in the ipblocks table. Basically it can happen in any table, which has a unique index.

To find out what causes the problem in your particular case, set  in LocalSettings.php and try merging the same user again. You will then see the database query, which causes the problem, for example

In this example there already is an entry for the new user (id=1234) in the watchlist table, which points to the same page as there would have to be added for merging the entries of the old user (id=10) to the new user. The solution is to simply remove the duplicated rows of one of the two users from the DB. That way after merging the new user will watch these pages anyway (still or again), but this error will no longer happen. --88.130.66.1 00:02, 9 February 2012 (UTC)

Fix by removing ipblocks for user being merged
I fixed the ipblock problem by just removing the ipblock information of users I want to merge. To do this apply the following changes to UserMerge_body.php in the mergeUser function: $dbw->delete( 'ipblocks', array( 'ipb_user' => $olduserID ) );
 * remove this line: array('ipblocks', 'ipb_user'),  OR (if you have a buggy unpatched UserMerge_body.php): array('ipblocks', 'ipb_id')
 * remove this line: array('ipblocks','ipb_address'),
 * just after the $dbw = wfGetDB( DB_MASTER ); line add this line:

Removing the old ipblock's is needed because MediaWiki only allows blocking of one ipaddress per user. If both the newuser (possible from a previous merge) and the old user have an ipblock this will give a problem. However I wonder if an ipblock won't be useless anyway in the future with the huge amounts of addresses IPV6 provides.

Spellcoder (talk) 02:07, 14 August 2012 (UTC)

Merged & deleted users still show up as logged in for some time (session)
It is a bit disturubing. And I am still searching for an extension to kick a user out as sysop/bureaucrat/admin. --Webrockers 05:17, 27 January 2011 (UTC)

Option to also block the last IP used by user
I use this extension to delete spam accounts. I'd like to see an additional option similar to Special:Block: "Automatically block the last IP address used by this user, and any subsequent IPs they try to edit from". --Subfader 23:22, 27 January 2011 (UTC)

I would also like this option, it would really speed things up! --173.162.42.101 14:21, 17 February 2011 (UTC)

Information about a problem when using "User Merge and Delete" together with "OpenID" [FIXED IN SVN]

 * fixed in r89014 (OpenID version 0.929-beta and UserMerge 1.6.2)

Information for those users who use Extension:User Merge and Delete together with Extension:OpenID: when using both extensions, the current version of User Merge and Delete ignores to copy OpenID settings of from the first (to be merged into the second and to be deleted) to the second account, and remains of the first account hinder the second account to use them (a property of the OpenID extension).

An ad-hoc solution is to manually delete the remains of the first account in the table OpenIDs:

DELETE FROM user_openid WHERE uoi_user=;

Merge "Anonymous" to User B (enhancement)

 * Bug 29188 - UserMerge enhancement: merging "Anonymous" user A to real user B (edit)

Extension Update (May 2011) [FIXED in SVN]

 * committed in r90650 --Wikinaut 06:48, 23 June 2011 (UTC) 

I've been working on an update for this extension which I will hopefully be releasing shortly. It adds support for:


 * Merging user watchlists done. r89015 --Wikinaut 03:00, 28 May 2011 (UTC)
 * Adding user edit count r90650 --Wikinaut 06:48, 23 June 2011 (UTC)
 * Moving user pages (on user deletion) r90650 --Wikinaut 06:48, 23 June 2011 (UTC)

However, I will only be able to test this updated version on MW 1.16 and maybe 1.13. If anyone is willing to test it on other versions before the release please let me know. --Matthew.JA 14:19, 2 May 2011 (UTC)


 * Thank you for adding these features! They were exactly what I was looking for. --88.130.64.63 15:39, 3 December 2011 (UTC)