Jason (Lead Developer)

Thanks for the follow-ups.

I just took another look at your site as it exists now.
http://dev.youracp.org/personal-membership/associate-grade-aacp-membership-gbp-payment-form/

I’m still seeing the same JavaScript error that existed before, and this error exists in all browsers that I tested. Including Firefox, Chrome, and IE9. As I said before, until the JavaScript error is resolved, this problem is likely to persist. If you can get the JavaScript error corrected, and if the problem still exists, we’ll be more than happy to take a look for you. We’ll also be happy to help with correcting any JavaScript errors that exist in s2Member Pro.

That being said, the error that I’m seeing on your site (in ALL browsers), is not contained within a file that ships with s2Member or with s2Member Pro. This file came with your theme, at least it appears that way. I know for sure the file did not come with s2Member or with s2Member Pro.

I won’t try and argue that the underlying cause is or is not attributed to s2Member Pro. However, the logical way to debug an issue like this is to start with the problematic area in the code. In this case, that problematic area lies within jquery.cycle.all.min.js, which ships with your theme. Your theme developer should help you with this, no question. Disabling s2Member is not an option for you, so your theme and s2Member both need to work together harmoniously. In this case, that seems to be the issue.

If you fix this problem, and then another issue comes up which is directly related to a file that ships with s2Member, or a feature powered by s2Member, we’ll be happy to assist you. JavaScript conflicts can be a tricky thing to debug, and a methodical approach is best. I recommend starting with the debugging output that I provided, and zap the bug that we know exists. Once all JavaScript errors are resolved, I think you’ll find that your IE9 issue will disappear silently as it’s done in many other cases where the same type of issue has been reported here in these forums.

To clarify, it is my belief your IE9 crashes are a result of JavaScript errors that exist in ALL browsers, but more visible in IE9, due to it’s inability to recover quite as gracefully as other browsers can. Regardless of my opinion though, the JavaScript errors that exist outside of s2Member, MUST be resolved before we can proceed with further debugging from our end. If your theme developer finds a conflict between his theme and our plugin, which is causing the error to pop up in a file that he is using (not likely, but certainly possible), we’ll be happy to work with him to find a resolution. Please feel free to point your theme developer to this thread.

Thanks for the heads up on this thread.

@Alex Kolosko

Thanks for reporting this important issue.

We will certainly take steps to prevent this from happening in the next maintenance release.

Thanks for your patience.

Yes, I can confirm. This is definitely coming in the next major release of s2Member.

Thanks for the great sugggestions!

Thanks for the heads up on this question.

do i need extended verification SSL?

EV SSL may not be required to receive payments on-site, but I’m not sure, never had this asked before. I’ll email Jason to confirm this.

Any valid SSL certificate will be sufficient in terms of software compatibility (the cheaper the better in my opinion). The same goes for PCI compliance (in most cases a standard SSL certificate is fine, depending on your overall sales volume – ask for recommendations and/or requirements from your bank or payment gateway please).

FYI: Extended validation costs more, provides some added benefits to you as the site owner, but still accomplishes pretty much the same thing as a simple standard SSL certificate. Please see:
http://www.godaddy.com/ssl/ssl-certificates.aspx

Update – OH NO! someone just purchased access to 2 pages and the link isn’t working (i tried it)! i need to figure this out ASAP! I’ll get the logs for this transaction too…

This issue has been investigated, and we determined the issue was occurring only on installations attempting to use Specific Post/Page Access Links, and only when the site was configured NOT to use fancy permalinks.

A short term fix for this issue (and always our recommendation), is to configure your WordPress permalink options in this section of your WordPress Dashboard: WordPress -> Settings -> Permalinks.

See also: http://codex.wordpress.org/Using_Permalinks

The absence of any formal permalink structure on your site is causing issues for the current release of s2Member, when it comes to Specific Post/Page Access Links. s2Member’s systematic routine will need to be adjusted to accommodate this scenario, which we have addressed already for the coming maintenance release.

Here is an excerpt from the Changelog (coming soon).

Thanks for the heads up on this thread.

Regarding the redirection. That’s normal. The redirection occurs because you’ve integrated Amazon Cloudfront. With Cloudfront integration, the files are ultimately served from edge locations (i.e. via Cloudfront servers).

