Hey Sandra,

Have you taken a look at the SP Codex article – How to Configure Simple Press with Membership Plugin?

Hi, I’d like to bump this topic.

I selected Wishlist specifically because Simple Press publishes instructions for integrating Wishlist with SP.

I’ve followed the instructions at https://simple-press.com/documentation/codex/faq/problem-with-post-edit-buttonow-to/problem-with-post-edit-buttonow-to-configure-simple-press-with-membership-plugin/ and it just isn’t working.

Communication between Wishlist and SP is completely broken.

I did the following:

I have a test discussion board with four SP forums. Two of the forums are set for Standard Access for “Members”. Two of the forums are set for Standard Access only for a custom group named “Espresso”.

What I want is Espresso to be a paid subscription level that allows access to certain private forums.

User subscribes, they must be able to automagically see the  membership required sections. User cancels payments, boom, the membership required sections vanish from their view. No admin intervention, driven completely from Wishlists’s membership engine.

I followed the steps in that “how to config” page religiously. I installed a plugin called “WPFront User Role Editor” and I removed all unnecessary custom  roles. I created a new WP role called Espresso. I mapped the role in Wishlist to a Wishlist member level called Espresso. I mapped the WP role “Espresso” to the Espresso role in Simple Press. I checked and it’s set that way.

Basically, none of the role communication stuff is working in any way how the instructions imply it should. Here’s the test I ran:

– Say the test member account starts out as only a member of Espresso usergroup in SimplePress.

– Setting that user’s Wishlist membership to “Espresso” (as a credit card signup would do) does nothing role wise. SimplePress still only sees “Members” as the single membership level.

– Then I manually set the users’ WordPress Role (field) in their WP profile to “Espresso”. Hallelujah, the membership is reflected in Simple Press. This is the ONLY feature that works right.

– If I manually reset the user’s WordPress role in their WP profile to “Subscriber”, and they have no secondary role set, the membership in SImple Press stays set with Espresso. It’s not removed in SP.

I suspect that the failure of Wishlist to change the WordPress role is a Wishlist problem and I’ll take that up with them.

But even if Wishlist were updating the role correctly, your forum doesn’t correctly track the change in the user role by removing the forum/board membership.

I can only remove the forum membership by going into the SimplePress level user profile and manually removing the membership with the “Leave Usergroup” checkbox.

The failure of the Simple Press membership to update in accord with the WordPress role seems to be SimplePress’s issue.

I can attach screen shots to prove which configuration values are set.

Any ideas?

(I really wish this integration wasn’t so bloody complicated with multiple types of roles communicating across plugins. Seems very fragile. )

bump?  a reply would have been just fine…

we have many, many users, including ourselves, that use simple press and wishlist together… they do work quite nicely…  but when you have the core framework (wp) and two other plugins, it might not be a nice as one would like since none of the three were necessarily designed with the other in mind and all must try to co exist…

the key is to map a wishlist level to a wp role… and then an sp usergroup to the wp role…

you say when a member purchases and gets espresso, they get no wp role…  why not??  that is how wishlist should be configured… there is an option in wishlist for that level to map it to wp role…  if wishlist is not setting the wp role properly, then of course, communication with sp and wp is not occurring…  you prove this with your manual test…  we do not hook into wishlist, but wp.. so when a role changes, we change the sp usergroup…

why would you expect an sp usergroup to be removed if the wp role changes?  it would only change if you have their new wp role mapped to another sp usergroup and you ALSO have set the single usergroup membership option… users can have more than one sp usergroup membership… and the mapping to wp role is on role gaining, not losing… so if a user loses a wp role, there is no inherent change in sp usergroup.. unless, like I said, they gain another wp role mapped to an sp usergroup and the single membership option is enabled…

the key is to map a wishlist level to a wp role… and then an sp usergroup to the wp role…

you say when a member purchases and gets espresso, they get no wp role…  why not??  that is how wishlist should be configured… there is an option in wishlist for that level to map it to wp role…  if wishlist is not setting the wp role properly, then of course, communication with sp and wp is not occurring…  you prove this with your manual test…  we do not hook into wishlist, but wp.. so when a role changes, we change the sp usergroup…

why would you expect an sp usergroup to be removed if the wp role changes?  it would only change if you have their new wp role mapped to another sp usergroup and you ALSO have set the single usergroup membership option… users can have more than one sp usergroup membership… and the mapping to wp role is on role gaining, not losing… so if a user loses a wp role, there is no inherent change in sp usergroup.. unless, like I said, they gain another wp role mapped to an sp usergroup and the single membership option is enabled…

