Cristián Lávaque

Hi Michelle.

You have the theme or another plugin, affecting the content filtering, and it’s adding HTML linebreaks where it shouldn’t (e.g. after hidden form fields or HTML comments). This is breaking the form’s HTML, and causing you to have that error on PayPal’s side.

If you already tested the theme changing to the default one and still have the issue, then try the plugin tests, please. Knowledge Base » Common Troubleshooting Tips

That is not really an enforced limit, more like a suggested one. The import tool won’t stop you if you want to try adding a thousand. The risk you run is having memory or timout issues. Test things out and see how many your server can handle. :)

How can you make s2Member include this? It seems to me that this is something s2Member should be doing. Why isn’t it? You have said…

That’s because of the type of button used. He just mentioned having noticed that missing as something that’d cause the Tracking API to not work ideally. When he said it, he had not yet realized that you aren’t using the button shortcodes, but he then followed up with his last reply when I mentioned it to him.

I am using a PayPal hosted button because the ones created by s2Member put in about 4 inches of blank space ahead of them and cannot be fixed.

Like I said before, this would be caused by the theme or another plugin affecting the way content is filtered, causing a lot of HTML line-break tags where they shouldn’t be (like after hidden form fields or HTML comments).

Did you do the theme/plugin tests I suggested to find which is causing this problem in order to solve it? Knowledge Base » Common Troubleshooting Tips

I do not know how to custom hack a file, so that is not happening. No hacks on this site. I have only worked within the boxes and fields of s2Member user interface.

Again, he mentioned this when he still had not understood you are using the PayPal created buttons. He was mentioning possible things that could cause the behavior.

I bought s2Member because it integrated with ShareASale and Aweber. There must be a way for it to work and the fault simply cannot be other plugins.

Sure, they work. Yes, another plugin could affect this, as in the content filtering adding line-breaks in the HTML form causing it to display wrong and even fail to work in some cases.

The ball is back in your court. I really need more help here. How can you make s2Member work properly?

If you could please do the theme/plugin tests I pointed to, so we can spot what’s causing the content filtering to behave like that and find a solution. I’ll wait for your update on this. :)

Jason pointed me to the [hilite mono]sub_account[/hilite] attribute in the ccBill shortcodes, that I wasn’t aware of.

You can set this up in the following way:

In the s2Member configuration panel enter 0000. [hilite path]WP Admin -> s2Member -> ccBill Options -> Account Details -> Sub Account[/hilite]

When creating a ccBill Button Shortcode that needs to use Sub Account 0001, please use the [hilite mono]sub_account[/hilite] attribute to override the default value of 0000, by setting [hilite code]sub_account="0001"[/hilite]. [hilite path]WP Admin -> s2Member -> ccBill Buttons -> Shortcode Attributes -> sub_account[/hilite]

[hilite mono]sub_account=""[/hilite] Optional. This defaults to the ccBill® sub-account which you’ve configured s2Member® to use. However, if you are operating multiple ccBill® sub-accounts, this can be used to construct a payment button designed to integrate with a specific ccBill® sub-account (e.g. making it possible to integrate s2Member® with multiple ccBill® sub-accounts, all from a single s2Member® installation).

The note to developers regarding licenses may be of interest: http://www.s2member.com/prices/#s2-terms-license-types

Please note… if you’re a developer, your clients will need to purchase their own Single-Site and/or Unlimited-Site License. We will not support s2Member® Product instances on domains that you do NOT own and operate yourself. We invite all developers to join our affiliate program, and refer their clients to s2Member.com, where your clients may purchase an s2Member® Product of their own. This also gives your clients access to future releases.

Hi Chris.

I’m going to forward this to Jason. Could you please send us the site info for him to review your installation? s2Member® » Private Contact Form

You were logged out of your admin account when you did the test, right? The log entry looks okay.

Did you get an email from the signup notification after the test?

Could you submit your site info in case Jason would like to take a look at your installation when he sees my message? s2Member® » Private Contact Form

Pirco, the billing update pro-form should help. [hilite path]Dashboard -› s2Member® -› Authorize.Net® Pro Forms -› Billing Update Forms[/hilite]

An Update Form can be provided to existing Members, as a way for them to update their billing information; without modifying their existing paid Subscription in any way. For instance, a Customer may need to update their billing information, because their credit card is expiring, or because they moved their bank account.

There are no plans for s2Member to manage the subscription, since it’s mean storing the card info locally, which carries with it a lot of security complications, so we leave that to the payment gateway. I mention this because it seemed like you were asking for something like that too.

Hi Michelle.

Yes, you can do that. Please see the documentation here: [hilite path]Dashboard -› s2Member® -› API / Scripting -› Content Dripping[/hilite]

I hope that helps. :)

Thanks for confirming that the PayPal integration is working right. Could you please enable logging, if you didn’t have it, do a test 1 cent transaction and get the log entries from all the log files created? I’d like to take a look just to confirm that nothing seems out of place.

About when it’d be displayed and where the pixel should be, this is from the documentation:

Signup Tracking Codes will only be displayed once for each Member. Signup Tracking Codes are displayed right after a “new”, “paying” Member, signs up successfully through your Payment Gateway, regardless of whether any money has actually been transacted initially. In other words, Signup Tracking Codes are displayed anytime a “new”, “paying” Member, signs up, even if you provided them with a 100% Free Trial Period ( e.g. no money is being transacted intially ).

