UBB.Developers Forums UBB.threads 6 V6 Modifications Archived Mods Change Username Hack

From this thread

In reply to:

---

This hacks allows you to:

a) Change a username to something new

b) if the new username already exists, the script will merge the usernames.

All the settings from the old username will be kept - except for the total posts number, which will reflect the correct totals. The title doesn't get reset though, so you may need to modify it manually.

PMs sent and received, address book entries, moderators, subscriptions, read receipts etc etc are all handled and reflect the new username.

I built on Dave's great work - thanks!

Max

---

I only changed a couple lines to get it to work. I also had to add in a section to change the "last post by" section, because it wasn't changing the name there.

Thank you very much. !!!!!

so this doesn't work under 6 final? I just tried it, the link shows up in the admin panel, but when you click it the right page is just a blank white page

Thank you.

Works just fine - will be very useful when I convert a forum from UBB to threads - I have extended it to my moderators, so that the workload of changing usernames is shared.

I realise it is a risk - but then I like to trust people.

Ian.

I'm sorry, it works for me. Are you sure the sk_changename.php file is in your ubbthreads/admin folder? That is the page that should be called up when you click the link.

Yes works just fine and so do signatures

sorry for my ignorance, I didn't see Lisa's new attachment, so I was using the old attachment

Works great on 6.0.1 !!

Thanks!

6.0.1 worked right out of the box; cant get a hack thats any easier to install!

Awesome hack. Works great... should be part of the official relase.

Here's a tip:
I had a user "bobbrown" who asked to change his username to "BobBrown" (note the capitols). Using the change for this actually deletes the user...... BUT

There is a work around....
Change "bobbrown" to "bobbrown2".. then change "bobbrown2" to "BobBrown" and it works fine.

Just a tip if anyone has this type of request.

Yep, I changed a user's name to have some caps, and they vanished later on. It did change them for a bit...

At least now I know to change them to something else first! LOL

Thanks for reporting that.

Maybe the hack should be revised to either deal with that case, or disallow it.

I had that too, changed a guy from barryrs4 to BarryRS4 and he was fine, then a few hours later he completely vanished from the database! his account and all his posts, the guy was really pissed as he had like 1500 posts and went down to newbie status!

Now we need a hack to backup all the deleeted users and their posts! ROFL

A hack from the admin menu that did a mysqldump would be a wonderful idea.... saving the last 5 backups or so.

[]Maybe the hack should be revised to either deal with that case, or disallow it.

---

I already played with that but didn't complete it.
I simply convert the usernames to lowercase and do a comparison. You can simply skip the db-queries that are used for merging 2 users and cause the disapearing.

I can post the code, when i'm back home. But it isn't finished yet.

So in sk_dochangename.php, if strcasecmp($olduser,$newuser)==0, then you would do all the queries after the comment "go ahead and change the source username to the target username everywhere", but omit all the preceding queries?

I wonder if the eregi_replace() on line 201 should be changed to ereg_replace(). Maybe that doesn't matter.

I attached my modified version with the workaround for the upper and lower case problem. It should work but isn't fully tested. So you may want to backup your user before trying it. Let me know if any problems occur.

@Dave_L yes, that was the way i did it. Yes, ereg_replace would be better code. Also it doesn't matter here, because the usernames are case insensitive.

Thanks

A few issues:

1) Are the parameters to authenticate() not necessary? I haven't figured out exactly how that function works.

code:
$user = $userob -> authenticate();

---

2) strcasecmp() usage:

code:
if strcasecmp($olduser,$newuser)==1 {

---

should be

code:
if (!strcasecmp($olduser,$newuser)) {

---

Or maybe your original code is easier to understand. I'm not sure.

code:
if (strtolower($olduser) == strtolower($newuser)) {

---

3)

code:
$upandlow = true;

---

should be

code:
$upandlow = 1;

---

4)

code:
$newmods = addslashes($newmods);

---

should be

code:
$newmods_q = addslashes($newmods);

---

I've made some enhancements to my copy of the hack:
a) Expanded explanation of what the hack does in the entry form.
b) Added more safety checks, including those done by adduser.php.

Should I merge my changes into your version and upload that?

