Thank you for the follow-ups.
I just investigated this issue on your installation and also made an attempt to reproduce it in our lab.
I was unable to reproduce this in a clean installation of WordPress running the latest version of s2Member and s2Member Pro in our lab. However, I did find a few things on your installation which are likely causing the problems that you’ve reported thus far.
Here are some recommendations for you.
1. Please disable object caching. Object caching is known to cause problems with s2Member, as it is implemented by the W3 Total Cache plugin. It’s fine to leave Page Caching on, but I recommend disabling object and database caching for increased reliability. You can search the forums here and find others having issues with object caching in the past. It can DEFINITELY lead to the type of issues that you’ve reported.
NOTE: I see that you’ve actually NOT enabled object caching from W3 Total Cache. However, it appears that it was once enabled at some point, and that the file was never deleted from your /wp-content/ directory. See: /wp-content/object-cache.php. See also: Dashboard -> Plugins -> Drop-ins.
For good measure, I would also recommend that you add the following line to your W3 Total Cache configuration.
See: W3 Total Cache -> Page Caching -> Never cache the following pages
*\?s2member_*
If you have any trouble with W3 Total Cache, we recommend Quick Cache (developed by us).
http://wordpress.org/extend/plugins/quick-cache/
2. The hack that you mentioned is DEFINITELY a problem in this case. That hack is known to cause almost exactly the symptoms that you’ve reported. I would ditch that hack all together, because it interrupts post-processing being handled by s2Member Pro Forms. s2Member Pro will function properly without this hack. If running properly, s2Member Pro Forms DO display a login link after a successful checkout.
If you need to customize this process further, I would suggest the use of the success=""
Shortcode Attribute provided by s2Member Pro Forms, instead of using that hack. So for instance, instead of implementing a hack that interrupts s2Member, you can redirect the customer to a page of your choosing after success. Then, on that custom page (which might actually just be a redirection if you like), you can do pretty much anything you like.
See: Dashboard -› s2Member® -› PayPal® Pro Forms -› Custom Return URLs Upon Success
See: Dashboard -› s2Member® -› PayPal® Pro Forms -› Shortcode Attributes (Explained)
3. Please upgrade to the latest version of s2Member & s2Member Pro so that we’re all on the same page with this bug report. The latest version at this time is v121204.
4. I would suggest that you make an attempt to reproduce this bug on a clean installation of WordPress so that both you/we will have a better chance of identifying the underlying cause of this issue. If all else fails and you ARE able to reproduce this on a clean installation of WordPress running only s2Member and the default WP theme; then we’ll take a look at that installation for you, hopefully with a more immediate resolution for you too.
Regarding the PayerID. That value would only be reflected in s2Member’s own logging routines (and only if you’ve enabled s2Member’s logging routines). It’s something that’s used behind-the-scene only. In fact, it only appears in the URL because PayPal passes that back to s2Member to identify what happened during Express Checkout, nothing more.
A PayerID will NEVER be reflected in your Dashboard, and it’s not tied to any of your customer accounts within WordPress. That’s a temporary ID that PayPal and s2Member use to communicate during the flow of checkout. It’s correct for that NOT to match up with a transaction or subscription ID.
Please let us know if problems persist.