How can a multisite site admin change a user's role?

I found another post from three years ago asking pretty much the same question. It got 17 replies, only one of which offered what appeared to be an actual solution – but that solution involved an edit to code that apparently no longer exists (in 3.7.1).

It looked to me like most of the replies didn’t understand the problem, which is simple. With multisite, an admin for a single site can add an existing network user to that site (by specifying the user’s email address). The admin can specify that user’s role within the site at the time of the invitation. But once the user has accepted the invitation, the admin has no way to change the user’s role within the site.

For super-admin, this change is made by going to the site’s dashboard, going to all users, and then editing the user in question. It is the user-edit screen that contains the role drop-down. But the user-edit screen also contains fields to change the user’s name choices, contact info, bio, and password. AFAIK, those aspects of a user are network-wide, so it’s right that they should only be modified by super-admin.

But the role of a user within a particular site is something that clearly ought to be changeable by the site admin. I understand that there have been various security issues over time with editors being able to make themselves admins or super-admins in some releases. But given that a single-site admin can set the role of an existing user when inviting them to join their site, I don’t see how giving them the ability to set that user’s role (with the same choices) after they have accepted the invitation introduces any new security issue.

What I would do if I could figure out how, would be to add the role selection drop-down to each user displayed on the users screen for a site if the current user has the promote_users capability. What happens right now (3.7.1), is that the “Edit” link is only present for the user that matches the current user (since it is effectively editing the user’s profile), and that prevents access to changing the user’s role within the site.

Oh my, how embarrassing. I had looked for role changes as a selection in Bulk Actions – but only at the bottom of the list of users. After all this time, I just now noticed the separate “Change role to…” selection box that appears beside the Bulk Actions, but only at the top of the list of users. I think I should go clean my shotgun now ??

Instead of cleaning my shotgun, I decided to go get a cup of coffee and take a look at why the “Change role to..” selection box is present at the top of the user list but absent at the bottom when I came back.

Turned our the answer was quite simple – in wp-admin/includes/class-wp-users-list-table.php at around line 136 we have:

function extra_tablenav( $which ) {
		if ( 'top' != $which )
			return;
	?>
	<div class="alignleft actions">
		<?php if ( current_user_can( 'promote_users' ) ) : ?>
		<label class="screen-reader-text" for="new_role"><?php _e( 'Change role to&hellip;' ) ?></label>
		<select name="new_role" id="new_role">
			<option value=''><?php _e( 'Change role to&hellip;' ) ?></option>
			<?php wp_dropdown_roles(); ?>
		</select>
	<?php
			submit_button( __( 'Change' ), 'button', 'changeit', false );
		endif;

where the parameter $which can be either 'top' or 'bottom'. Commenting out the second and third lines above put the role-changing selection right beside the bulk-action selection at the bottom of the table exactly the way they appear at the top of the table, just in case our users are as unobservant as I was.

DO NOT EDIT CORE

Just don’t. This is a bad idea, it’s not supported, and it’s horrible advice.

*ahem* If you think this should be fixed all over, go post your patch here: https://core.trac.www.ads-software.com/

I’m guessing that since it’s not something you want to run accidentally (nor is it something that’s often run in bulk as users. So it’s a bit of a holdover from that on a singlesite. I would think there should be a way to ‘quick edit’ a user to allow things like that, but it’s complicated since the profile page is a network page and the user role is not.

I don’t THINK we have an open ticket on handling per-site roles, and we really should, since the current set up is janky. Interested in making one? ??

Thanks, Mike, I appreciate your advice and agree with it. I certainly try to avoid editing core files, and those very few times I have felt compelled I carefully track the changes I make, plus I keep the whole tree (excluding uploads) under git. So upgrading core remains a manageable merge task And those few times I do make a change, I often go back and review it several times to see if I can find a hook somewhere to avoid it, or if it was really such an important change.

In this particular case with changing a user’s role within a site, I actually think that the supported method of having only a Bulk Action style of interface where you check the boxes on users to change, and then set the role from a whole-page control, is perfectly fine. And it nicely avoids the confabulation of role within a site with editing a user.

So my only real problem was not noticing the box to do it at the top of the table, having fixated on the bulk actions at the bottom of the table. And I admit that it was a bit hasty of me to edit the file just because I thought that what it was doing was silly, and had caused me to waste a bunch of time, inventing the excuse that someone else might be equally unobservant. Doesn’t meet the importance criteria for editing a core file, so I’ve taken it out ??

I notice that other tables like posts and pages have a somewhat similar property, that at the top of the table there’s a row of table-wide controls, and then at the bottom of the table there’s a similar but smaller row of controls. For the life of me I can’t understand why this is done, it only serves to confuse the user. IMHO, it would be better to omit the row at the bottom of the table completely, than to have it duplicate only a subset of the controls presented at at top. In the case of posts and pages, it could be argued that the additional controls at the top are only for filtering which rows are displayed, so maybe it made sense to someone for them to appear only at the top. But in the case of changing roles, the functionality is identical to a Bulk Action, so I can’t imagine why someone wrote a couple of extra lines of code to prevent it from appearing beside the Bulk Action control at the bottom.

Never submitted a ticket before, but I’ll give this one some thought.

Okay, I decided to be a good citizen and give trac a try.

*nods* Okay you’re probably fine with updating core, but remember the majority of the people who read this? Are not ?? So for their sake, and our sanity, don’t suggest it asa viable alternative.

I’m trying to remember why the dropdown’s only on the top, and it may have been because when you add in a lot of roles, the list gets REALLY long and ran off screen.