[] Are the parameters to authenticate() not necessary? I haven't figured out exactly how that function works.

---

Yes, the authentication function has been changed in V6, so all necessary parameters are set by default. Look at ubbt.inc.php for details.

There shouldn't be any difference betweem strcasecmp and strtolower, but i'll choose the first one cause i don't know how strtolower behaves on '"@| etc...

Yes, i missed the "!" before the statement, removed it for testing.

code:
$upandlow = 1; and $upandlow = true;

---

Both should work, i'm used to set boolean = true/false from java programming.

code:
 $newmods_q = addslashes($newmods); 

---

Yep, missed that one, thanx.

[] I've made some enhancements to my copy of the hack:
a) Expanded explanation of what the hack does in the entry form.
b) Added more safety checks, including those done by adduser.php.

---

Greatly appreciated

Re: authenticate() - thanks, that's what I thought, but wasn't sure.

That's a good point about strtolower() not converting special characters to lower case. Although, I think Rick uses strtolower() in other places for comparing usernames. I wonder if that's a potential problem.

This is PHP, not Java.

I believe in using the idioms for whatever language I'm using. In PHP (and Perl and C), boolean operations are designed to work with 0 for "false" and nonzero for "true". Using "true" and "false" in PHP is a bad practice, because you're fighting the language. For example, both "true" and "false" evaluate as true in boolean context. And if you want to compare two boolean values, it's simpler (and more reliable) if you stick with the language conventions.

But if you're going to use "true" anyway, the quotes should be present. Depending on the PHP version and the error_reporting() level, true (without the quotes) will result in a warning or error message.

I'll post my modified version.

[] Although, I think Rick uses strtolower() in other places for comparing usernames.

---

Yep, that's why i used it at first. But as you have mentioned, i'm not really familiar with PHP.
Will stick to to 1 and 0 now

I may have been wrong about the 1/0 and true/false stuff.

I just noticed in the PHP manual that in version 4, there are keywords True and False. I haven't had time to see exactly how they work.

It was pointed out in another post that the w3t_PollData.P_IP column contains a username (or an IP address).

I assume this needs to be added to the script?

Yes, if you wanna have 100% clean code.
The you also have to change w3t.PollData.P_Name and w3t.Polls.P_Name.
Both contain the combination of the ip and the username who started the poll. The Poll is identified via that fields.

But you can't edit polls anyway so not updating this fields shouldn't cause any problems. Also it's not perfect then...

Any chance we might see the newer version?

There's a good chance

I'm in the middle of doing other things, but I haven't forgotten about this.

I'm back to working on this now.

I'm trying to figure out who to list in the History or Credits section. Is the following accurate? If not, please make corrections or additions.

sixpack69 - original author of UBB.threads version 5 hack (5/01)
Dr_Manhattan - reworked hack (11/01)
Max Fisch - reworked hack (2/02)
Lisa_P - adapted hack for version UBB.threads version 6 (5/02)
Astaran - added fix so that hack would work correctly when old and new usernames differ only in alphabetic case. (6/02)

References:
Plug-in: change username
Change Username Hack, reposted
Change Username Hack

sounds good... it can always be updated if some obscure person was missed, like the dude that asks questions, me

[:"red"]CAUTION: THIS HAS NOT BEEN FULLY TESTED[/]

NAME: Change Username
VERSION: 2.0.0
DESCRIPTION: Changes a username, or merges two usernames
WORKING UNDER: UBB.threads 6.0.2
PREREQUISITES: none
AUTHORS: sixpack69, Dr_Manhattan, Max Fisch, Lisa_P, Astaran, Dave_L
CREDITS: documentation adapted from that provided by Max Fisch
DEMO: none
FILES ALTERED: admin/menu.php
DATABASE ALTERED: username changed
NEW FILES: admin/sk_changeuser.php, admin/sk_dochangeuser.php, admin/sk_changeuser.inc.php

