Support » Plugin: Members » Members not compatible with Simple:Press Forum

  • Hi, Justin.

    It looks like that when Members plugin is active, Simple:Press Forum admins don’t “see” their rights properly (capabilities don’t work), but as soon as I deactivate Members, they work just fine.

    Would it be possible for you to check with Simple:Press developers where the problem lies?

    https://simple-press.com

    Kind regards,

    Ari

    The page I need help with: [log in to see the link]

Viewing 9 replies - 1 through 9 (of 9 total)
  • There’s also an ongoing discussion topic on their forum on this matter:
    https://simple-press.com/support-forum/pre-membership-queries/new-installation-admin-rights-dont-stick/

    Regards,

    Ari

    Plugin Author Justin Tadlock

    (@greenshady)

    The best thing to do is to ask the forum plugin authors for a way to disable role/cap management from within the forum plugin. The forum plugin shouldn’t be attempting to handle the management of roles and caps. It should only be concerned with being a forum plugin and leaving role editing to role editing plugins.

    I’ve seen this a number of times with other plugins that attempt to do too much. Quite often, the experience isn’t great because those plugins just aren’t capable of handling all the nuances with the role/cap system in WP. It’s not because those plugins are bad. It’s just out of scope and better left to plugins that are specifically built for this.

    With all that said, when I get a little time, I’ll look at the forum plugin to see what it’s doing.

    Plugin Author Justin Tadlock

    (@greenshady)

    Is there a way to download the plugin without creating an account at that site? I couldn’t find a link to a plain ZIP file or Git/SVN code repo.

    Thank you for a quick reply. I do appreciate your support in this matter.

    I’ve imformed Simple:Press developers that you responded – and truly hope you could sort this out together. I’m not a programmer, so these details do not tell me much.

    Kind regards,

    Ari

    It feels a bit funny to act as a discussion proxy in the middle, but here’s what Simple:Press devs had to say (in their forum, link provided above):

    “Justin is an old and respected hand at all of this so he should know what he is doing. So here is the reply you need to give to him…

    Simple:Press does NOT get involved in WP Roles in any way. We do not create them, remove them etc. What we DO is define a set of capabilities for the Forum Admins. Note that Forum Admins do NOT need to be WP Administrators.

    When a user is defined as a new Forum Admin the forum specific capabilities defined for that user are added to the standard capabilities defined in their usermeta record. We have never before heard – in over 12 years – of these user caps being lost, ignored or bypassed before.

    As far as we are concerned, these caps are added in line with the WP API and within the scope and intention of user caps.”

    Hoping this helps to clarify the situation…

    Plugin Author Justin Tadlock

    (@greenshady)

    I’m happy to test it out at some point in my free time. I just need a copy of the forum plugin.

    Plugin Author Justin Tadlock

    (@greenshady)

    If I’m looking at the forum plugin correctly, it appears to be using capability names like SPF Manage Users. Ideally, such a capability would be named spf_manage_users.

    While it is technically possible to name a capability anything, the standard has been well established since WordPress version 2.1 (when roles and caps were introduced) — caps should be all lowercase with underscores to separate words (snake case). Having a standard gives us a consistent and reliable way to sanitize or validate that something is in fact a capability.

    Members will sanitize capabilities on its edit role screen (for security purposes mainly). Most role/cap plugins are going to do something similar. This is going to remove the spaces and is likely the issue you’re experiencing. I saw that you had issues with User Role Editor too. I imagine it’s going to be the same issue.

    Members does have a filter hook to change this behavior with a few lines of code, but I just realized it doesn’t pass in the original, unsanitized cap, which sort of makes the hook useless (hey, we found a bug!). I could put that on the agenda for the next version. I don’t mind doing that.

    If you absolutely need this before the next version, you can open up members/inc/functions-capabilities.php and change this code on line 245:

    
    return apply_filters( 'members_sanitize_cap', sanitize_key( $cap ) );
    

    To this:

    
    return apply_filters( 'members_sanitize_cap', sanitize_text_field( $cap ) );
    

    That should fix it assuming that’s where the issue lies. This is just an educated guess on my part.

    For the long term, I’d recommend the forum plugin building in an upgrade routine to convert to the cap-naming scheme that core WordPress uses.

    Plugin Author Justin Tadlock

    (@greenshady)

    I did want to clarify that I’m not 100% certain this is where the issue lies. It’s just something that caught my eye scanning the code.

    Just some general thoughts for the plugin author:

    If I were building a forum plugin, I’d probably build some dynamic roles specific to the forum by hooking into wp_roles_init. I’d lock the editing of those roles using the editable_roles filter hook in core WP. Then, I’d create a “forum role” dropdown on the manage users and edit user profile screens for assigning forum-specific roles.

    These would be in addition to the users’ normal WP role. It’d cover 95% of use cases if you covered your bases with a good hierarchy of forum roles. Then, for the other 5% that need something custom, they could use a role-editing plugin to create custom roles.

    arikontiainen

    (@arikontiainen)

    Hi, Justin. Thank you very much for your efforts.

    I changed the code line as instructed, but when I activated Members, the other admin did not see forum menus. When I deactivated Members, menus are visible. So, it looks like it did not solve the problem. There must be something else…?

Viewing 9 replies - 1 through 9 (of 9 total)
  • You must be logged in to reply to this topic.