Cristián Lávaque

Hi Joycellyn.

I would like to remove a section title – namely the one referring to the cpatcha. Where do I locate the file to do this, please?

You could remove it with CSS using the ID [hilite mono]s2member-pro-paypal-registration-form-captcha-section-title[/hilite]. Something like this in the theme’s styles file:

#s2member-pro-paypal-registration-form-captcha-section-title {display: none;}

To edit the template:
Pre Sale FAQs » Is it possible to modify s2Member® Pro Form templates?
[hilite path]Dashboard -› s2Member® -› PayPal® Pro Forms -› Shortcode Attributes -> template[/hilite]

I’d also like to remove the text – ‘signup now it’s free’ as the font doesn’t fit the rest of the form.

You can edit that in the free registration pro-form’s [hilite mono]desc[/hilite] attribute. [hilite path]Dashboard -› s2Member® -› PayPal® Pro Forms -› Shortcode Attributes -> desc[/hilite]

In debug mode there will be notices of several things that aren’t critical.

What caching plugin are you using? Do you get that same error using another one?

Hi Amanda.

This may be because the missing accounts have not been activated (BuddyPress adds an account activation step). I remember this users count discrepancy coming up in the past with BuddyPress and it was because of that.

Hi Eric.

adding Custom Registration/Profile Fields in s2member is only to be used within s2member, right, or can i add fields and map it to the wp-user-profile?

The s2Member custom profile fields would be shown in the WP profile as well, yes.

The custom attribute in your shortcode seems wrong, since it has the other address. I’d generate a new shortcode from your test installation, so s2Member gives you the right value for it. [hilite path]Dashboard -› s2Member® -› PayPal® Pro Forms -› Membership Level # Forms[/hilite]

I see you mention the Sandbox. I’ve seen it sometimes cause problems that wouldn’t be present in live transactions, so I prefer to avoid it and instead test with live 1 cent transactions.

I’m glad it’s working now. :)

But I do wonder what the problem was…

Since it’s working, then it seems the ccBill integration is correct.

Keep logging enabled so that when/if it happens again, you can look at the entries for more info to help us determine what the cause may be.

Hi Christine.

That’s all I have, unfortunately… except that I’m pretty sure he signed up with a credit card, not via Paypal… is there a way for me to confirm that one way or the other inside s2?

If he subscribed with a PayPal button, then it’d be PayPal Standard and, unless you hired the Enhanced Recurring Payments (ERP) upgrade, he’d have been required to login to his PayPal account. He should be able to see the subscription in his account and cancel it from there, but if you did have ERP and he paid without logging into a PayPal, you’d need to cancel the subscription from your side.

We now have PayPal Pro working for sign ups… had some issues with it initially, so some beta members signed up via a more “manual” process via regular PayPal. This is likely going to be a separate issue for unsubscribe. We also got some IPN warnings when their monthly went thru… although it appears all the payments were successful.

This would cause trouble, because you’d have subscriptions from the previous PayPal Standard account, but your current integration be with the new PayPal Pro account. New subscriptions via PayPal Pro won’t be a problem, but older subscriptions would have the problem you described. Basically, the PayPal account you have integrated s2Member with needs to match the account the user’s subscription belongs to.

You’ll need to handle demotions manually for the old subscriptions, and remove the subscr. ID from their profiles so you don’t have the conflict happen. Or have them cancel that and resubscribe via PayPal Pro.

Here is the current short codes that resides on the MY ACCOUNT page…
When I looked thru S2, am wondering if we have the wrong one… but I have no idea how to test it.

The cancellation button would work for PayPal Standard subscriptions where the user logged in to his PayPal account to subscribe. Subscriptions created via ERP will need you to cancel it for them. Subscriptions created via PayPal Pro will need a cancellation pro-form. [hilite path]Dashboard -› s2Member® -› PayPal® Pro Forms -› Billing Cancellation Forms[/hilite]

P.S. In addition… a lady lost her credit card and needed to update her payment info… according to a notification from PayPal, it appears that was successful, but client said he never saw the payment go thru that failed earlier. Is it best for him to just ask for funds replacement manually and assume it will go thru ok next month?

I’m not sure I understand that question fully, but it seems you/he’d need to contact PayPal to ask them about it.

Right, you can translate other strings too. Search for the string in the s2Member files and there you’ll see the complete string you need to match, as well as the context string. There are editors that let you search in several files, I use EditPlus.

