Cristián Lávaque

Hello John.

Could you post a link to the page you set for the Membership Options and a page that you protected?

Also a screenshot of your panel for the Membership Options Page setting, please.
[hilite path]Dashboard -› s2Member® -› General Options -› Membership Options Page[/hilite]

Thanks!

Hello Mike.

s2Member doesn’t manage access to the admin side of WordPress, only the front end.

You may want to look into WordPress roles to see how you could give those users the special permissions.
http://wordpress.org/extend/plugins/user-role-editor/

I hope that helps. :)

Hi Grace.

The custom fields are all stored together in the usermeta table as a serialized array. This post by Jason will give you more info and an example of how to query a field there: http://www.primothemes.com/forums/viewtopic.php?f=4&t=15658&p=48878#p48878

That said, we’re planning that the coming major release of s2Member will make it possible to set a custom field as unique, so that users won’t be able to enter a value that was already entered in another account. This should help in your case.

Cool. :)

But does it happen while s2Member is inactive? If so, it’s certainly another plugin causing it.

If it happens only with s2Member active, then there may be another plugin conflicting with s2Member. Please test this deactivating other plugins one by one, and trying after each if the problem continues.

Please, let me know how it goes.

The cron job hasn’t made any difference. No EOTs are being set when CCBill customers cancel. I’m having to set them manually. Any suggestions?

Is that still happening with new EOTs or are you waiting for old ones to trigger the behavior? Jason mentioned above that any EOTs that occurred more than 48 hours ago would be missed, due to the way ccBill’s DataLink service works.

OK, I understand now.

You’re basically thinking that the access is tied to the account and to prevent the user from using that access, he has to be prevented from getting into that account.

The way I’m thinking it is that access is something added to the account, and can be taken away. So the user can keep his account, but you’d be in control of the access you granted him, and can take away from him if you want.

Good, I think that what he have in mind will work then.

Thanks for your feedback!

Ah, I understand now what you meant. Thank you very much for showing me the screenshots.

I agree that it should be the label the one shown there. I’ll mention it to Jason.

I see. Could you compare the plugins you’re using in the local server that you aren’t using in the online one, and deactivate them? One of them may be causing a shortcode parsing problem. If not, try changing the theme to the default one. All this as a test, of course, just to find where the problem is so you can then figure out how to fix or replace it.

Hello Jeff.

You’d have to customize that using the Membership Option Page variables.
[hilite path]Dashboard -› s2Member® -› API / Scripting -› Membership Options Page Variables (MOP Vars)[/hilite]

There you’ll find enough info to know what page to redirect the person back to after login. You can use the redirect_to var in the link to the login page, for example: [hilite mono]/wp-login.php?redirect_to=/?p=123[/hilite]

I hope that helps. :)

Well, I guess you can at least make the suffix really short (1 char) and seem part of the code.

I’ll ask Jason about the hook, but I just remembered the registration access links, which you could send to those users so they can register.
[hilite path]Dashboard -› s2Member® -› PayPal® Buttons -› Registration Access Links[/hilite]

Let me know if that helps. :)

Great. :)