sootsnoot

I don’t mean to butt in, and I don’t know why the original poster hasn’t replied. But just out of curiosity after reading her post I went to https://achecker.ca and entered https://www.arntstopsoil.com in its default Web Page URL box. It reported very specifically on 99 “known problems”, including missing labels or labels with no text for input elements. And looking at the elements reported I’d guess most/some of those issues came from forms that are part of the widget.

There were also lots of other complaints about low-contrast colors on visited links that probably had nothing to do with the plugin.

If nothing else, I thought the achecker.ca site itself, and the kinds of errors it reported, were somewhat interesting/educational for someone not overly familiar with accessibility issues.

No problem, Josh, use it however you like. I’m secretly flattered that you called it concise, as I seldom hear that – responses I get to emails I send usually include something like: “I didn’t have time to digest the whole thing, I’ll have to get back to you later on the details” ??

I’ll just heap on a little more praise and appreciation. Having seen a few of the slams you got for the loss of some free functionality, I’m really impressed by the tactful and truthful way you responded to each hand every one, and your continued enthusiastic support. Yup, real professionalism. The timing of the demolition of the code base on which you built Ultimate TinyMCE could hardly have been more catastrophic for you. It was tough taking personal hits for moving *some* of the big-ticket work items forced on you to the paid version, while keeping most of the not-so-huge items free. Clearly your excellent work and dedication to the community are appreciated by most of us, and this article explaining the situation to those who didn’t know should help with the critics.

Get some rest. But not too much, there’s more to do be done ??

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

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.

Authors/editors of a site within a multisite network don’t normally have direct access to the uploads folder. So if the network admin has enabled space quotas, it seems like this behavior would leave them no way to reclaim space. Once they uploaded enough media to fill their quota, they’d be stuck.

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.

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 ??

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.

Thanks for looking at this. I realize I’ve got a fairly unusual situation, so finding out I can’t really get exactly what I want through plugins (without touching core files) might well be the answer. What I’m asking sort of directly contradicts the behavior of WP subdomain multisite. The only thing in my favor is that I set up only subdirectory multisite, so my little parochial interpretation of what that might mean is that wordpress should ignore the subdomain and just look at the path in requests ??

So yes, you’ve hit the nail on the head. In more detail, accessing the MVC application through different subdomains is sort of accessing only a single site in the sense that 99.9% of the sources are the same (through symbolic links), and there is only one MVC database with the result of queries not depending on which subdomain is used (though MVC application code might interpret or format query results differently depending on the subdomain). Thus the subdomain is used only as sort of a global implied query parameter to the MVC application, and I’d like to be able to do the same thing with the WP installation that goes with it.

I’ve got workarounds that avoid the handful of unexpected behavior kinds of problems that can occur when wordpress redirects to the main server. But one that I don’t know how to workaround is that if a user of the MVC application accessed through a subdomain clicks a link to a blog, then the browser’s address bar changes to the servername of the main site with the subdomain stripped off.

Thanks again for looking at this.

Quick experiment shouldn’t have been necessary if I’d been familiar with the table definitions: blog_id is the primary key, so it isn’t possible to have more than one row with that value.

Next idea? ??