|
Pedro Ordenes
|
December 19, 2017 at 10:41 am
Hi there! I use s2member to unlock member-level pricing for paid members. It used to work so that, for example, someone that has a membership that expires in June 2018 could only access member pricing for events taking place through June, but events in July and beyond would not show member pricing.
Now, no matter the membership term length, they have access to the entire calendar of member pricing for the duration of their term. So theoretically, someone can buy the cheapest and shortest membership tier, and stock up on a year or more’s worth without paying for the membership term that should cover them. (Does that make sense?)
I don’t know when this changed but we have our holiday sale on and I noticed people stocking up on far more than they typically should be able to. Is there a way to change this?
Thanks for your help and happy holidays!
|
|
Tony
|
December 20, 2017 at 5:00 am
Hi there and Happy Holidays 🙂
Blocking registrations on events outside of the S2 membership is not something Event Espresso has ever done as far as I am aware, have you previously worked with a developer to add some customizations to your site?
|
|
Pedro Ordenes
|
December 20, 2017 at 11:02 am
Nope! Weird. Maybe it was something on s2member’s side then. Around the time we made the membership & EE4 implementation, we got a lot of emails about not being able to access membership pricing outside the term and it was great because it kept membership purchases high, and now there is naturally a drop. I’ll check s2member’s support. Thanks!
|
|
Tony
|
December 20, 2017 at 11:07 am
Hmm, yeah that is strange.
So when a member viewed the event outside of their membership what did they see for member tickets?
What capability did you set on the ticket?
I don’t think S2 member will be able to help as if it’s the tickets that were hidden (not the event post itself) that would be an EE feature no S2, but again that’s not something we have added to the plugin so will take some digging to figure out whats going on.
|
|
Pedro Ordenes
|
December 20, 2017 at 11:24 am
So if a current member viewed an event that took place after their membership was set to end, it had the members only pricing message. The capability set was the access level of that membership, like access_s2member_level1.
We had people email us to voice some choice words that we had finally closed that loophole a couple years back, so somehow it worked that way for a while. Maybe it was a fortunate glitch 🙂
Thanks for digging, I appreciate it!
|
|
Tony
|
December 21, 2017 at 5:11 am
Yeah, so to be honest, it sounds like a happy accident that it worked that way for you previously.
So if a current member viewed an event that took place after their membership was set to end, it had the members only pricing message.
That text is added using the WP user integration add-on and the only check it does is to confirm the user has the minimum required capability set on the ticket, if not that message is shown. It’s possible that it worked because of the caps you used on the tickets but again that would be weird as S2 ‘stacks’ its capabilities (level 2, has all of level 1 + more and so on).
We don’t add code to EE core (or its add-ons) to allow it to work with specific plugins and prefer to add a filter which can be used to alter the functionality if needed. The end of term date for S2 would be custom to S2 and would need code to specifically check for that so it’s not a part of EE.
So having said that, it’s possible to do what you are trying to do and if you only used fixed payments (rather than recurring subscriptions) would be farily straightforward. Pull the EOT from the current user and compare that to say the datetime start date of the first datetime assigned to the ticket the user is trying to purchase, but it would be custom and you mentioned you’ve not had any custom development so I don’t know why/how that worked previously.
|
|
Pedro Ordenes
|
January 2, 2018 at 9:05 am
We just have one-time payments, not recurring subscriptions, but unfortunately I wouldn’t know how to code that myself so I guess we’ll have to go without. Thanks for looking into it!
|