HISTORY:
2001-05-04 sixpack69 - Original release (UBB.threads version 5).
2001-07-14 Dr_Manhattan - Reworked.
2001-11-09 Dr_Manhattan - Revised.
2002-02-13 Max Fisch - Modified to include more database conversion.
2002-05-29 Lisa_P - Adapted for UBB.threads version 6.
2002-06-25 Astaran - Added fix so that hack would work correctly when old and new usernames differ only in alphabetic case.
2002-07-06 Dave_L - Expanded displayed information on entry form, and added same checks that are in adduser.php.

REFERENCES:
Plug-in: change username
Change Username Hack, reposted
Change Username Hack

********
ABSTRACT
********

This modification changes a username, or merges two usernames.

Numerous columns in the database get modified, so it is recommended that you back up the database prior to installing or using this hack.

If the new username already exists, the database information (posts, messages, moderators, etc.) associated with both usernames will be merged and associated with the new username. The settings from the old username will be kept, except for the total post count, which will be adjusted to include the total posts from both usernames. The title doesn't get reset, though, so you may need to modify it manually.

The columns w3t_Polls.P_Name and w3t_PollData.P_Name are *not* converted. Since polls cannot be edited, this is not considered to be a problem.

Hi Dave,
I just looked this over... a couple of questions:
* I didn't see the user and post ratings updated... did I miss them, or are they not converted
* I didn't quite get why uppercase gets converted to lowercase - in the old version, you could modify the capitalization of a name. Was this creating problems in some databases?

Cheers,
Max

1) There's nothing in there now to convert the ratings.

It looks like the w3t_Ratings.R_Rater column needs to be converted.

Also, the w3t_Ratings.R_What column needs to be converted if it's a username (w3t_Ratings.R_Type == 'u'), rather than a post number (w3t_Ratings.R_Type == 't').

In addition, w3t_Posts.B_LastEditBy was left out.

Thanks for the feedback. I'll make a note to add these in. Please let me know if you find anything else missing.

2) It should handle case-conversions correctly. That was one thing that I did test. The lowercase/uppercase stuff had to do with a bug in an earlier version - if the old and new names differed only in case, the user got deleted. The earlier posts in this thread discuss that.

Got it - thanks!

Case conversions worked fine for me with the old version, I did test for that... my guess is that different database/php installations handled it differently, good to hear it's cleaned up.

Cheers,
Max

Found a small mistake in the documentation. In the installation instructions for admin/menu.php, "Replace with" should be "Insert after".

Found some other columns that need to be converted:

w3t_Online.O_Username
w3t_Favorites.F_Owner
w3t_Banned.B_Username

I noticed these when reading a post on the UBB Central demo board.

I took another look at the poll stuff:

w3t_Polls.P_Name (timestamp concatenated with username)
w3t_Polldata.P_Name (timestamp concatenated with username)
w3t_Polldata.P_IP (username or IP address)

I don't think converting the P_Name columns is important, since that appears just to be a way of uniquely identifying the poll. (And it would be messy to convert.)

But the P_IP column is evidently how the script keeps users from voting more than once, so that probably should be converted.

Dave,

No pressure but... I am about to convert over a 1,000+ member forum to threads, and will rely heavily on this hack over the next 24 hours or so - as many of our users have different usernames to their old UBB screen names.

I guess that these other fields could potentially be quite important - is it worth me holding off until you release another update? Or are these other fields not going to cause me major headaches with half converted data?

Cheers,

Ian

I'm attaching an updated version, 2.0.1, which has all the corrections noted above.

I added conversions for the following columns:

w3t_Posts.B_LastEditBy
w3t_Ratings.R_Rater
w3t_Ratings.R_What
w3t_Online.O_Username
w3t_Favorites.F_Owner
w3t_Banned.B_Username
w3t_Polldata.P_IP (username or IP address)

For some of these, I deleted any existing rows for the new username, but I'm not sure whether it's correct to do that.

I would [:"red"]NOT[/] recommend using either the previous version or this new version on a production board until others have reviewed the code and beta-tested it.

Ian, if you are importing a ubb.classic into threads, there is a fix for the import script to import users using their public displayed name. It has been posted a few places... infopop a couple of times. If you can't find it and need it, I'll find it for you

Thanks Allen - but we are going down the login name route - and then altering them.

It is now 05:45 here - and the new forums are live!!! It has been a long night....

Just waiting for the complainst to start now!!

Ian.