Hooking into User Role changes

I am working on an existing plugin

(1) What’s exact name of this plugin?
(2) Plugin acquired from?

The plugin is https://www.ads-software.com/support/plugin/authorizer/, I am one of the developers on it.

I don’t have an answer to your question. I’m somewhat confident no one here knows offhand. I recommend placing an error_log() line or similar mechanism into your callbacks and do your own testing to find out for yourself. If you would please report your findings here, it’d be very much appreciated.

In many cases it’s not detrimental for callbacks to execute multiple times per request since the end result is unchanged. For example, if I update “my_option” to “foo”, it doesn’t matter if it’s done once or five times, the end result is the same. Yes, there’s a minor performance hit. Typically negligible.

It’s not uncommon for even a single action or filter hook to fire multiple times in one request. For the situation where multiple executions is a problem, such as when incrementing a counter, the callback should use one of the remove_*() functions to remove itself from the call stack so it will not be called again should the hook fire more than once per request. You should call the removal function straight away because waiting until the end could cause a race condition where execution starts again before the removal can be completed.

Not only can a callback remove itself, it can remove other callbacks that were added elsewhere. Your set_user_role callback could remove the user_profile_update_errors callback and vice versa. I don’t think it’ll be necessary, but it’s an option that’s available to us.

Sounds good; I’m already part way down the rabbit hole on this one and getting a good handle on the workflow. We’re trying to hunt down a weird bug related to roles, and in the process trying to reduce complexity. If we can reduce the hooks when role changes occur to just one place it will make troubleshooting issues easier down the road.

I’ll update with findings once I have more info.

OK, following the logic flow, user editing is handled in edit_user (see https://developer.www.ads-software.com/reference/functions/edit_user/).

In edit_user are two functions that appear to get called whenever a user is updated or created: wp_update_user (https://developer.www.ads-software.com/reference/functions/wp_update_user/) and wp_insert_user (https://developer.www.ads-software.com/reference/functions/wp_insert_user/). The former actually calls and passes data to the latter, so we’ll focus there.

wp_insert_user will update roles by calling set_role on the user object (see https://github.com/WordPress/wordpress-develop/blob/master/src/wp-includes/user.php#L2144). This will presumably only get called if everything else with the user has not thrown an error, based on where it is in the insert user call.

set_role (https://developer.www.ads-software.com/reference/classes/wp_user/set_role/) has a hook in it called set_user_role (see https://developer.www.ads-software.com/reference/hooks/set_user_role/). This appears to be only called if there are no issues with the set_role and happens only if the user’s role actually was properly set.

Based on this, it’s looking like it’s safe for us to remove references to user_profile_update_errors, which is called early on in edit_user and before either wp_update_user and wp_insert_user, which means it would not really be indicative of whether the user’s role has actually been set at that point since all of the subsequent logic to actually set the user’s role had not yet been called. Instead we should use the set_user_role hook to verify that a role has been changed successfully, and run our code based off of that.

I hope that helps explain our refactoring work!

Thanks for the detailed summary! So “set_user_role” is indeed the only hook necessary and it is the one most suitable for your purpose.

It does look that way. We’re going to continue refactoring and I’ll check back in if we discover anything that’s an exception to this.