Jason (Lead Developer)

My Latest Replies (From Various Topics)
Author | Replies |
---|---|
Author | Replies |
Posted: Tuesday Aug 28th, 2012 at 9:32 pm #23363 | |
![]() |
|
Thanks for the heads up on this thread.@MarkI just tested an s2Member protected file download with remote authentication using a Motorola Atrix running Android v2.3.6 and it works fine from my end of things. I’m prompted for my username/password and upon entering the proper credentials, the file download begins. If problems persist on your end, can you please let us know the specifics of what fails during your tests. For instance, does the username/password authentication window not open at all? Or it opens, but fails to authenticate you? I would try testing in the phone’s browser first. If it works there, but does not work in specific Apps, it could be related to the app itself, which might NOT be capable of dealing with protected content that requires remote authentication to access. Some apps are incapable of sending the “Authorization” header, or dealing with a 401 header in an HTTP response, which is something that browsers ARE capable of. |
|
Posted: Tuesday Aug 28th, 2012 at 5:48 pm #23356 | |
![]() |
|
I should also add the following…In no case will s2Member attempt to cancel billing profiles and/or existing charges of any kind, which are associated with a completely different payment gateway. In other words, even if you integrate PayPal, PayPal Pro, or Authorize.Net, the upgrade/downgrade processes are limited in scope, to the current gateway, and s2Member will not look for other charges which might have been associated with another payment gateway (e.g. a gateway other than the one currently in use during checkout). |
|
Posted: Tuesday Aug 28th, 2012 at 5:43 pm #23355 | |
![]() |
|
Thanks for the heads up on this thread.s2Member working together with PayPal, PayPal Pro, or with Authorize.Net; will automatically cancel previous billing profiles during an upgrade and/or downgrade from one Membership Level to another. So these are the payment gateways I would recommend for the scenario you mentioned. With ccBill, ClickBank and Google Checkout, automated cancellations are not possible for s2Member (i.e. the gateways APIs do not allow for such a thing to occur from the s2Member side of things), it must be handled manually, or by the customer. In other words, if a customer is upgrading and/or downgrading his account, under a ClickBank and/or Google Checkout subscription, they will need to cancel any previous billing plans they have with you (in most cases), by contacting you (or by contacting ClickBank directly). Or, in the case of Google Checkout, the customer can log into their Google Wallet account and cancel charges from there. In either of these cases, cancellation is handled manually, and then s2Member is notified automatically behind-the-scene that a cancellation took place, and it will terminate whatever site access was associated with the billing plan, at the correct point in time. NOTE: In the case of ClickBank… ClickBank provides customers with a link which allows them to request cancellation via ClickBank directly: https://www.clickbank.com/orderDetail.htm This can also be introduced to a customer through an The same is true for Google Checkout, as seen in the screenshot below. |
|
Posted: Tuesday Aug 28th, 2012 at 5:19 pm #23350 | |
![]() |
|
Thanks for the heads up on this thread.PayPal’s product availability chart can be found here: Website Payments Pro is available in the US (including Alaska/Hawaii), the UK, and Canada. However, s2Member Pro Forms are NOT currently compatible with Payflow Pro as a stand-alone product. s2Member Pro Forms are compatible with PayPal Pro accounts, and with PayPal Pro accounts operating under the Payflow edition, but in Australia that is currently NOT possible unfortunately (e.g. s2Member Pro Forms work best when integrated with PayPal Pro, or PayPal Pro Payflow Edition). That being said, s2Member Pro Forms are compatible with Express Checkout (available in all countries, including Australia), and if implemented properly, Express Checkout can be integrated with s2Member Pro Forms exclusively. Making it possible to accept coupon codes, collect custom fields, etc, etc… via Pro Forms, and then the actual checkout process is handled by PayPal Express Checkout (either with a PayPal account, or with a credit card, if the customer does not have a PayPal account). Please see this article for further details regarding Express Checkout: The only limitation that bothers some site owners using Express Checkout exclusively, is that PayPal requires the customer to have a PayPal account (if, and only if), you are collecting recurring charges. If you’re not collecting recurring fees, there should be little standing in your way with Express Checkout. |
|
Posted: Tuesday Aug 28th, 2012 at 4:47 pm #23344 | |
![]() |
|
Cristian brought to my attention…You posted this script, which is a hack that we posted some time ago, but should still work as expected.
In this script/hack, the custom and item_number variables are set explicitly, as seen in this portion of the code:
Since the custom and item_number variables are NOT being filled in however (according to your log files), I suspect one of the following is happening. 1. Your PayPal account is NOT actually processing IPNs through this script, and instead it’s processing them directly, or through another central IPN processing script somewhere? 2. You’ve made some modifications to the above script? If problems persist, I recommend that you attach a logging routine to this script, so you/we can see the results. Here is the full code you posted above, with an extra line of code that logs the full set of POST data being processed.
The line that handles logging, is as follows:
So you’ll want to monitor this file in the same directory: paypal-proxy-ipn.log |
|
Posted: Tuesday Aug 28th, 2012 at 4:32 pm #23343 | |
![]() |
|
Thanks for the heads up on this thread.What you’ve done is just fine, so far as I can tell from your post. If you’re not using Pro Forms, there really is no benefit to using s2Member Custom Fields over those provided by BuddyPress. So what you have will be just fine. Either way, the field data is tied directly to specific members of your site, and that’s what’s important here. |
|
Posted: Monday Aug 27th, 2012 at 7:14 pm #23216 | |
![]() |
|
Posted: Monday Aug 27th, 2012 at 7:07 pm #23214 | |
![]() |
|
Thanks for the heads up on this thread.Regarding this log entry you posted earlier… This log entry is missing the custom variable, which s2Member expects (i.e. requires) that it start with the installation domain name. This IPN would pass fine, if custom were set to:
Also, the item_number MUST match up with an s2Member Membership Level #.
Other than those two variables, everything else is fine. s2Member only requires special attention to these two variables, as everything else processed by s2Member follows the PayPal Standard IPN variables strictly.
|
|
Posted: Monday Aug 27th, 2012 at 6:57 pm #23211 | |
![]() |
|
Thank you for the reply!I’m updating our diagnostic report on this, and we’ll continue our attempts to reproduce this. So far I’ve been unsuccessful, even with content filters applied, but we’ll do our best to continue the search. |
|
Posted: Monday Aug 27th, 2012 at 6:49 pm #23209 | |
![]() |
|
Thanks for the heads up on this thread.My investigation of this installation turned up the following issues.
Correct. In the case of BuddyPress, the /create/ URL will result in a 404 error introduced by BuddyPress itself, whenever access to create blogs is not possible for the current user (for any reason). So if s2Member is configured NOT to allow blog creation access, BuddyPress will interpret this as a 404 error, because the page used to create a new blog does not even exist in the eyes of BuddyPress. As you mentioned, this is the expected behavior.
This would also be the expected behavior. s2Member will redirect the user to the Membership Options Page, because they do not have access (i.e. in this case there IS a URI Restriction implemented within s2Member), and therefore s2Member will intervene, by redirecting anyone without access. However, what’s NOT working properly, is the redirection URL itself, which in this case results in a 404 error. Upon a deeper investigation, I find this URL /membership-options/ no longer exists. It appears that you renamed this page to /options/ instead, which does work properly. I updated your s2Member General Options, and s2Member now has the right Membership Options Page (i.e. /options/, instead of /membership-options/). Please let me know if problems persist. |
|
Posted: Monday Aug 27th, 2012 at 6:18 pm #23202 | |
![]() |
|
Investigation completed.
Thanks for your patience. I’ve looked through your log file entries, and I find some very confusing scenarios where s2Member is lead to believe that transient data entries exist for IPNs that are brand new, and have never been processed before. This is not the expected and/or normal behavior. Upon further investigation, I am lead to believe that there might be a plugin conflict that exists on your installation, related to one of the following. 1. A caching plugin, which has object caching enabled (and perhaps not behaving properly). I would suggest that you disable any plugins that you believe might be related to the above (at least temporarily), and see if the problem goes away. If problems persist, please submit a list of all of the plugins that you are currently running together with s2Member. Also, please submit a Dashboard login for us via our private contact form here: s2Member® » Private Contact Form |
|
Posted: Monday Aug 27th, 2012 at 5:51 pm #23200 | |
![]() |
|
Investigating this now.
~ Thanks for your patience. I’m very sorry for the delay. You will have a response shortly. |
|
Posted: Saturday Aug 25th, 2012 at 3:07 pm #23072 | |
![]() |
|
Thanks for the heads up on this thread.We will keep an eye on this issue in the future. Currently s2Member is not in control of routines in the authoring of posts, and only restricts data from users viewing the page, therefore any issues with the post’s author is most likely an issue with core WordPress functionality or JWPlayer itself. Please keep in mind that you can change the author from within the WordPress Dashboard if any problems persist. |
|
Posted: Friday Aug 17th, 2012 at 1:41 pm #22378 | |
![]() |
|
Investigation completed.I’m finding that your log files contain several references to these two Payflow errors.
These two errors, while appearing somewhat different, both indicate the same thing. It appears from our inspection of your log files that record communication between s2Member and the PayPal Payflow API, that your PayPal account is currently not setup to allow for recurring transactions. Here are possible solutions:1. Try removing all of your Payflow configuration options from the s2Member Dashboard panel, in hopes that your current PayPal Pro account will work without it. Not all PayPal accounts are designed to work with the Payflow API. If you are absolutely sure that you’ve already setup Recurring Billing service with PayPal, this might be the problem. So, you can try disabling Payflow integration by removing the s2Member configuration options for Payflow. This places s2Member back into a normal PayPal Payments Pro integration, which still allows for the processing of recurring transactions, but under a different API (i.e. the PayPal Pro API, instead of the Payflow API). However, please note that you will still need to have a PayPal Pro account setup which supports the PayPal Recurring Billing service, regardless of which API s2Member is working with, Recurring Billing service must be enabled. 2. Contact PayPal to ensure that your current Payflow API supports Recurring Billing service. Please let us know if problems persist. |
|
Posted: Friday Aug 17th, 2012 at 1:15 pm #22373 | |
![]() |
|
Details received. Thank you.
~ Investigating now. |
|
Posted: Friday Aug 17th, 2012 at 1:11 pm #22371 | |
![]() |
|
Thanks for the heads up on this thread,
|
|
Posted: Friday Aug 17th, 2012 at 1:02 pm #22370 | |
![]() |
|
Thanks for the feedback guys! We’re working hard to improve this.
|
|
Posted: Friday Aug 17th, 2012 at 12:47 pm #22369 | |
![]() |
|
Thanks for the heads up on this thread.The topic being discussed here is related to two separate questions.
Specific Post/Page Access Links are controlled by your configuration of Unique IP Restrictions under: Dashboard -› s2Member® -› Restriction Options -› Unique IP Access Restrictions. So the answer to this question, is that a single user will be able to share his link with as many unique IP addresses as you’ve configured to allow, after which other users will start being denied. This is designed to allow a single customer access from multiple IP addresses (i.e. a personal computer, a laptop on the road, etc), but to give a site owner control over what they deem acceptable. After a customer exceeds the number of unique IP addresses that you’ve decided to allow, the link will be blocked automatically (i.e. for whatever punishment period you configure). See: Dashboard -› s2Member® -› Restriction Options -› Unique IP Access Restrictions
The current release of s2Member creates Specific Post/Page Access Links in a way which places all of the autorization details in the link itself (i.e. in the encrypted string which appears in the link, and it is NOT contained in any database table). This makes it possible for Specific Post/Page Access to remain disconnected from any membership or registration on the site. However, while this does provide for some great advantages, it also poses a serious problem for site owners that wish to revoke access for one reason or another, with respect to Specific Post/Page Access. In the current releases of s2Member, it is NOT possible to revoke access to a Specific Post/Page Access Link. At least, not in any simple way (i.e. via any UI panel in the Dashboard). The only way to revoke access to a Specific Post/Page Access Link is by blocking the customer’s IP address conditionally, through code of your own. We recognize this as a problem, and efforts have been underway for some time to resolve this in the next generation of s2Member, which has been accomplished, and a beta release will be available soon. |
|
Posted: Friday Aug 17th, 2012 at 12:21 pm #22364 | |
![]() |
|
Thanks for the heads up on this request for support.Having more than one member with the same paid Subscr. ID would be produce very unpredictable results within the context of s2Member itself. Payment gateways supply a unique transaction and/or subscription ID for s2Member, which is associated with a specific customer. s2Member expects this value to be a unique identifier for a particular paying customer, so having more than one customer with the same ID is not advised. s2Member also associates each paid subscription ID with the underlying gateway. So each paying customer will have these two meta fields:
(always unique for each paying customer) I would suggest that you add some additional meta fields of your own, instead of modifying these which the s2Member software itself uses. That way you won’t run into any compatibility issues. |
|
Posted: Tuesday Aug 14th, 2012 at 3:30 pm #22023 | |
![]() |
|
Investigation completed.I found that your PayPal account is sending IPN data back to your s2Member installation with a “gb2312” charset. For instance, your paypal-ipn.log file contains lines like this:
Unfortunately, PHP does not support “gb2312”, but it does support “GBK”. I’m attaching a patch file that should resolve the issue that’s being reported here. If you decide to implement this patch, please provide any feedback that you can. http://d1v41qemfjie0l.cloudfront.net/s2member/uploads/paypal-utilities.inc_.php_.zip Reference article: http://www.php.net/manual/en/mbstring.supported-encodings.php |
|
Posted: Tuesday Aug 14th, 2012 at 3:14 pm #22021 | |
![]() |
|
Thank you. Details received.
~ Investigating now. |
|
Posted: Tuesday Aug 14th, 2012 at 3:11 pm #22020 | |
![]() |
|
Thanks for the heads up on this request for support.This ticket was resolved via email. Please let us know if you have any further trouble. |
|
Posted: Tuesday Aug 14th, 2012 at 3:09 pm #22019 | |
![]() |
|
Thanks for the follow-up.Yes, that hosting configuration will be incompatible with s2Member. Any hosting company which blocks the server from making requests to itself (i.e. for s2Member, or for WP_Cron, or for any other script that needs to post HTTP requests to itself for any reason), will be a problem. I recommend any of these hosts: Also recommend: If possible, please tell us who your current hosting provider is? |
|
Posted: Saturday Aug 11th, 2012 at 12:22 pm #21782 | |
![]() |
|
Thanks for the heads up on this request for assistance.@ AndyI’ve just completed a review and full diagnostics on your installation. I found that you may have a firewall issue (or a PHP configuration issue at the server level), which is preventing your site from connecting over HTTP to itself. While your site is capable of connecting via HTTP to outside networks, connections from your server, to scripts that reside on the same host are failing. This is indicative of firewall configuration conflicts. I recommend contacting your hosting provider with the details below, so they can start an investigation on their end of things. I’ve installed a test script here, which your hosting company can use to reproduce the issue. Until this issue is resolved at the server level, s2Member will not behave as intended.
|
|
Posted: Saturday Aug 11th, 2012 at 10:14 am #21776 | |
![]() |
|
@AllanThanks for your patience.OK. Based on the log entries you’ve posted, I’m unable to find a logical reason why this is failing on this one particular installation. I’d like to see the log files in their entirety, so I can see the broader perspective, and that should help us to shed light on the underlying cause of this for you. If it’s possible to send us the full details, please submit a private contact form entry via this URL: |