Thanks for the heads up on this request for support.
I can’t say that I would agree with moving s2Member’s JS into the footer. There are some valid reasons for, and advantages in, including JS files in the HEAD of a document. However, we are aware of performance gains associated with this; and we’re making an effort in the next generation of s2Member to accomplish this in areas where it’s possible to do so.
In the mean time, you can selectively load s2Member’s JS/CSS files if you like.
I just wanted everyone to know that we did see this report, and it has been tested under WP 3.4, with the default theme. I was unable to reproduce the issue reported here. I suspect the underlying cause might have been filters applied by other plugins and/or a theme (perhaps another plugin in certain installations that needed an update for compatibility with WP 3.4). For example, something like the RAW HTML plugin, or another plugin that affects WP output filters. It would be a good idea to update those plugins too.
If the problem continues for anyone, please update us here, and we’ll dig deeper.
Posted: Wednesday Jun 27th, 2012 at 2:23 pm
#17677
Thanks for the heads up on this request for support.
@Luis Caraballo
Nothing wrong with the hack that you posted. I just ran it through a test install and it works as expected. If problems persist on your end, I would start looking at other possibilities (i.e. something besides the code you posted here). Is it possible there are other hooks/filters at work somewhere? Something else that might be filtering shortcode attributes?
Posted: Wednesday Jun 27th, 2012 at 2:14 pm
#17675
Thanks for the heads up on this request for support.
Yes, s2Member’s Payment Notificatiion would be my suggestion as well. You can attach custom scripts to that easily. See: Dashboard -› s2Member® -› API / Notifications -› Payment Notifications
Or, if you prefer to use a hook, the one you’re looking for is: ws_plugin__s2member_during_paypal_notify_during_subscr_payment
Posted: Wednesday Jun 27th, 2012 at 2:09 pm
#17674
Thanks for the heads up on this request for support.
@Noelle Morris
This is part of the sanitation that occurs in the WordPress core. By default, spaces ARE allowed in Usernames. You can’t have contiguous whitespace, but single spaces are fine. Contiguous whitespace is automatically reduced to a single space during processing.
The only time spaces are NOT allowed, is if you’re running WordPress in Multisite mode. In that case, spaces are stripped by core WordPress routines. I’ll see what we can do to make the UI more friendly under this scenario. In the mean time, you can modify your Pro Form template if you like, so input cannot contain spaces.
In your Pro Form template file, you might do something like this, for the username input field:
Hi there. Thanks for the heads up on this request for support.
Interesting. Well ® IS a valid XHTML entity. I was also unable to invalidate this against even a mobile DOCTYPE matching the one you originally posted. Can you please confirm which DOCTYPE you are using? Thanks!
Perhaps the DOCTYPE was updated to support this? I think it should, it’s part of the XHTML specs.
(click to enlarge screenshot for review)
Posted: Wednesday Jun 20th, 2012 at 11:24 pm
#17068
Thanks for the heads up on this request for support.
Do you have any enhanced security considerations you’d like to share that are potential risks associated with s2Member? Do you regularly check it with XSS/CSRF and SQL injection vectors? I just want to know how many new mod_security rules I might be writing during this implementation.
We recommend that you establish a Security Encryption Key for your s2Member installation, in order to make your installation unique among others that exist globally, on other WordPress installs.
Also, I recommend that you qualify your installation of s2Member, to receive our Security Badge. By doing this, you’ll not only build trust with your customers, but you’ll also learn more about enhanced security features provided by s2Member. Please follow the checklist we’ve posted here: http://www.primothemes.com/forums/viewtopic.php?f=4&t=15600&p=48551#p48550
See also: Dashboard -› s2Member® -› General Options -› Security Badge
Regarding XSS and SQL injections.
We’re not aware of any vulnerabilities that exist in the current releases of s2Member/s2Member Pro. We make it a point to properly sanitize, encapsulate, and escape all data used in SQL queries. XSS attacks are prevented with built-in WordPress® core functionality, such as esc_html().
Regarding CSRF (Cross-Site Request Forgery)
I’m not aware of any vulnerability in s2Member that would expose it to an attack like this. s2Member uses wp_verify_nonce() to avoid some variations of these types of attacks, and it also refuses to allow browser caching.
You can help yourself to further avoid the possibility of this type of attack, by carefully configuring any caching plugins that you might intend to use. For example, a caching plugin (if not properly configured), can lead to unforseen issues that might be classified as CSRF in some circles. Generally speaking, be sure that your caching plugin does NOT cache pages/objects/etc, for any user that is logged into the site. We recommend our own Quick Cache plugin, as it comes this way by default, and is tightly integrated with s2Member.
Security In General (and PCI compliance)
We have many PCI compliant installations of s2Member, which are constantly scanned for security issues. Should you employ a populate scanning service, and should it report any security vulnerabilities, please notify us immediately, and we’ll work to resolve them for you.
Posted: Wednesday Jun 20th, 2012 at 2:29 am
#16974
I found this was caused by a change in Google’s currency conversion API, which is required for sites selling products in a GBP currency. That is, PayPal requires that all transactions submitted in GBP, be converted to GBP before running them through the API. A recent change in Google’s currency conversion API, was causing a $0.00 amount to be pushed through instead.
We’ve had this corrected in the development copy, which will come out in a maintenance release in the next day or two. Until then, I’m including a patch file, which updates existing installations of s2Member v120608. If you’d like to implement this patch, please unzip and upload the attached file, allowing it to override your existing copy of: /s2member/includes/classes/utils-cur.inc.php
“Using the payflow api you can’t do recurring billing with express check out. If you wanted to do that you’d have to set it up using regular payola express check-out apis.”
The issue was simply related to an incomplete TOKEN value, which has been addressed. Thanks again!
Posted: Wednesday Jun 20th, 2012 at 1:57 am
#16968
I found this is caused by a bug in s2Member’s implementation of Express Checkout for Payflow, in the current release of s2Member v120608. We’re having this resolved in the next maintenance release.
Until then, I’m attaching a patch file for you, that you’re welcome to use. If you’d like to implement this patch file, please unzip and upload the attached file, allowing it to override your existing copy of: /s2member-pro/includes/classes/gateways/paypal/paypal-checkout-pf-in.inc.php
Please upgrade your current installation of s2Member/s2Member Pro to v120608 BEFORE using the patch file. This patch file is designed to fix current installations of s2Member/s2Member Pro v120608.
Thanks for the heads up on this request for support.
The member who owns/admins “msn” will have non members and members pages. I want them to have to pay for that access. If they do not pay their bill I would like “msn” not to be accessible to anyone. Until payment is received.
s2Member does not come with any functionality that handles this in an automated way. However, WordPress® itself does have a feature that allows Network Admins to deactivate a child blog temporarily.
Posted: Wednesday Jun 20th, 2012 at 1:07 am
#16963
Note. API Payment Notifications, are for ANY type of payment, including subscription payments. However, there is ONE exception to this, and that’s for Specific Post/Page Access. Specific Post/Page Access, has it’s own API Notification.
Dashboard -› s2Member® -› API / Notifications -› Specific Post/Page Sale Notifications
@ Allan
When you setup an API Notification with s2Member, you’re dealing with silent HTTP connections, which occur behind-the-scene. Therefore, you will want to stay way from any of the tracking codes that uses image tags, those will NOT work properly in an API Notification.
Instead, you will need to use the API URL provided by iDevAffiliate, called “Generate A Comission”.
See: Dashboard -› s2Member® -› API / Notifications -› Payment Notifications
See: iDevAffiliate -> Setup & Tools -> API Scripts -> Generate A Comission
Thanks for the heads up on this request for support.
“Using the payflow api you can’t do recurring billing with express check out. If you wanted to do that you’d have to set it up using regular payola express check-out apis.”
It is my belief that this response from PayPal support is incorrect.
The PayPal Express Checkout API for Payflow DOES support a BillingType set to: RecurringPayments
PayPal has implemented several service/API changes over the last couple months, and we’ve gotten the impression that many people are confused about which service does what, including even PayPal’s own support team. Therefore, I won’t rule out the possibility of this being a correct statement, but I also can’t take it at face value either :-)
The error you reported was: ‘TRXRESPMSG’ => ‘Field format error: Invalid Token’,
So that we may gain a better understanding about how this error occurred on your installation, please submit a Dashboard login and FTP access for me. I’ll run diagnostics on your integration, to determine the underlying cause of this error for you. Or, if you’d prefer… please enable s2Member’s logging routines, so that data associated with this error is recorded by s2Member, for us to review with you.
If you can submit log entries, please do that privately through this form. If you can include a Dashboard login and FTP access, please include that as well. We’ll help you track this down.
I pressume that even though the header you added is invalid it won’t have any adverse effects on the site?
Nothing serious, no. There are a few cases where some HTTP clients may interpret “none” as a form of compression, and attempt to decompress the file being served by s2Member. This can lead to file corruption, but it’s a rare occurrence, particularly with browsers; this is more of an issue with script-based HTTP clients.
So you should be fine, is what I’m saying. If you can find a way to get this working, without the hack; that’s obviously better, but not necessarily required at this point.
These really are both the same thing, but are classified separately for one reason only.
An “ipn-cancellation-expiration-demotion“, is an EOT demotion (or deletion, based on your EOT Behavior setting) that occurs due to a cancellation and/or expiration of a subscription plan, where the cancellation should occur immediately (i.e. during s2Member’s processing of the IPN itself). This is the case, for example, when a subscription is cancelled and/or expires due to it reaching max failed payments (this usually dictates an immediate EOT, access is now revoked in most cases, and there is no need to calculate any remaining time).
More the norm:
An “auto-eot-cancellation-expiration-demotion“, is an EOT demotion (or deletion, based on your EOT Behavior setting) that occurs due to a cancellation and/or expiration of a subscription plan, where the cancellation should NOT occur immediately (i.e. it does NOT occur during s2Member’s processing of the IPN itself).
Instead, this type of EOT is handled as part of s2Member’s Automatic EOT System (powered by WP Cron), where the EOT occurs at the correct point in time, based on a multitude of factors; like what was originally sold, whether it included a trial period, if the cancellation occurred during the trial period, etc, etc.
Thanks for the heads up on this request for support.
The minimum required import columns are as follows, in this order. The ID column can be left empty, but all of these other minimum requirements MUST be filled in.
All of the other columns are optional, and can be included in whole, or in part, as needed. So for instance, in your case, you just need to update the Role and EOT Time, as you mentioned before. So you might do something like this. So long as you keep the columns in order, leaving those which you don’t need to import empty, you’ll be fine.
"ID","Username","Password","First Name","Last Name","Display Name","Email","","Level[0-9]+ or Role ID","","","","","Auto-EOT Date ( mm/dd/yyyy )"
Following this example, this imports a new user “johndoe22”, at Level #1, with an EOT Time set to: 12/12/2012
Recurring comissions with s2Member / iDevAffiliate.
There are two ways to handle this.
1. Allow iDev to handle recurring commissions for you.
2.RECOMMENDED (Let s2Member handle this for you).
You configure an API Notification for Payments, which speaks to iDev, and processes an affiliate commission, each time an actual payment is received, either initially, or in the future (i.e. for future recurring payments).
See: Dashboard -› s2Member® -› API / Notifications -› Payment Notifications
See: iDevAffiliate -> Setup & Tools -> API Scripts -> Generate A Comission
It sounds to me like you still have a form that is trying to collect usernames/passwords on the ccBill side of things. Please make sure that your ccBill account is configured like this:
Posted: Wednesday Jun 13th, 2012 at 12:06 am
#16337
Thanks for the heads up on this request for support.
I’ve run diagnostics on your installation, and I find that your server is ignoring all of s2Member’s attempts to disable GZIP during the delivery of a PHP-based file download. Even the .htaccess rule is being ignored.
Only solution that seems to work on your installation:
I updated this file: /s2member/classes/files-in.inc.php at line #352
I changed this:
header("Content-Encoding:");
To this: (and it’s working as expected now)
header("Content-Encoding: none");
Please note that header("Content-Encoding: none");, is an invalid header specification. Which is why s2Member does not use this by default. However, there are certain cases where this header can be set to “none”, to force a server that is not listening to standard directives, to NOT apply GZIP compression. This seems to do the trick on your installation.
So that we may tune things in further as we move forward with s2Member, can you please let me know who your hosting provider is? If it’s a private server, can you please list the main server components that you’re running, and how/where GZIP compression has been applied/configured?
Thanks for the heads up on this request for support.
This feature was requested quite awhile back. However, due to structural limitations in the current release of s2Member and s2Member Pro, combined with limitations in the current payment gateways integrated with s2Member; we’ve not been able to accomplish this effectively.
The decision was made some months ago, that this would be included in the next generation of s2Member instead, which is currently under development; scheduled for release sometime this summer.
Thanks for the heads up on this request for support.
In this case, it’s only ONE instance of s2Member running on the main site of the network, so a Single-Site license is sufficient :-) If you later decide that you’d like to run s2Member on other child blogs in this Network, you will need an Unlimited Site Support License.
Yes, I’m so sorry. I left out one key component that MUST be implemented before this is going to work.
When s2Member finally receives the forwarded IPN data, it is posted back to PayPal for verification. However, since you’re changing the data in the IPN response itself, which is required in your case (i.e. the old-domain is changing to that of your new-domain); PayPal is not going to verify it, because the data is different now.
The solution to this, is to force verification. This can be accomplished with the use of an s2Member Proxy Key, which is sent to the IPN handler. All you really need to do, is change this line in the configuration section of the central IPN handler. I’ve written instructions below.
Before you can make this change, you will need to log into your s2Member installation, and check this section of your Dashboard. Here you will find the full Proxy IPN URL (which includes a Proxy Key for your installation).
Pre-Sale FAQs
Video Tutorials
Community Forum
Knowledge Base
News/Updates
s2 Codex / Docs
GPL v2 License
Contact A Human
About Us
Our Customers
Support Policy
Privacy Policy
Old Forums (READ-ONLY): The 
