Cristián Lávaque

OK, I found what I think is the problem, you still haven’t updated the thank-you page URL with the right one over at ClickBank. It has to be the one s2Member gives you or s2 won’t have a chance to set the cookie in the user’s browser to let him register an account.

His only other way to register is through the special registration link s2 sends in the confirmation email, which right now isn’t there either.

From the s2Member documentation for the ClickBank thank-you page: [hilite path]Dashboard -› s2Member® -› ClickBank® Options -› Thank-You Page Integration[/hilite]

You’ll need the URL for your Thank-You Page, which is:

http://socialmediatrainingsolutions.com/?s2member_pro_clickbank_return=1

It is also possible to bypass s2Member’s Thank-You Page all together, if you prefer. You can take s2Member’s Thank-You Page URL ( shown above ), and add [hilite mono]&s2member_pro_clickbank_return_success=http://...[/hilite] where the value can be set to a custom Thank-You Page URL that you prefer.

Which would be something like this:

http://socialmediatrainingsolutions.com/?s2member_pro_clickbank_return=1&s2member_pro_clickbank_return_success=http%3A%2F%2Fsocialmediatrainingsolutions.com%2Fthank-you-for-your-purchase%2F

By the way, your salespage only has one button generated by s2Member, the other buttons are regular ones that won’t work with s2Member properly because they lack the variables s2 adds/needs.

You have to make those changes or the process won’t work properly.

I hope it helps.

Right. That’s why I’d like to find a way to let him finish purchasing and after checkout, instead of just letting him register, have the option to login and add the recent purchase to his account. With this, though, there’s the risk of a person not completing the login after checkout and someone else using the computer to login/register to that same site. It’s not the likeliest situation, but a popular site in a public computer could see that happen. Anyway, we’re looking at this option, since it has the same risk that the current registrations do.

The ideal would be for the customer to already be logged in when he gets to the page where the option to buy is, so this doesn’t become a problem, that’s why it’s advised to protect at Level 0 the upgrade buttons/pro-forms, but I understand it’s a problem when a user is browsing the site, forgetting to log back in, and sees the salespages for visitors to join, and them starting a checkout there as if they weren’t already registered members.

Oh, right. I was thinking of matching Paypal for recurring customers, but of course, there are also the previously-registered ones who had not made a purchase. See why it is not MY department!

And there are those that are registered, but with an email address that isn’t the one they use for PayPal, too.

Yeah, one has to see all possible scenarios when creating these things, that’s why it takes a little time to get it all right, but we’re getting there little by little. :)

Thanks a lot for your valuable input, you’re great. And I can’t tell you how we appreciate people like you helping others in the community when you can. Very appreciated. We’ll keep doing what we can to improve the plugin to meet the needs of all you guys.

Right, it may be doable, but it’ll take a little work to get right.

Ideally, the person would not be taken off the checkout, cause each step will losses. That’s why having the registration after the payment is better. Logging in first is better because it makes sure the paid access gets added to his account.

One approach could be to have the order button with a couple of optional username and password fields, so if he has an account he logs in and starts checkout in one step, and if no login info is entered, then checks out and then registers.

That’s doable with the current s2. It’d be a two step process, although the user wouldn’t notice it. The button, instead of pointing to PayPal would point to the site, where some code you create for it checks the submitted form. If user and pass were entered, then log the user in, generate the PayPal link for that order and forward to PayPal. If the user and pass are empty, then just generate the link and forward to PayPal.

There’s also the case where the user entered a wrong password for that user, or a non-existent username, so that has to be taken care of as well.

Anyway, there are different things we can try, but we haven’t decided what yet. We are aware of the issue, so we’ll work on it. But thanks for the reminder. :)

Yeah, the same is true with the pro-form, since the pro-form will register the person too unless he’s logged in.

Added your request, and this is something I want to see happen too.

The way I’ve seen other sites do it, where you don’t have to login first, is when they have a cart where you add the products, but before the checkout they do ask you to login if you already have an account.

Could you give an example of a site that lets you purchase without logging in and then letting you add your purchased items to an existing account?

is sent as well! This is great!

Excellent! :)

However, the auto-generated login and password email does not arrive! That’s the big problem. Any idea why S2Member is sending the payment confirmation email but not the login/password email?

Do you mean the one WordPress sends after registration? The login and password email is sent after the person registered. Did you register the account before looking for that email?

By the way, s2Member makes it possible to customize the New User email WordPress sends on registration. [hilite path]Dashboard -› s2Member® -› General Options -› Email Configuration -> New User[/hilite]

I hope that helps. :)

Got your email with the logs and went through them:

Andreja:
The entry about he $60 purchase mentions registration, so it seems he wasn’t logged in to his account when he made that payment, which is why the ccaps weren’t added to it.

