Jason (Lead Developer)

Thanks for the heads up on this thread.

The latest versions of BuddyPress/s2Member use the “wp” action Hook, so the “template_redirect” Hook is too late. Try changing references to “template_redirect” in your previous code samples, to “wp“, with the same hook priority of “1”, and you should get the results you’d expect.

Please let us know if problems persist.

Sorry for any confusion on this. I know some of my past video tutorials use template_redirect, and those need to be updated as soon as possible, so they continue to work for folks running the latest versions. BuddyPress in particular, requires everything to run on the “wp” action hook now.

Hi Mark. Thanks for the follow-up.

Couple of things come to mind.

1. Any object caching plugins running on this installation? Or a database cache of any kind?
2. Anything in your own PHP sub-routines that might be making updates to a WP_User object by reference? In other words, is it possible that your script runs something else right after the IPN is sent to s2Member? Something which might actually be operating on what would be a stale WP_User object, once the IPN is processed.

If problems continue, please post a longer code snippet for me, so I can get a bigger picture, and see where you’re at currently with the issue. I’ll be happy to assist further in any way that I can. I’d be particularly interested in seeing the full code snippet that is posting IPN data to s2Member. Perhaps I’ve missed something, that your code will make more apparent to me.

Cristian asked me to take another look at this for you.

I just did a quick review of that plugin you posted. It looks like the changes this plugin makes will allow the Pro Login Widget to function this way also. So it’s fine. The only remaining issue is the wording in the Pro Login Widget itself. Instead of asking a User for a “Username” in the Pro Login Widget, it might be desirable to ask for Username or Email Address.

The change needed is at line #118 inside:
/s2member-pro/includes/classes/login-widget.inc.php

echo '<label for="ws-plugin--s2member-pro-login-widget-username">' . _x ("Username", "s2member-front", "s2member") . ':</label><br />' . "\n";

Change to:

echo '<label for="ws-plugin--s2member-pro-login-widget-username">' . _x ("Username or Email Address", "s2member-front", "s2member") . ':</label><br />' . "\n";

This could be handled with a Filter against gettext_with_context, but that might produce unwanted changes in other areas of s2Member, where all you’d want is just Username. Therefore, it’s better to hard code this particular change following the instructions above. I’ll see what we can do to make this simpler going forward.

I agree. The hook set_user_role is your best bet in this case, as that lies beneath s2Member’s functionality, taking place in the WordPress core framework whenever a Role is changed.

Thanks for your patience.
After running diagnostics on your server, I found the following issues.

1. Your installation of PHP is compiled –with-curlwrappers. This alters the way some native features in PHP function, and it causes problems for WordPress, because of this known bug that still exists even in the latest versions of PHP. For further details, see: https://bugs.php.net/bug.php?id=41051

2. Your Amazon S3 Bucket Name contains characters that are considered invalid for CloudFront. All Amazon S3 Bucket names should contain lowercase alphanumerics and dashes only. Your current Amazon S3 Bucket contains one uppercase character. Please see: http://docs.amazonwebservices.com/AmazonS3/latest/dev/BucketRestrictions.html

I removed the s2-hacks.php file that you created with:
add_filter ("use_curl_transport", "__return_false");.
On a server configured –with-curlwrappers, you are better off using cURL directly. When this option is enabled in PHP, cURL is going to be used one way or another, so we might as well go directly to it.

case 'PUT':
	curl_setopt( $handle, CURLOPT_CUSTOMREQUEST, 'PUT' );
	curl_setopt( $handle, CURLOPT_POSTFIELDS, $r['body'] );
	break;

After this section of code, add this section:

case 'DELETE':
	curl_setopt( $handle, CURLOPT_CUSTOMREQUEST, 'DELETE' );
	curl_setopt( $handle, CURLOPT_POSTFIELDS, $r['body'] );
	break;

This adds DELETE support to the WordPress cURL interface. s2Member normally falls back on WP_Http_Streams for this, but on your server that’s causing problems. So this direct edit is needed.

if (!empty ($args["method"]) && strcasecmp ((string)$args["method"], "DELETE") === 0)

Replace that line with this instead:

if (!empty ($args["method"]) && strcasecmp ((string)$args["method"], "X-DELETE") === 0)

Referencing this thread in communication with PayPal MTS and Developer Support.

Thanks for bringing this thread to my attention.

Cristian and I just spoke about this.

This WAS possible in previous versions of s2Member. However, it’s NOT possible in the current release, because s2Member now uses digitally signed URLs to help prevent fraudulent transactions, and to prevent ClickBank URLs from being modified by an end-user (e.g. to prevent someone from changing the Membership Level # in the URL on their own, or from changing other important details, like term lengths).

Current versions of s2Member absolutely require that each ClickBank Button be generated by the Shortcode of the installation site; this way the URL leading to ClickBank is digitally signed by s2Member, for future authentication after a completed purchase (e.g. the IPN handler will NOT process the IPN if the original link to ClickBank was missing it’s digital signature).

Therefore, what you’ve requested is NOT possible in the current release of s2Member v120309+. I suggest that you link Site B to your sales page at Site A, where your ClickBank Button Code will be generated by the Shortcode at Site A (i.e. your actual installation of s2Member).

Another possible alternative is to create a simple script at Site A, which generates a ClickBank Button URL, using the documented output Attribute: output="url"; and then redirects a visitor automatically to the URL that is generated by the Shortcode at Site A. For instance, you might create a MUST USE plugin like this one.

Create this directory and file:
/wp-content/mu-plugins/s2-hacks.php

<?php
add_action('init', 'handle_custom_clickbank_redirections');
function handle_custom_clickbank_redirections()
	{
		if(!empty($_GET&#91;'clickbank'&#93;)) // A url leading to this site, with: /?clickbank=redirect
		{
			$clickbank_checkout = do_shortcode('&#91;&#91;s2Member-Pro-ClickBank-Button ... output="url" /&#93;&#93;');
			// The Shortcode has been abbreviated here for clarity in this regard.
			// You will need to generate your own full ClickBank Button Shortcode, and set output="url".
			
			// Redirect the potential customer now to ClickBank.
			wp_redirect($clickbank_checkout); exit;
		}
	}
?>

With this MU plugin in place. Now create a link on Site B, pointing to Site A.
Site A will silently redirect the customer to ClickBank checkout.

http://yoursite.com/?clickbank=redirect

Thanks for the heads up on this thread.
~ Yes, that would certainly be news to us.

I’m not aware of any change in this regard. However, I will follow-up on this with PayPal just to double-check, and also to find out why you had the experience that you did. I’ve posted an inquiry here which you’re welcome to follow along with. I’ll update this thread once I have confirmation. See: https://www.x.com/developers/paypal/forums/website-payments-pro/paypal-payments-pro-recurring-billing

Please let us know if this problem continues.
If anyone has the ability to submit a Dashboard login so we can track this down, I would appreciate it.
s2Member® » Private Contact Form

Hi there. Thanks for reporting this important issue.

~ and thanks for the heads up on this thread.

I just ran some tests on this, against all PayPal Pro and Authorize.Net Free Registration/Payment Forms. I also ran tests against the default WordPress login/registrations forms. Thus far, I’ve been unable to reproduce this issue. That is, the Replacement Code %%user_id%% is always properly filled by s2Member in my tests.

Therefore, I’ll have to assume (at least for now), that this is a script error on your end?

As Cristian mentioned, did you check the value of $_GET[‘wpuserid’] in your script?

Thanks. Please let me know if we missed something here. Or, if there’s a specific path we can follow in order to reproduce the issue you’ve reported. Reproducing the issue is about 90% of way to resolving it :-)