Jason (Lead Developer)

Thanks for the heads up on this thread.

A full review of WordPress v3.5 running together with s2Member and s2Member Pro has been underway and will be completed sometime within the next few days. Required updates will be made available in the next maintenance release of our software. I’m not aware at this time of any major concerns, but there are some minor issues like the bug reported in this thread that we’re taking a closer look at before the next maintenance release.

Regarding /wp-login.php

Until the next maintenance release, you can resolve this issue by downloading the attached ZIP file. Please unzip and upload mms-patches.inc.php to your existing installation. Allowing the patched copy to override your existing copy of: /s2member/includes/classes/mms-patches.inc.php

Now, go to your Dashboard and re-run the Multisite patches provided by s2Member.

Download PATCH file: http://d1v41qemfjie0l.cloudfront.net/s2member/uploads/mms-patches.inc_.php_.zip

OR, if you don’t like patches, another option is to follow the manual instructions provided in this section of your Dashboard, which are still accurate enough to work with WordPress v3.5. Please see: Dashboard -› s2Member® -› Multisite (Config) -› Patches -› Do It Yourself

Thanks for the heads up on this thread.

Regarding what you said here…

The stylesheet https://mysite.com/wp-content/plugins/s2member/s2member-o.php was not loaded because its MIME type, “text/html”, is not “text/css”.

MORE – Of course it seems to be a theme issue, as activating the default theme returns the Paypal Pro form to ‘normal’ – however, this theme conflict was not present prior to the upgrade of s2Member. Is there some information you can perhaps give me so that I can let the theme developers know and troubleshoot on their end as well as yours?

This indicates to me that s2Member’s dynamic CSS, which is loaded via the /s2member-o.php file, is causing a fatal error in PHP, resulting in an incorrect MIME type, and the loss of any valid CSS being produced by this file, as it normally would be.

Since disabling the theme you’re using corrects the issue, I suspect a conflict between s2Member and your theme of choice. We’ll be happy to help you identify the conflict. Please check your PHP error logs where the file /s2member-o.php is mentioned. If you can post the PHP error that is occurring, that will give us some insight, and should lead to a resolution for you.

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.

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.

Please let us know if problems persist.

Thanks for the follow-up.

Yes, we VERY much appreciate it when you come back and update on us things. That helps us, and it helps others. Thank you very much for that. I’m glad to hear you got that sorted out.

Investigation Results

Thanks for reporting this important issue.

The account was successfully created, but nothing else. So I’m wondering is there some sort of “race condition” that’s going on where authorize’s “Silent Post URL” is reporting too late that ends up erasing s2member’s user role upgrade?

I’m not aware of any race conditions with Authorize.Net integration. The Silent Post URL only handles incoming notifications regarding successfull payments, and NOT for failed payments. Failed payments are handled via the Authorize.Net ARB system, which is a different API all together. In either case though, the communication between s2Member and Authorize.Net is dependent upon the current Paid Subscr. ID value being a match to the data provided in communications from Authorize.Net. Thus, I’m not aware of a way for that to happen.

I then thought of something else. I have s2member send “s2Member® API / Notifications” for “signup”, “registration”, and “payment”. The “signup” and “registration” Notifications URL’s were alerted to this checkout, but it doesn’t look like the “payment” notification was ever fired. So if it wasn’t fired for me, perhaps it was never fired within s2member’s own internal routines?

Yes, this coupled with what you mentioned before, would indicate that post-processing of the transaction is failing on your installation. s2Member and s2Member Pro both work internally with an underlying set of core PayPal processors, which set the standard for s2Member’s post-processing of a transaction. The best way to debug this issue in s2Member, is to enable logging under: Authorize.Net Account Details in your Dashboard, and then look at both of these log files.

See: Dashboard -› s2Member® -› Authorize.Net® Options -› Account Details -› Logging

After a test transaction, please check these log files to assist you in debugging:

authnet-api.log This will indicate all details related to s2Member’s direct communication with Authorize.Net.