0 => 'IPN received on: Fri May 25, 2012 7:43:23 am UTC',
1 => 's2Member POST vars verified through a POST back to PayPal®.',
2 => 's2Member originating domain ( `$_SERVER["HTTP_HOST"]` ) validated.',
3 => 's2Member `txn_type` identified as ( `web_accept|subscr_signup` ).',
4 => 's2Member `txn_type` identified as ( `web_accept|subscr_signup` ) w/o update vars.',
5 => 'Signup Confirmation Email sent to: "Andreja xxxx" <xxxxxxxxxxx@gmail.com>.',
6 => 'Storing `payment` for Subscription via ( `web_accept` ).',
7 => 'Creating an IPN response for `subscr_payment`. This will go into a Transient Queue; and be processed during registration.',
8 => 'Storing IPN signup vars into a Transient Queue. These will be processed on registration.',

Sheila:
I found a transaction from the May 20, the previous one is Mar 5. The May 20th one is for $19.99 and also mentions registration, so I think she wasn’t logged in either.

Bernice:
Same.

Karen:
If you look at her entry for the $60 purchase that added the ccaps fine, you’ll notice how the entry is different than the problem ones for the other users.

0 => 'IPN received on: Sun May 6, 2012 1:52:07 am UTC',
1 => 's2Member POST vars verified through a POST back to PayPal®.',
2 => 's2Member originating domain ( `$_SERVER["HTTP_HOST"]` ) validated.',
3 => 's2Member `txn_type` identified as ( `web_accept|subscr_signup` ).',
4 => 's2Member `txn_type` identified as ( `web_accept|subscr_signup` ) w/ update vars.',
5 => 's2Member Level/Capabilities updated w/ advanced update routines.',
6 => 'Modification Confirmation Email sent to Customer, with a URL that provides them with a way to log back in.',
7 => 'User exists. Handling `payment` for Subscription via ( `web_accept` ).',
8 => 'Payment Notification URLs have been processed.',
9 => 'Storing IPN signup vars now. These are associated with a User\'s account record; for future reference.',

So, basically, make sure that if they have an account, to be logged in to it before paying for more access, or the payment will expect a new account. You can have a message were you sell access to new people, saying that if he has an account already, he should login first, and give him a link to the the login form, or point to the login widget to use it.

I hope that helps!

Ah, and please confirm these:

Sasha, your problem is with the notification’s email field.

Marlin, your problem is with the payment notification URL or email field?

Excellent! Thanks for the update. I’m glad it’s working well for you now. :)

OK, this time the file did come through. I’m sorry about the time, but normally the files come through alright throught he contact form the first time.

You sent me just one log file, is that the only file in your s2member-logs directory? If you have more, could you please send them all?

Or just send the login info for the FTP so I get them directly. If you include the login info for the dashboard I can do a test 1 cent purchase to see if I have the problem you mentioned and I can look at the new log entries for it.

Thanks!

It may be a JavaScript conflict, could be the theme or another plugin.

This is part of a conversation I had with Jason some months ago regarding JavaScript conflicts.

Cristián: I still don’t understand how the JS conflicts work… If the library is the same in both plugins, why is there a conflict? Same var names?

Jason Caldwell: Well, I call it a conflict. Sometimes it’s a conflict in jQuery because of a bad plugin, which attempts to load jQuery on it’s own, instead of doing it the WP way. Or sometimes, it just a bad plugin that causes a JavaScript error, which may result in all JavaScript failing (the nature of JavaScript). Not really a “conflict” in that case, really an error due to a bad plugin/theme.

Jason Caldwell: I’ve also seen some conflicts between frameworks. That’s rare, but there are some plugins that use the ProtoType framework, and combined with another framework like MooTools, there is a possibility for a conflict to arise. Rare though, and it’s usually attributed to the way they’re loaded (i.e. by a bad plugin/theme).

Cristián: Does WP load JQuery already? If so, why do plugins load it too?

Jason Caldwell: Yea, WP already loads it. But some plugin authors don’t know that, or they just hard code it into their plugin not realizing that. Other times they’ll try to include a dependency on jQuery, but they name it wrong, and WordPress gets confused.

Cristián: Does s2Member load it again or uses WP’s?

Jason Caldwell: Hmm, not really, because in the Dashboard, it’s already loaded by WordPress. s2Member enques scripts that it uses, which rely on jQuery being present. In the call to wp_enqueue_script(), s2Member will list jQuery as a dependency, which forces WP to load it, though it’s already loaded in the Dashboard anyway. That’s the proper way to handle it.

On the front-end of a site, s2Member will load jQuery if it’s not already loaded, but again, using the same technique. A call to wp_enqueue_script() with a dependency on jQuery forces WP to load jQuery. If 10 plugins all do it this way (i.e. the right way), WordPress loads jQuery in the proper order and only one time.

Cristián: Ah, got it. I understand WP has a QC team, don’t they check this?

Jason Caldwell: Not in my experience. They look mostly for security issues and really bad code. They usually don’t catch minute details like this.

Cristián: I see, but these details do cause trouble for the users. Maybe it’d be good to write an article about JS conflicts as you explained above and post it in the forums, and then show it to the QC guys for consideration to include in their quality checklist.

Jason Caldwell: Yea, that’s a good idea. On the WP side though, they’re aware of this problem, and that’s why they created the wp_enqueue_script() wp_enqueue_style() functions. Although, I wish this were more prominent in this article: http://codex.wordpress.org/Writing_a_Plugin#Plugin_Development_Suggestions

It is mentioned, but it’s all the way at the bottom:

Try not to echo [hilite code]