Regarding the error message “AccessDenied”. This is a generic message that can occur on the Cloudfront side of things when/if there are issues in the link that is providing the access (which is generated by your installation of s2Member, based on your configuration of s2Member). I’m not aware of any widespread issues with the way s2Member formulates the links, so I doubt seriously there is problem with the link format overall. It also looks correct from the post that you submitted earlier, in terms of the overall format.

Since you’ve said that streams are working properly?
But the direct download is NOT working properly, do I have that correct?

If that’s the case, I’d take a look at your Amazon Cloudfront Console at Amazon.com. Have any of your Cloudfront distributions been disabled, or are there any other issues being reported to you in the console there?

I’d also be curious to know if you’ve integrated the Cloudfront distributions (or any other part of your Amazon web services account), with another software application that might be interfacing with Amazon using an entirely different version of their API. For instance, you do you have other software applications (besides s2Member), connected to your Cloudfront and/or S3 services?

If all else fails, I recommend that you ask s2Member to reconfigure your Cloudfront Distributions (i.e. allow s2Member to delete and then recreate your Cloudfront distributions, by checking this box again and clicking save).

Note, this process can take several minutes, and you may get some error messages from s2Member, while the distributions are being deleted and recreated on the Cloudfront side of things. In other words, some temporary errors during this process are normal. Please be patient with the process that s2Member has to go through.

Thanks for the heads up on this thread.

Thanks for reporting this important issue. You’re not the first person to report this problem. If you search for IE9 in our support forums here, you’ll find that others in the past have experienced similar issues from time to time.

The underlying cause has almost always been related to other JavaScript errors that exist in other parts of your theme and/or with another plugin somewhere, which might be loading a JavaScript dependency that either contains errors, or has code that conflicts with s2Member Pro’s use of the jQuery extension.

I just took a quick look at your site with FireBug installed, and I’m finding that you currently have some JavaScript errors that need to be resolved in a jQuery extension that is NOT loaded by s2Member. I would recommend that you correct that issue first, and then do cross browser testing again.

The reason this issue is reported most often with IE9 as the culprit, is that IE9 tends to be less forgiving about JavaScript errors that exist in other parts of the site. I’ve seen IE9 (and other browsers too, but more so in IE9), where a single JavaScript error that exists in an entirely unrelated part of your code, have far reaching impacts on the performance and behavior of s2Member Pro Forms (as well other parts of a site).

Using a debugging tool like FireBug will help you resolve this. If you cannot, I suggest that you hire a freelancer to do a review of your installation, and help you work out any kinks that might exist between the plugins you’re running together on a single installation. I’d look for someone experienced in WordPress, and who is quite good at debugging JavaScript conflicts.

Thanks for the heads up on this thread.

The BuddyPress account deletion feature should be disabled in a site that runs s2Member. Please use a cancellation button, and/or a cancellation form provided by s2Member instead.

To clarify. Please disable the BuddyPress account deletion feature from your BuddyPress configuration panel. Then create a cancellation button and/or Pro Form (if you’re running s2Member Pro) instead. If a customer deletes their account with BuddyPress, the billing is NOT terminated. Thus, that feature should be disabled please.

A site running s2Member should always ask a customer to “cancel” billing, so that s2Member’s EOT behavior can be used to control the automatic account deletion and/or demotion (depending on your s2Member configuration).

See also: Dashboard -› s2Member® -› PayPal® Pro Forms -› Billing Cancellation Forms
See also: Dashboard -› s2Member® -› PayPal® Options -› Automatic EOT Behavior

Thanks for the heads up on this thread.

@ David Lim

I think we’ve it clear that we have a no refund policy on digital goods.

You wrote…

the way your product worked made our site look very awkward and unprofessional

That’s not nearly specific enough. s2Member integrates with the WordPress theme you’ve selected; inheriting styles and appearances provided by your theme, and/or by any other plugins that you’ve installed together with s2Member. Based on your statement, I’m not sure if the issues you’ve had were related to the WP theme you selected, or if they were with s2Member’s functionality?

If so, what is the specific issue you’re having with s2Member?

I did a quick review of your history here in our support forums. I find that you’ve posted several topics, and all except ONE (which was answered/resolved – and found NOT to be related to s2Member), were all about your request for a refund. That is, almost all of the topics you’ve written, were siimply requests for a refund.

