About: Schott Taylor

Jason, Cristian and Raam,
It’s been over 48 hours since I’ve heard from anyone at s2M. Can I please ask you to please help us with our issue?

I just received another notice from the SAS help desk:

1) The ShareASale tracking code pixe should be installed in only 1 location, that being the thank you page a customer is auto returned to when they complete a purchase.
So this tracking code should only display from a completed purchase not from any other action. So you should verify it is not in all 4 boxes you referred to.

I have the SAS pix img located in all of the following API/Tracking boxes: Signup Tracking Code, Modification Tracking Code and Capability Tracking Code (as stated in my first post). The SAS gentleman is suggesting that it should only be in one location. I’m assuming that each of these tracking code boxes only actually puts the code in 1 area of the site, so that it would NOT cause a conflict with the replacement codes.

I searched the message again boards to see what causes a conflict or why the replacement codes are not passing through the data and did not come up with any supporting documents.

Please, we need your assistance.

• This reply was modified 3 years, 11 months ago by  Schott Taylor.

Hi Jason,
Thank you for such a quick and thorough response.
That auto-login hack worked fantastic! I had an earlier post concerning the failure of the success=”” atr in conjunction with the auto-login hack. I gave up hope on a solution.

If you have a link to the article where you found this hack, please post it in a reply here so we can backtrace that and have it removed and/or post a warning to others.

I will look for those articles and post them here. There were actually 2 that were very similar. we were using the older one that caused a the redirect url to end in /?first.

Unfortunately we are still not able to get SAS working.

Now that we have the auto-login AND success=”” atr working, we redirect new users who are just registering to the /sign-me-up page (members option page) and new and existing users who have landed on the checkout page to the /member-pages/login-welcome page after a payment transaction. The redirects work, the tracking codes do not.

Tests

SAS Tracking Codes are the same as above, but with the following adjustments

1. Ran a transaction with the new auto-login hack | Fail :(

If you setup a success=”” attribute, your Signup/Modification Tracking Codes will be displayed at the bottom of your custom Post or Page, as indicated by the value of your success=”” attribute.

2. I read this to mean that I needed to add the SAS tracking coded to Specific Post/Page Tracking Codes, to which I did. Could there be a conflict if I do not take the Specific Post/Page Tracking Codes out? | Fail :(
3. Then I read it to mean that I needed to add the SAS tracking coded directly into the /member-pages/login-welcome page, to which I did | Fail :(

If these are not working as expected, please remove the Auto-Login hack that you’ve implemented with custom code.

4. I wasn’t sure what ‘these are’. The Tracking Code or the success=”” atr? The auto-login is very important to the sales process, so I ask with trepidation, are you saying here that the auto-login hack and the SAS affiliate tracking code are incompatible?

Also, please verify that your theme is performing the wp_footer action which is standardized by WordPress. This is what s2Member uses to display your Signup/Modification Tracking Codes.

5. WP codex says the wp_footer() is suppose to be located just before the closing body tag. We had a script before the body closing tag, so I moved the wp_footer() below the script and ran a transaction test | Fail :(

Your log file indicates that s2Member is also having trouble verifying $_POST vars. This could indicate that you have an invalid and/or expired Secret MD5 Hash configured with s2Member®. Please see: Dashboard -› s2Member® -› Authorize.Net® Options -› Account Details -› Secret MD5 Hash

6. We have not yet tested the validity of the MD5 Hash. | unknown result

*Tip* ShareASale® also provides an alternative method, using a 3rd-party call. The alternative 3rd-party call, could be used with s2Member -> API Notifications. A 3rd-party call, is essentially an HTTP connection that runs silently behind-the-scene, as opposed to being loaded in a browser. It’s a bit more powerful (and reliable), but also more advanced.

Thank you for mentioning this tip. You actually have to get special permission from SAS to use this method. I’ve inquired hoping this could be a work-around if the issue isn’t the MD5 Hash. I’m also leery of my skills to implement this option.

• This reply was modified 3 years, 11 months ago by  Schott Taylor.

Cristián
Thank you, Thank you, Thank you!
The hack was the culprit. I can’t believe I missed that.

I researched some workarounds on the forum and found a couple of threads:

http://www.s2member.com/forums/topic/auto-login-conflicts-w-trackingnotification/

Christian said:

No, that hack has that problem. What you could try is, instead, use the success attribute in your shortcode pointing to a page, where you then have a hack to log him in and redirect him to the page you want.

Then in another thread:

http://www.s2member.com/forums/topic/auto-login-code-question/

Jason said:

If you’d like to accomplish auto-login after registration with a Pro Form, I recommend the success=”” attribute for your Pro Form Shortcode. With that attribute, you can create a custom thank-you page, which might include code from your hack file above; and you may choose to automatically log them in and redirect them to a page of your choosing. Please see: Dashboard -› s2Member® -› PayPal® Pro Forms -› Custom Return URLs Upon Success

What I couldn’t find was how exactly to do this. I understand how to use the success=”” attribute to redirect a user to an custom thank-you page, but can you point in me in the direction of how to “include code from your hack file above; and you may choose to automatically log them in…”

I’m fuzzy on how to automatically log a user in once they’ve been redirected to a custom thank-you page.
The success attribute would point to URL: /thank-you-for-registering/?user_login=%%user_login%%&user_pass=%%user_pass%% which both redirects them to the page I want AND logs them in? So I would not need the auto login hack, correct?

Hi Bruce,
This is Jill, Schott’s developer.

The first thing I notice here is that the two pages that you’re attempting to redirect to do not actually exist (e.g. they are 404s when you navigate there).

I wish it was that simple. You must have looked at the site when I changed the slugs away from /welcome-1 /welcome-2. I tried different slugs and changed the success=”…” attribute in the shortcode to try to isolate the issue. With no luck.

It appears that this is meant to be the Membership Options Page, but is set up as the Login Welcome Page in your WordPress Dashboard (your site is redirecting to your My Account page, instead of this page right now.

Yes, I am aware of the flip flop. I took over the site with it set up this way. It’s on my agenda for my client. :)

1) Create pages with the slugs /welcome-1/ and /welcome-2/ before continuing. This could be causing the error itself

Again, I wish it was as simple as having the incorrect pages. I’ll switch the slugs and shortcode back to /welcome-1/ and /welcome-2/ before I submit this response.

2) Enable logging under Dashboard -› s2Member® -› PayPal® Options -› Account Details -› Logging

3) Make sure that you are logged out before you try to register

4) Run another test transaction, and if problems persist, send us the log files that were generated under /wp-content/plugins/s2member-logs/ (you’ll need to access your server via FTP to get the files).

