Paul Gilzow

Not sure I’m following. You want your users to be able to enter in their sAMAccountname or their email address as the user name? Is the email address just [email protected]?

2.2.5 corrects the issue though i’m not sure why the plugin page shows that 2.2.4 is the latest tag version.

AH. That change makes sense.

It’s to prevent someone from trying to directly address that file, or prevent it from loading if the screen that is requested isn’t the backend interface, or to prevent it from loading if the current user doesn’t have the appropriate role.

The piece that isn’t making sense is that if core has loaded, that function should be defined.

I’ll try to set up an exact replica of your site (minus content) tomorrow to see if I can replicate the issue

• This reply was modified 5 years, 3 months ago by Paul Gilzow.

this is_admin() is a trap !!! it should be called !is_front() !!!

Yes, that has been a source of much confusion and frustration for many years.

if you attempt to access /wp-admin/ and you’re not logged in, it doesn’t redirect you to wp-login.php? Or are you saying that you’re already logged in, but if you then try to go directly to /wp-admin/ that’s when the error is thrown?

I haven’t been able to replicate it yet.

I have not seen that so far on any of the sites I have access to. I want to make sure I’m clear, this occurs during authentication at wp-login.php, correct?

Can you include WordPress version number and other plugins (+versions) you have installed?

Really? I have not seen that. Can you start a new thread with the details so we can troubleshoot?

Sent.

Happy to take it over as we have hundreds of sites depending on it, and if it isn’t available here, I’ll have to either maintain it on our local gitlab instance anyway or as I mentioned above, fork it. Do you want me to send the information you listed to our previous email thread, or post here?

I spoke with the author. He said he doesn’t know why his access has been revoked. He never received a notice, here or at the email address associated with his account here. Given he’s done with WordPress, he’s not overly motivated to look into it further. I’ve asked if he’d be willing to let me work on getting his access restored so he can transfer ownership to me so I can maintain it, but have not received a response yet.

Given we depend on this plugin, if he doesn’t respond, I’ll probably fork it and submit it as a new plugin, though I’d prefer to just maintain the original.

• This reply was modified 5 years, 3 months ago by Paul Gilzow. Reason: Typo

And this is what I dislike about the current WordPress ecosystem: plugins are closed/removed with ZERO notification to site’s using the plugin. And no information on WHY it’s been closed.

Interestingly, the author has left the WordPress ecosystem because of similar frustrations with WordPress: https://www.ctrl.blog/entry/enough-of-wordpress.html

Some plugins remove the default roles and replace them with their own.

Right, which is where the editable_roles filter comes into play. I can update the plugin to include all of the roles assigned for a child site (or whatever currently exists in the options table for the site) but I won’t be able to trigger a child site’s plugins to apply the editable_roles filter.

I can adjust the plugin so it shows all of the available roles for a child site (and now that I know about this issue, I will), but I don’t know of a good way to have it show a limited set of roles that are affected via a plugin. Does that make sense?

Hhhhhmmmm…. good point. I see what you’re saying now. Though, running switch_current_blog for every site in a large multisite in the edit screen and then in the save section is going to introduce a distinct performance issue… The WP_Roles class takes a siteid as a parameter in its constructor, and has a for_site method but both of those are available only as of version 4.9. So I could do it for sites that are on 4.9 or later. For versions before v4.9 I’d essentially have to recreate what they added to WP_Roles. And doing it this way won’t fire the editable_roles filter for that child site.

Actually, can you do me a favor? For the site that has roles removed, can you get the option_value for the key wp_<blog_id>_user_roles from the table <wp_prefix>_<blog_id>_options (e.g. wp_2_options) ?

I’m betting it will contain _all_ of the roles, including the ones you have removed for that site.

The plugin uses the WordPress function wp_dropdown_roles to display the list of roles in that screen, so in your case, WordPress isn’t seeing your custom roles, or roles you have removed.

Are you using a plugin to modify roles, or code inside a theme’s function file?

Selecting the default role from a site isn’t a bad idea, though it’s a bit more complex in a mulsite instance. Might add that to a future release.