In addition, in all of the topics where you’ve requested a refund, we’ve repeatedly asked you to clarify the issue that you’ve having, and you’ve refused to do so. You’ve continued to talk about the difficulty that your developer had, but nothing specific about the s2Member software itself. Having issues with a developer that you hired, is not grounds for a refund by the software vendor. We have no control over how the software is used and/or integrated into your site, or by whom the integration is completed.

If there is a specific issue that you need help with, or that you can explain for us, we’ll be happy to listen. If the issue is indeed a failure on the part of s2Member (i.e. something advertised to work in s2Member, but is in fact NOT working), we’ll be happy to process a refund for you – but only IF we are unable to help you resolve the issue in a reasonable amount of time via these support forums, and only IF you are still within your 30 day purchase period. This policy is reflected officially in our refund policy statement.

Thanks for the heads up on this thread.

Regarding the next billing date. This is NOT something that s2Member keeps a record of on-site. s2Member keeps track of the last time a payment was received, but not when the next payment is set to occur. This is maintained by your payment gateway. If you’re running PayPal, then the next billing date is established on the PayPal side of things.

s2Member is fully aware of transactions, cancellations, expirations, failed billing attempts, and other events that occur with a billing profile established on the payment gateway side of things, because s2Member communicates with your payment gateway through a combination of APIs, including things like the PayPal IPN service. However, personal billing details, other financials, and billing cycle specifics are left on the payment gateways side of things for maximum flexibility and security.

If you’re running PayPal Pro, it’s possible to obtain the billing profile details from the PayPal side of things programmatically – via the PayPal Pro API. While it’s not something that s2Member keeps a record of on-site, s2Member does have the ability to pull this information for you from the PayPal API.

Here is a code snippet that shows how to accomplish this:

<?php
$user_id = 1; // The user we'd like to check.
$subscr_id = get_user_option("s2member_subscr_id", $user_id); // User's current PP subscription ID.
$paypal = array ("METHOD" => "GetRecurringPaymentsProfileDetails", "PROFILEID" => $subscr_id); // API call configuration.

if (($paypal = c_ws_plugin__s2member_paypal_utilities::paypal_api_response ($paypal)) && !$paypal["__error"])
    {
    	print_r($paypal); // Prints a full list of all profile details.
    	// You can parse these variables if you like, and make a determination about the next billing date.	
	}
?>

The $paypal variable will contain the following details, as documented by PayPal. This was pulled from the PayPal API docs, which are provided to you in your s2Member.com account. Upon logging in at s2Member.com, go to the My Account page, and download the s2m-pro-extras.zip file. Inside the zip file, you’ll find this information in the file: payflow-pro-rec-api.pdf

Related thread: http://www.primothemes.com/forums/viewtopic.php?f=4&t=2062&view=unread#p7407

Thanks for the heads up on this thread.

A – Where in this process is the trial period being managed? Authorize.net has a trial period area within it’s ARB functionality, but it doesn’t seem to be used.

That is correct. Authorize.Net (like many other payment gateways), has some issues with the handling of a trial period. For instance, Authorize.Net may allow a customer to gain access initially, but then fail to collect charges a day later on the initially declined card. This is NOT a good thing for most sites.

In short, if s2Member chose to process trial periods via ARB exclusively, it would have very little control over how initial declines are handled (whether they be authorizations or captures).

s2Member’s solution is to make the initial charge (if there is one), as a direct pay transaction that is collected (i.e. authorized/captured in real-time), instead of doing it all together as an initial charge into the ARB configuration. If the initial charge declines for any reason, the ARB subscription is not created, and access is denied until the customer provides a card that has sufficient funds to cover the initial charge.

If there is a trial period, or a different initial charge amount, the ARB subscription is configured to start on a delayed scheduled that matches the time allowed in the initial term. In other words, the ARB subscription is used ONLY to handle future billing, and everything else is handled by s2Member.

B – I’ve tested an instance where the trial amount transaction goes through and the subscription creation fails, dumping the user back to the checkout page with the generic error “Error. Please contact Support for assistance.”. If for some reason there is an error while processing (general error) and only one transaction goes through, how do you communicate with the customer what has happened to avoid them being billed for something that looks as though never occurred?

