Can't crack the structure I need here. Help?

[kennymcnett]

I can't crack how to set this up. I've been banging my head against it for more than a week. I hope you can help.

Scenario:
1. Sell single post access each for 4 days.
2. Sell "Special" access to some posts forever (or for a time limit--say, 30 days--it doesn't matter).
3. Sell "Premium" access to all posts--*except* "Special" posts--for 60 days.

My solution
1. Needs an EOT, so I have to use a subscription modification button + ccap. It goes from (Level 0) to (Level 1+ ccap).
2. PROBLEM: Need to use a ccap for "Special", I don't see how to limit this to 30 days without affecting the ccaps from #1. If I use a Buy Now ccap for this, and the user is currently Level 1, it will disappear when the user downgrades (which is automatically 4 days after a #1 purchase). Alternately, if I use a sub mod button + ccap, the ccaps from #1 will last as long as #2 is in effect.
3. Upgrade via sub mod button to Level 4. My php grants access to any post if the user has Level 4 and the post does NOT have the #2 "Special" ccap. Alternately, I could make this just like #1, but with a one-year EOT.

Downgrading is a problem because it causes the ccaps to disappear. If a user buys a ccap at Level 1, then later upgrades to Level 4, then downgrades back to Level 0, does the user keep the ccaps? What if they downgrade back to Level 1?

What am I missing here? Thank you in advance!

[Eduan]

Have you tried using specific post/pages restrictions?
http://www.s2member.com/specific-posts-pages-video/

[kennymcnett]

@Eduan, the problem with post/page restrictions is that they're mutually exclusive from subscriptions. So, while I could restrict access to each post, I would need to duplicate that content to make it available to a sitewide all-access subscription. Content duplication is, for so many reasons, not okay for this project (or in general).

[kennymcnett]

I've sort of worked out another solution, but I still have the ccap downgrade question:

If a user has ccaps purchased via Buy Now buttons while a Level 1 subscriber, and that user downgrades his account from Level 1 to Level 0, does the subscriber lose those Buy Now ccaps?

[Eduan]

Try this post:
viewtopic.php?f=4&t=15423&p=44833&hilit=conflict#p44833

Hope this helps.

[Jason Caldwell]

I've sort of worked out another solution, but I still have the ccap downgrade question:

If a user has ccaps purchased via Buy Now buttons while a Level 1 subscriber, and that user downgrades his account from Level 1 to Level 0, does the subscriber lose those Buy Now ccaps?

This is VERY advanced. For further details, please check your Dashboard:
s2Member -> API Scripting -> Custom Capabiities.

Dashboard, see: s2Member -> PayPal Buttons -> Independent Custom Capabilities

With s2Member, you can sell one or more Custom Capabilities using Buy Now functionality, to "existing" Users/Members, regardless of which Membership Level they have on your site ( i.e. you could even sell Independent Custom Capabilities to Users at Membership Level #0, normally referred to as Free Subscribers, if you like ). So this is quite flexible.

Independent Custom Capabilities do NOT rely on any specific Membership Level. That's why s2Member refers to these as `Independent` Custom Capabilities, because you can sell Capabilities this way, through Buy Now functionality, and the Customer's Membership Level Access, along with any existing paid Subscription they may already have with you, will remain completely unaffected. That being said, if you intend to charge a recurring fee for Custom Capabilities, please use a Subscr. Modification Button instead; because Independent Custom Capabilities can only be sold through Buy Now functionality.

Related specifically to your question... ( the answer is yes )

Independent Custom Capabilities are added to a Customer's account immediately after checkout, and the Customer will have the Custom Capabilities for as long as their Membership lasts, based on their primary Subscription with your site, and/or forever, if they have a Lifetime account with you.

In other words, Independent Custom Capabilities will exist on the Customer's account forever, or until an EOT ( End Of Term ) occurs on their primary Subscription with you; in which case s2Member would demote or delete the Customer's account ( based on your EOT configuration ), and all Custom Capabilities are removed as well.

[kennymcnett]

Thanks for your response Jason. I definitely looked over you documentation (and really appreciate its detail) before I asked the question. To your point here, how is the "Primary Subscription" determined? In my project, all users are first registered as lifetime Level 0 before they make any purchase. Then they can buy ccaps via Buy Now or upgrade to a Level 1. If the Primary Subscription is their first subscription, then I'm in the clear because their ccaps will never expire unless they cancel their account completely, even if they upgrade/downgrade to other tiers. However, if their Primary Subscription is equal to whatever their current membership level is at the time they purchase a Buy Now ccap, then I see they would lose that ccap if they modified their subscription level.

So, back to the question: what is the "Primary Subscription" exactly?

Thanks!

[Jason Caldwell]

Thanks for the follow-up.

The term "Primary Subscription" in this context is referring to
the Subscription ID that s2Member records in the Customer's Paid Subscr. ID field ( screenshot below ).

Specific Post/Page purchases, and Independent Custom Capability purchases are one-off purchases, and s2Member will not record a Paid Subscr. ID for those types of transactions. A Paid Subscr. ID is only recorded by s2Member, when/if a Customer pays you for Membership "Level-based" access.

When we refer to a "Primary Subscription" in this context, we're talking about any payment plan that a Customer signs up for, which provides the Customer with Membership "Level-based" access to your site, on a fixed-term, recurring basis, or is otherwise connected to a possible EOT ( End Of Term ) event.

For instance, if a Customer is paying for Level #1 access on a monthly basis; they might cancel at some point in the future, which would result in an EOT ( End Of Term ), and an EOT event will cause a loss of all Custom Capabilities. Or, if you sell a Customer Buy Now access to Level #1, good for 6 months only, an EOT event would be triggered six months later, also causing all Custom Capabilities to be lost.

Rule of thumb. If your Customer is going to trigger an EOT event, they will eventually lose all of their Custom Capabilities, whenever the EOT event occurs. Otherwise, they will have their Custom Capabilities forever. Upgrading/downgrading from one Memership Level to another does NOT cause a loss of Custom Capabilities. The only thing that causes a loss of Custom Capabilities, is an EOT event.

[kennymcnett]

Jason, thank you for this answer. It appears, from your explanations, that independent custom capabilities aren't actually independent, since they are affected by an EOT regardless of whether that ccap was purchased in conjunction with the level subscription that has the EOT. I've really wanted to use s2member and I've dived in deep integrating it into my wordpress site by writing automated button creation and ccap permissions.

But, unfortunately, it looks like s2member isn't quite ready to accommodate the setup I need. (I really hope I'm wrong.)

I've been able to refine the scenario explanation a bit. Here's what I need:
1. Sell individual posts (using a ccap, one-time payment, lifetime access)
2. Sell access to all of those posts (subscription level, recurring payment)
3. Sell access to a separate group of posts, not included with a subscription from #2. (ccap, one-time payment, lifetime access)

The problem is this, for example: A customer purchases some posts individually, then buys a monthly subscription access. After a month, they decide not to renew their subscripion, so it hits an EOT. What the user would expect to happen is that their account reverts to a Level 0 account and retains the ccaps they purchased previously (before becoming a subscriber). But what really happens is that the EOT triggers the loss of all ccaps, and now they're mad because they don't have access to what they already paid for.

Even if I could that issue, the second problem is, for example: A monthly subscriber with recurring payments decides to purchase #3, a ccap for another group of posts not included in their subscription. Then they don't renew their monthly subscription, so their account hits an EOT. Because of the EOT, the ccap they purchased while a subscriber is now lost, resulting in an angry customer.

I sure hope I'm wrong because I love the flexibility of s2member, but I can't see a way around it. I've been digging in for weeks now and I'm at my wit's end.

If there's not out-of-the-box solution, is there a way I can turn off the loss of ccaps with an EOT (that won't be overwritten with future upgrades to s2member core files)?

