vickifarmer

Same.

Sadly neither one of these is optimal for me. (This is about preserving privacy on an anonymous feedback form on a company intranet run on a WP multisite network.) I’ll keep looking for a solution. Totally okay with just being handed a filter hook and minimal documentation.

Thanks for your response.

Yes, I think we’re on the right track, here. I just updated both users to “editor” on their respective sites through the approved users interface for Authorizer INSTEAD of changing their roles through their individual profile interfaces. The database entries for auth_settings_access_users_approved are now showing “editor.”

We’ll see if the one user also retains the custom role of researcher_admin!

No, neither of them have two accounts, and neither of them are in the multisite approved users.

The person who keeps toggling back to “researcher” from “researcher_admin” + “editor” is set to “researcher” in the auth_settings_access_users_approved, which is expected from the perspective of that being what she keeps getting reset to, but that is NOT the default setting for that site. The default setting is “subscriber”; she started out there and at some point the system accepted and saved the change in her role to “researcher.” (This would have been relatively recent — within maybe the last three months?) At some point since then it stopped saving changes. (On TWO separate multisite networks, no less.) In both of these cases, these are relatively new users and recent role changes. People who’ve been around longer have their settings established. Something changed between point A and point B. ??

I’m going to play around with some placeholder accounts and see if I can replicate this thing. It’ll be a lot easier to experiment if I’m not waiting for a user to log in.

I’ll update here if I find anything.

YES, okay, I see the user and when I run the data through unserialize, this is what I have:

16 =>
array (
'email' => '[user email]',
'role' => 'subscriber',
'date_added' => '2024-01-04 17:40:21',
),

There are 16 entries for this particular subsite.

I looked at the approved users for this subsite in the Authorizer admin tab, and it shows this user as being approved as an editor.

The fa_prefix refered to the User Login History plugin, which honestly I had forgotten I had running. (Sometimes the chainsaws that I’m juggling hit the ground. *sigh* At least I tend to default to “more security” rather than less.) I have disabled it because I have other logging enabled that makes it redundant. I’ll let you know if this seems to have changed anything.

Meanwhile, my other user on the other multisite network logged in this afternoon, and her permissions had been rolled back, too.

At this point, the rollback is happening every time for this one user. (Don’t know if the other user is active or not, honestly.)

Looking at the [mydbprefix and site number]_fa_user_logins table, I’m seeing this user has ‘old_role’ = subscriber. If I were to edit that by hand to editor…..? I always hate to do that sort of thing without knowing if I’m breaking something else…..

Well, one of those users (the one who is supposed to be an Editor and keeps getting set back to Subscriber) had his permissions rolled back again today, without the failed login, so I guess that’s a red herring.

Not to be a downer about it, but I’m about to have to implement some new MFA requirements coming from waaaay above my pay grade, that may move us to a new authentication plugin. I’ll be sad, because this has been a genuinely useful tool for me for a long time, but it may solve my particular local problems.

Hi there,

This is a very kind response to a review left after a bad day at work.

You have a really very good plugin, and I have edited my review to reflect that.

But yeah, if the nags were to be reduced, that would be so very appreciated.

Not to put too find a point on it, but if you’re causing fatal errors in people’s admins, you might want to consider that a priority fix.

I was NOT using grid view in WP multisite, and I’m getting fatal errors in my activity log.

Edit to add: Okay, I went into the db and deleted the wsal_events-nav-type line. I wanted to see the setting, just to be sure, and it was ‘infinite scroll’. Deleting the line has the interface working again, so yay, but this may be more than just a grid display problem?

• This reply was modified 12 months ago by vickifarmer.

Seriously, this should not be hard.

Dev branch works! \o/

Thanks!

Out of curiosity, I reinstalled this plugin from scratch, and sure enough, when I activated it, the site crashed.

Hi, sure, this is a WP multisite network; the WP Beta Tester plugin was network-activated, and the entire site was down, front and back end. I had to remove the plugin from the plugins directory to get it back up.

Other plugins that are network activated are Multisite Enhancements, Multisite Plugin Manager, NS Cloner-Site Copier, User Switching, and WP Help.

PHP 8.1.13, Currently running WP 6.2-RC2-55551.

I think the site went down as soon as the plugin updated automatically.

Let me know if there’s anything else I can do to help.

• This reply was modified 1 year, 7 months ago by vickifarmer.

Very cool. Thank you!

I have to ask: why is this inline CSS? It seems to me like bad form, unless there’s some really compelling reason for it. Unless this space serves a specific and unalterable purpose in the player, it should be in the regular CSS files and be configurable by means of custom CSS, so we don’t have to re-hack the .php file every time we update the plugin. Srsly, give the player different class names for different alignment settings and do the padding in the CSS files the way God and man intended. *g*