s2Member will display your Signup Tracking Codes in one of four possible locations… 1. If possible, on the Thank-You Return Page, after returning from your Payment Gateway. 2. Otherwise, if possible, on the Registration Form, after returning from your Payment Gateway. Note. If you offer a 100% free Trial Period, Tracking Codes will be displayed in location #2 when using PayPal® Standard Button integration. 3. Otherwise, if possible, on the Login Form after Registration is completed. 4. Otherwise, in the footer of your WordPress® theme, as soon as possible ( immediately with s2Member Pro Form integration ); or after the Customer’s very first login.

So even if you didn’t find it in the thank-you page, s2Member may still fire the pixel in one of the other listed ones.

I’ll ask Jason what could be done to test if the Tracking API is working correctly other than looking for the pixel in those places.

About using the Notifications API, it may be a good idea, but like the documentation says, you may need to work at it a little more. I’m not familiar with Share-a-Sale’s 3rd-party calls. Maybe their support rep can tell you what the URL should be like? The signup notification has replacement codes similar to the tracking one, and they’re documented below the text area where you enter the URLs.

Here’s a video that explains both APIs, in case it helps: Video » s2Member (API Tracking/Notifications)

By the way, it doesn’t look like you do, but did you add the post-registration auto-login by chance? I ask because it causes these APIs to not work, which is fine if you don’t need them, but troublesome if you do.

I then went into My Account and used that Pro Form unsubscribe … a message popped up for me to unsubscribe in PayPal… I clicked the link to take me there, and got the message that no subscription could be found… (is that because the first month is free… and if so, am I going to have to be charged and then unsubscribe?) (hope not)…

No, even if there’s a trial a subscription is created. You don’t need to wait to be charged before unsubscribing.

Weird that the subscription wasn’t found. So you paid with a card in the pro-form and then tried to unsubscribe with the cancellation pro-form but got sent to PayPal with the error that the subscription wasn’t found?

If that wasn’t the case, could you walk me through the process, showing me the shortcode for the pro-form you used, what payment option you used, and what happened step by step after that? Screenshots would help too.

I’d like to test it via credit card… but would use the 1st month free again, so not sure how that would test, given my results above… Suggestions? (the other options are a $250 and $400 purchase first).

You can modify the amounts in your shortcodes to test with 1 cent transactions.

SO, I removed the Pro Form unsubscribe and left the other PayPal “unsubscribe button” in place for now… but that is the one not working for Pro Form subscribers…as you’ve indicated it probably wouldn’t.

Right, the PayPal Standard button won’t work for PayPal Pro subscribers, most probably not for Express Checkout either.

Is it possible or viable to have two options for unsubscribe or would that be confusing? (“if you registered prior to THIS date, use this button and ALL after this date, use the unsubscribe form link below”)… (I ask because I don’t know if I can feel confident moving those 35 or so beta users which are on standard paypal…)

You could probably write a conditional that checks the user and shows one or the other based on that. Or you just leave the decision up to the user, but they’ll most likely pick the wrong one a lot of the times.

If you remove the PayPal Standard subsr. ID from their profiles, as I suggested to avoid errors now that the integration is with PayPal Pro, the conditional could check if the user has a level higher than 0, but doesn’t have a subscr ID, then show the button, else the pro-form. Or something like that.
Video » s2Member (Advanced Conditionals)
[hilite path]Dashboard -› s2Member® -› API / Scripting -› PHP/API Constants[/hilite]

With all your advertising that you don’t need to be a coder to do this stuff… not really true!

Well, one doesn’t need to be a mechanic to drive a car, but if you want to modify the machine (or close to it), then you either know/learn a bit about it, or get someone that does. :)

It’s not usual that a site owner starts getting subscribers with one PayPal account and then changes to another one. Since s2Member integrates with only one PayPal account at a time, having users from another account does cause inconveniences for now. We’re working on how to improve this and we may release a solution in the future.

(if you have someone you could refer me to, who would be available to go in a get this stuff in order, I would appreciate it.) Again, thanks for your help.

No one in particular, but we usually suggest posting a job in freelancer sites like jobs.wordpress.net, elance.com or odesk.com.

I hope that helps. :)

I understand what you mean, but when I say they aren’t critical, I really mean they won’t cause trouble. That said, we plan to take care of all of these eventually. We’re doing a complete rewrite of the plugin, and care is being taken to avoid these. Since we’re rewriting the plugin, and these warnings aren’t really important, we haven’t spent more time to clean them up in the current s2Member.

The page index warning is about this line:

[hilite pre_code]
if (!$page || "*" === $page || $pagenow === $page || $_GET["page"] === $page)
[/hilite]

If page were in the GET array and exactly equal to the value of the variable $page, it’d be true in that condition, but it is possible that ‘page’ is not in the GET array at all, which normally means that condition is false, but PHP would still warn that it wasn’t defined at all. To avoid that, it’d have to first check if $_GET[‘page’] is set and then check the value. Try editing that line so it’s like this and see if the warning goes away:

[hilite pre_code]
if (!$page || "*" === $page || $pagenow === $page || (isset($_GET["page"]) && $_GET["page"] === $page))
[/hilite]

About the $cache_needs_updating var not being defined, it’s a similar problem. There are a few conditionals before that line where the variable can be set to true, but if neither one happens, then the var remains undefined. It should be first set as false and then changed to true if needed.

I’ll forward this to Jason so he can comment on it if needed. :)