Yes, this can happen under special circumstances. We have found that it’s very rare for this to happen, but you’re not the first person to report this to us. The issue (as I explained above), is that s2Member processes the initial charge, and if that goes through, the ARB subscription is created to cover any future charges. s2Member’s code assumes that a fully authorized/captured card, with full billing details and other important info, will not have any issue passing through the Authorize.Net ARB service API. And this is indeed the case 99% of the time. However, if for some odd reason (i.e. it’s a rarity), the ARB subscription fails to be created, this leaves the customer with an error on-screen, but a charge that actually went through.

We’re working on a fix to correct this issue for a future release.

A – It seems the current functionality when it comes to modifications is to cancel the existing subscription and create the new one (with new terms). So if someone wants to modify their account mid-cycle, an appropriate method would be to pro-rate until the end of their cycle and then start the next cycle with an increased amount. This assumes the terms of the subscription do not change and it is just an increase (or decrease) in the sub amount. I would have to do this by setting the new terms to match the existing and calculating out a trial period that matches the pro-rated terms. Is this the only way to accomplish this and am I confined by s2member to only have one set of terms per account?

B – The above scenario does not work well with levels. Since users can pick and choose what they want, custom capabilities fits much better. However, adding a CC with subscription terms isn’t exactly offered here. I can get what I want by selling another set of terms at the same level that includes the CC’s, but again everything falls into one bucket, preventing me from controlling terms separately. Is there any other way to accomplish adding CC’s with recurring terms?

Yes, these are both limitations in the current integration between s2Member and Authorize.Net. We’re working hard to move past these limitations in a future release of s2Member. Until then, you can work around some issues related to “A” above, by calculating some things on your own, perhaps creating a shortcode dynamically, based on the needs of your site. Please see this related thread:
http://www.primothemes.com/forums/viewtopic.php?f=36&t=1604

See also: Dashboard -› s2Member® -› API / Scripting -› Advanced PHP Conditionals

Thanks for the heads up on this thread.

I agree with Cristian. If WP Cron is not running on your installation, any plugin (including s2Member), which replies on WP Cron will NOT behave as expected. If problems continue to occur with WP Cron, I would start by sending a quick email to your hosting company, to verify that WP Cron is capable of running on your hosting platform. I would also take a look at the s2Member configuration panel here, to verify that your configuration is setup to use WP Cron.

See: Dashboard -› s2Member® -› PayPal® Options -› Automatic EOT Behavior

Regarding UTC time in the EOT field. WordPress operates on UTC time throughout. While WordPress does make it possible for a site owner to display times in a localized time zone, based on preference, all of the underlying times are calculated based on UTC time. For this reason, s2Member uses UTC to prevent any confusion about what time zone may or may not be employed on a given site (since this is an administrative setting not impacting front-end display). My suggestion would be to calculate the GMT offset in your timezone, and base your input related to EOT Times accordingly (i.e. translating to UTC time).

In the mean time, I’ll accept this as a feature request. Thank you!

Thanks for the heads up on this thread.

Regarding this question…

Next question: I also upgraded so that I could use the import feature in case the “free membership” option did not work. I figured I’d just import my members. But that process doesn’t send the new members usernames and passwords, nor does queue the opt-in email from Mailchimp. So that doesn’t help me either. Now what? How do I get these people into the site and on my mailing list?

My member’s skill sets are all over the place. Some are going to need hand-holding even with the easiest scenarios. I have to make it simple!

That is correct. The User/Member import routine remains silent in every possible way on purpose, so as not to introduce any actions that might be tied to Hooks/Plugins for WordPress. However, s2Member Pro does make its Remote Operations API available, which provides a user creation API, which does allow new user notifications to be sent. However, this still does not fit exactly what you’ve requested with respect to the way you’d like to handle passwords. You can learn more about the Remote Operations API here: Dashboard -› s2Member® -› API / Scripting -› Remote Operations API

Possible Solution:

s2Member Pro does provide mailing list integration, but this requires user confirmation in most cases. What you’d need is a mass email tool to handle the transition from your old site/system I believe.

I suggest that you import all of your Users/Members with s2Member Pro, and then find another plugin (and/or write a custom code fragment), which accomplishes precisely what you’re trying to do with user passwords. You’ll want to look for plugins like MailPress, or another plugin which allows you to mass email your existing userbase from within WordPress (many of these are readily available for free).

I’ll accept this as a feature request. Thank you!

You may also find this thread to be helpful:
http://www.primothemes.com/forums/viewtopic.php?f=4&t=16843#p61284