Name: hook_user_update_name
Rationale: All MODs that store usernames in there own database tables, need them to be updated when a user is renamed.
Placement: includes/functions_user.php inside user_update_name($old_name, $new_name) (position is not really important
Input arguments: $old_name, $new_name
Output format: void
[RFC|Implemented] user_update_name hook
- nickvergessen
- Former Team Member
- Posts: 733
- Joined: Sun Oct 07, 2007 11:54 am
- Location: Stuttgart, Germany
- Contact:
[RFC|Implemented] user_update_name hook
Member of the Development-Team — No Support via PM
Re: [RFC] user_update_name hook
I would pass the $user->data array as well with the updated name (and remove the current new name param). Because that contains the row in the phpBB table, some mod/bridge authors could use custom columns they have set up for user account association.
- nickvergessen
- Former Team Member
- Posts: 733
- Joined: Sun Oct 07, 2007 11:54 am
- Location: Stuttgart, Germany
- Contact:
Re: [RFC] user_update_name hook
We don't have a user_row of the user we update, and sending the one of the user who changes the name makes no sense at all...
Member of the Development-Team — No Support via PM
Re: [RFC] user_update_name hook
How about a simple notification that "something" in the user profile was changed? I agree that some mods need the name change, but other mods might need other changes as well. One could simply have a hook that carries the information of the column names that were changed along with the new values and - to be able to react on changes within the ACP as well - the user ID. If the mod needs another column to link to users, thats obviously a badly coded mod. But some Mods should know if other fields are updated, e.g. a Geo-Location Mod might want to know if the location profile field of a user changes. I would not treat the username special in any way here, and creating a hook for every single profile field is a lot of functions and probably a lot of overhead, too if several changes are made and needed by a mod.
Same thing goes here as for user_add/delete: One should be able to deny/alter the change as well, thus I would split this hook up into two: One before, one after the change was commited. Changing/denying things could be done using the "before" part, updating other tables based on the changes could be done using the "after" part.
Same thing goes here as for user_add/delete: One should be able to deny/alter the change as well, thus I would split this hook up into two: One before, one after the change was commited. Changing/denying things could be done using the "before" part, updating other tables based on the changes could be done using the "after" part.