2) Yes, logging is set to “yes”
3) Yes, I’m logged out when I register a new test user.
4) The only “transaction” that is happening is the user is registering. Users are not purchasing at this point. Registration transactions do not show up on either of the Auth.net logs.

The registration forms are registering the users correctly. They are registered at level-1 and level-2 respectfully correctly and show up just fine in WP Users. The ccaps are working as well. I just can’t get the success=”” attribute to work.

Just to recap what we are trying to accomplish. When users register in either of the registration forms (on pages sumigni.com and sumigni.com/resumes) we’d like them to be redirected to https://sumigni.com/welcome-1/ and https://sumigni.com/welcome-2/ upon just their registering. I’m attempting to use the success=”https://sumigni.com/welcome-1″ and success=”https://sumigni.com/welcome-2″ attribute in the s2Member-Pro-AuthNet-Form shortcode for that redirection.

The result we are getting is an incorrect redirection. Users who register in either form (sumigni.com or sumigni.com/resumes) are being directed to sumigni.com/sign-me-up/?first instead of /welcome-1 and /welcome-2

NOTE: sumigni.com/sign-me-up/ does not exist any more. I changed that page’s slug to sumigni.com/welcome-1.

If there is another way to redirect users who have just completed just the registration process, we’d be open to suggestions.

Thanks
Jill

Hi Cristian
I LOVE this plugin, and your support is outstanding. So thank you!…is what I should have said first :)

So those two pages are in the same WP installation, correct?

Yes, correct.

/resume/ is not another WP installation? Just checking.

No, it is not another wp install.

About the free registration pro-form shortcodes, they look okay, so the success redirection should work. Is the user account created successfully?

Yes, the users are being created successfully. The sumigni.com form creates the user at level=”1″ and the /resumes/ form creates the user at level=”2″.

Have I misused these levels? I am registering each users at level 1 or 2 (vs level 0 free subscription), but they are not paying for anything at this point. I am trying to redirect the users to different content pages (via success=”…”) where depending upon their level, they can access specific products to purchase. I reread the Open Registration notes:

If you set this to Yes, you’re unlocking /wp-login.php?action=register. When a visitor registers without paying, they’ll automatically become a Free Subscriber, at Level #0. The s2Member software reserves Level #0; to be used ONLY for Free Subscribers. All other Membership Levels [1-4] require payment.

Does this apply to the Auth.net Pro Forms shortcode? FYI, I have the Open Registration set to “Yes”. Do the users have to pay for something in order to be redirected via success=”…”?

Why would the default redirect go to /sign-me-up/? That page must have been set at some point, somewhere. I did change the slug on the /sign-me-up/ page to the /welcome-1/. Could that effected the success=”…” redirection?

As a test, could you enter the full URL in the success attribute?

Yes, I tested the full URL

success="https://sumigni.com/welcome-1/"

and

success="https://sumigni.com/welcome-2/"

On both forms, I’m still getting redirected to:

https://sumigni.com/sign-me-up/?first

I’m super stumped.