Thanks, Jason.

Kenny

[Jason Caldwell]

Thanks for the follow-up.

Yes, I definitely understand what you're running into. You're not the first to report this either. Independent Custom Capabilities are a relatively new feature for s2Member, and while the structural design for Independent EOT Times has also been implemented, it's not 100% ready to go yet.

This IS definitely something that's coming before the end of 2011 though. It's the top thing on our TODO list at the moment, along with other improvements related to EOT Times and email notifications.

---

There is NOT currently a way to hack s2Member in this regard. At least, NOT without modifying the source code directly. However, given the updates coming soon in this area, I wouldn't fret too much over that; because you're going to see new UI panel controls over this aspect of s2Member in a future release.

Until then, here is how you can deal with your immediate issue.

Open this file in your installation of s2Member v111017:
/s2member/includes/classes/auto-eots.inc.php, at line #148 find this section of code:

Code: Select all

foreach ($user->allcaps as $cap => $cap_enabled)
    if (preg_match ("/^access_s2member_ccap_/", $cap))
        $user->remove_cap ($ccap = $cap); 

And comment this out to achieve what you need:

Code: Select all

#foreach ($user->allcaps as $cap => $cap_enabled)
    #if (preg_match ("/^access_s2member_ccap_/", $cap))
        #$user->remove_cap ($ccap = $cap);                 

* This way Custom Capabilities are NOT lost during an EOT event. They will remain.

---

Moving forward, please keep an eye on our Changelog with each update. When this is ready-to-go, we'll make a prominent announcement in the Changelog, and also here: viewforum.php?f=46

[kennymcnett]

Thank you, Jason. I'm giving this a go. Looking forward to the official update.

[kennymcnett]

Jason, this is working wonderfully. What's the best way for me to future-proof it against updates? I'm already faced with wanting to update to the latest version (for the download counts--very excited about those!!), but I'll lose this change and have to re-make it each time I update.

[Jason Caldwell]

Thanks for the follow-up.

Jason, this is working wonderfully. What's the best way for me to future-proof it against updates? I'm already faced with wanting to update to the latest version (for the download counts--very excited about those!!), but I'll lose this change and have to re-make it each time I update.

So sorry, there's really no Hook/Filter available in this regard yet. The hack I posted above would need to be done through a direct edit of s2Member's source code in this case. So, not really a way to future proof this modification. Although a future release will include this functionality, so you shouldn't need the hack in the future. See also this article on the best ways to hack s2Member: viewforum.php?f=40#src_doc_overview_description