Forum Replies Created

Viewing 4 replies - 1 through 4 (of 4 total)
  • Thread Starter lizardzone

    (@lizardzone)

    We use W3C Total Cache for page-level caching for non-logged-in visitors.

    No custom roles involved in this particular scenario. We have one custom role which has been used for a few users on another child site. None of those users or roles or sites intersect with the sites where we’ve experienced this problem.

    Thread Starter lizardzone

    (@lizardzone)

    Yup, we are on 3.1.2

    Thread Starter lizardzone

    (@lizardzone)

    Thanks for your response!

    In the past we’ve had an issue where changing the role in the WordPress UI did not properly sync to the Authorizer Approved List, so Authorizer was changing the role to what it had listed when the user logged in.

    That sounds like it would describe our situation pretty well – I wonder if that’s what’s happening? The roles are currently correct in Authorizor compared to the WP UI. If we should simply avoid making role changes with the WP user UI, I can live with that as a solution for now.

    1. Where in the WordPress dashboard did you change roles (via bulk actions on the user list page, editing the individual user profile, or the dropdown on the Authorizer Approved list are the 3 methods we are aware of)?

    WordPress UI, using bulk actions

    2. Is this only affecting multisite users that also have capabilities on another site in the network, or all users?

    Yes, all affected users are multisite users who previously had capabilities elsewhere

    3. Does it happen when the user first logs into the new site, or on subsequent logins?

    I can say that in at least one case, a user had the correct role, logged in, did actions in that role, and then when coming back to the site later, had lost that role and was demoted to a subscriber, and that the preceding scenario happened to them twice. With other users who were demoted, I don’t know if they successfully performed actions before later losing their role.

    4. Do you know if the users were hitting the /wp-login.php endpoint of the new subsite, or some other subsite, or the main site?

    Probably the login page of their subsite, but we don’t know

    • This reply was modified 3 years, 6 months ago by lizardzone. Reason: fixed blockquotes
    Thread Starter lizardzone

    (@lizardzone)

    That helps a lot – thank you WPyogi.

Viewing 4 replies - 1 through 4 (of 4 total)