Exactly one fact in your reply was extremely helpful.

“you ALSO have set the single usergroup membership option.” was the key. After I read your reply I selected that option in Simple Press for user groups.

When I manipulate the WordPress role of a user in the admin control panel, the Simple Press user changes between “Member” and the special group “Espresso”. The Simple Press end is working as I’d expect.

The broken or unclear part of my setup is now between WordPress and Wishlist, communicating the user level to the WP role. I’ll take that up with their support.

Thanks.

glad we are getting a bit closer…

just checking, but are you sure each wishlist level is mapped to a unique wp role?  not familiar with the wp role creating plugin you are using, but adding/removing wp roles is quite common…

when wisthlist adds a user to a level, if it has a corresponding wp role, the role does get set – tested it this morning…  this is whether through purchase or wishlist manual setting from the wishlist members panel…  when wp role is changed, it fires an action and SP works on that action…  if the wp role does not change, we wont know about it..

I do have some code that keys on wishlist levels changing (add or removed) that I can share…  we use the wp role of subscriber for all wishlist levels…  then manage the sp memberships manually via the wishlist hooks…  but that is because of other things we do…  I dont know of anyone else doing what we do…

Thanks for the help… Would it help to diagnose this if I posted some screen shots of the setup screens that are involved at the Wishlist, WP and Simple Press levels?

I’m doing what you’re describing although I only need one Wishlist level, the single paid “Espresso” level.

wishlist is just one of many membership plugins… and all do things differently (of course and unfortunately)…

so here is some quick custom code for catching wishlist actions directly, if you want…  example has four wishlist levels, but think its pretty straight forward what is going on…

add_action('wishlistmember_add_user_levels', 'sp_wl_add_levels', 10, 2);
function sp_wl_add_levels($id, $levels) {
    $rank = '';
    $usergroup = '';

    $level = current($levels);

    # get special rank and usergroup id from level
    if ($level == 111111) { # www
        $rank = 'www Member';
        $usergroup = 1;
    } else if ($level == 222222) { # xxx
        $rank = 'xxx Member';
        $usergroup = 2;
    } else if ($level == 333333) { # yyy
        $rank = 'yyy Member';
        $usergroup = 3;
    } else if ($level == 4444444) { # zzz
        $rank = 'zzz Member';
        $usergroup = 4;
    }

    # add to special rank that matches membership level
    if (!empty($rank)) {
        # remove existing special ranks
        sp_delete_special_rank($id);

        # add in new special rank corresponding to new level
        sp_add_special_rank($id, $rank);
    }

    # add to sp usergroup that matches membership
    if (!empty($usergroup)) {
        # remove current usergroups
        spdb_query('DELETE FROM '.SFMEMBERSHIPS." WHERE user_id=$id");

        # add in new usergroup corresponding to new level
        sp_add_membership($usergroup, $id);
    }
}

# when wishlist removes user levels, adjust our special ranks and membership accordingly
add_action('wishlistmember_remove_user_levels',    'sp_wl_remove_levels', 10, 2);
function sp_wl_remove_levels($id, $levels) {
    $rank = '';
    $usergroup = '';

    # get special rank and usergroup id from level
    if ($level == 111111) { # www
        $rank = 'www Member';
        $usergroup = 1;
    } else if ($level == 222222) { # xxx
        $rank = 'xxx Member';
        $usergroup = 2;
    } else if ($level == 333333) { # yyy
        $rank = 'yyy Member';
        $usergroup = 3;
    } else if ($level == 444444) { # zzz
        $rank = 'zzz Member';
        $usergroup = 4;
    }

    # remove from special rank that matches membership level
    if (!empty($rank)) {
        # remove existing special ranks
        sp_delete_special_rank($id);
    }

    # remove sp usergroup that matches membership
    if (!empty($usergroup)) {
        sp_remove_membership($usergroup, $id);
    }
}

one thing to remember, is that when a user membership expires in wishlist (if time based), the user retains the wishlist level but are just marked expired…  so you wont get a level change (or wp role change)…  you may have to cater for that directly… 

Wow! Thanks for the code sample.

So it looks like you’re hammering Simple Press’s usergroup level when the user’s Wishlist level changes. So this completely avoids the issue of the WordPress role as an intermediary.

yes…  I mentioned this earlier because of other things we are doing… and because of how wishlist handled expirations – or rather how it leaves expirations in same level…  we dont use wishlist to protect the forum page, just simple press permissions…

just holler if you have questions with the code…  if needed, can give you an example code fragment for checking for expirations and adjusting memberships too…