paypal-ipn.log Once s2Member’s Authorize.Net-specific routines have finished, s2Member will ultimately use it’s core PayPal processor to handle post-processing of a transaction, so some errors may exist here that will shed light on things for you. This log will be generated even with an Authorize.Net integration. Please feel free to submit log entries from these files, and we’ll review them with you here.

If problems persist, please submit a Dashboard login for us privately. We’ll run diagnostics on your installation. If it comes to that, please use this form: s2Member® » Private Contact Form

Thanks for the heads up on this thread.

#1

On my install S2Member appears to behave differently when I restrict access to a page by setting a specific level from the post editing screen (through the metabox) or through s2member>restrictions options>page access restrictions.

When I set the restrictions via the s2member settings screen things work as intended, but if I set the restrictions via the meta box, the conditional is_permitted_by_s2member( $post_id ) doesn’t return false when it is supposed to. This is remedied when I manually plug in the id through s2member>restrictions options>page access restrictions.

Is that intended behavior? I would expect any adjustments made to page access from the post/page editing screen to show up at s2member>restrictions options>page access restrictions.

No, that would indicate to me there is either some confusion about how the API function works, or that there is a deeper issue somewhere in your installation somehow. Restrictions set in the Post/Page editing station (with respect to Level-based Restrictions), are simply updating the options that you see under this section of your Dashboard. Nothing more.

Dashboard -› s2Member® -› Restriction Options -› Post (or Page) Access Restrictions

Is this continues to be a problem, please submit a list of specific instructions on how we can reproduce this in a default WP installation, and we’ll take a closer look for you. I’m not currently aware of any issues in this regard. I was unable to reproduce it with the details we have so far.

#2

When restricting a page based on a specific custom capability, will is_permitted_by_s2member( $post_id ) check for that? Unless something on my setup is interfering, it doesn’t seem to. If this is intended, is there another alternative conditional that will take post_id as a parameter and check for the current user’s access privileges?

Yes, if you’ve used the Post/Page editing station to add a list of one or more Custom Capabilities required to gain access to certain Posts or Pages, the is_permitted_by_s2member() function will consider those Custom Capabilities as well, before it returns TRUE or FALSE. So for instance, if a Post requires Level #2 access, and it also requires Custom Capability music, the is_permitted_by_s2member() function will return FALSE for someone at Level #2, who does NOT also have the Custom Capability music.

Here are some things I would take a look at:

Have you configured s2Member with a Membership Options Page yet? If not, this is the problem.
See: Dashboard -› s2Member® -› General Options -› Membership Options Page

Are you logged in as an Administrator when testing? If so, this is the problem. Administrators have full access to everything, regardless of your configuration of Level Restrictions or Custom Capabilities. You’ll want to log out of your Administrator account and into an account that will reflect the proper permission level.

Are you passing an ID into this API function?

<?php
if(is_permitted_by_s2member(123))
	echo 'Yes';
else echo 'Nope!';
?>

Reference article in Codex: http://www.s2member.com/codex/stable/s2member/api_functions/package-functions/#src_doc_is_permitted_by_s2member()

Please let us know if problem persist. Thanks!

Thanks for the heads up on this thread.

Have you tried this yet?

For HTTP Authentication to work with IIS, the PHP.ini directive cgi.rfc2616_headers must be set to 0 (the default value).

See also: http://php.net/manual/en/features.http-auth.php

Investigation completed.

Thanks Joseph!

@ Todd

The code changes I posted here that provide compatibility with JW Player v6 did NOT make it into the latest maintenance release. The existing code samples work with JW Player v5. We’ll get the JW Player v6 code samples into the next maintenance release however. Thanks for your patience :-)

In the mean time, the latest release of s2Member comes with the patch we mentioned in an earlier reply to this topic. So while we investigate this issue further, feel free to upgrade to the latest release of s2Member.

See: http://www.s2member.com/changelog/#s2-changes-v121201