Got it.

The trial term and period were wrong in your shortcode, you have it as 1 month, when it should be the the days left in the month: [hilite code]tp="' . $days_left . '" tt="D"[/hilite].

You can try this:

[hilite pre_code]
date_default_timezone_set('America/New_York');
$days_in_month = date('t');
$days_left = $days_in_month - date('j');
$prorated_payment = number_format((10 / $days_in_month * $days_left), 2);
echo do_shortcode('[[s2Member-Pro-PayPal-Form level="1" ccaps="" desc="1A Membership: This month prorated @ $' . $prorated_payment . ', then $10.00/Month (recurring charge, for ongoing access)" ps="paypal" lc="" cc="USD" dg="0" ns="1" custom="www.healthsuccesscenter.com" ta="' . $prorated_payment . '" tp="' . $days_left . '" tt="D" ra="10.00" rp="1" rt="M" rr="1" rrt="" rra="2" accept="paypal,visa,mastercard,amex,discover,maestro,solo" accept_via_paypal="paypal" coupon="" accept_coupons="0" default_country_code="" captcha="clean" /]]');
[/hilite]

The regular pro-forum will be available all year around for new members. Sets EOT to ‘current-year/12/31′.

That’s fine.

The renewal pro-form will be available say during november-december only and only for current members.
Must set EOT to ‘current-year+1/12/31′.

Okay. This one would need a conditional around it to determine if time to show it or not.

So the forms will, at some point, be avaliable at the same time. Are there different hooks to use in the s2hacks-file for the renewal form, for setting the right form of EOT? Would it be a good idea to check if user is loged in and if month nov-dec then show the renewal form?

No need to use a hacks file. You can have a page accessible to Level 1 users (assuming that’s the paid access you sold), so only them would see this page. And in it you’d have a condition that checks the month and shows the renewal pro-form during November and December only.

Then it’s the third option, when a member don’t/ forgets to renew and gets demoted – then we need the upgrade pro-form/button or something similar? Does upgrades work differently?

Upgrade works just like the original sale, but when the user is logged in. So you’d have this pro-form in a page protected at Level 0 and you can have the pro-form inside a condition that checks if the user is at Level 0 and not higher. [hilite path]Dashboard -› s2Member® -› API / Scripting -› Simple/Shortcode Conditionals -> Example 3[/hilite]

[hilite pre_code]
[[s2If current_user_is(s2member_level0)]
Some content for Free Subscribers.
[/s2If]]
[/hilite]

Cool. :)

I can understand it can be confusing and exhausting to have these seemingly random problems, and what they imply. I’ll go over the symptoms you mentioned.

B. who we manually EOT and they continue to be charged and/or have member access

When you set an EOT manually, that doesn’t automatically end a subscription. It just tell s2Member to end access at that time, but the subscription is handled by the payment gateway, which doesn’t know about that. The subscription has to be ended in the gateway either by the user or you for it to stop. It’s possible that a few of the problems you mentioned, come from this assumption/mistake.

A. cancel and continue to be charged months later

When you say the user cancelled and continues to be charged, how did he cancel? Did he do it in the payment gateway? Or, if you have PayPal Pro or Authorize.Net, did he use the cancellation pro-form? Or did he call you to cancel it and you entered the EOT manually?

C. who stopped paying but are still listed as s2m level 1 or level 2

If the payment gateway stops receiving payments, then it’d notify s2Member and s2Member would set an EOT time, to trigger the auto-EOT behavior, which in your case is demote, if I’m not mistaken.

If the EOT never got set although the user stopped paying, then there would have been a communication error from the payment gateway and s2Member never found out.

The logs would help see better what happened with those particular subscriptions. [hilite path]Dashboard -› s2Member® -› PayPal® Options -› Account Details -› Logging[/hilite]

D. who can access member only content on the site AND on iTunes.

This goes together with the previous one, since not being demoted, the user would still have the access. Only those that have the required or higher level would have access to the restricted content, s2Member would not allow access to content restricted at a level higher than the user’s.

E. who are listed as Subscribers but continue to be charged

This would be possible for those for whom you set the EOT manually, but didn’t end the subscription in the payment gateway.

Hi George.

The code Jason covered in the video, was to show more things you can do with this, but isn’t required unless you have a more complicated setup than what s2Member does by default.

You can protect posts and pages with custom capabilities, simply entering the required custom capability into the s2Member box in the edit page.