Jason (Lead Developer)

My Latest Replies (From Various Topics)
Author | Replies |
---|---|
Author | Replies |
Posted: Tuesday Mar 13th, 2012 at 1:55 pm #8028 | |
![]() |
|
The EOT Time in your Dashboard, only controls access to the site. Billing is handled by your payment gateway. s2Member configures the Recurring Profile for billing, according to your Pro Form Shortcode configuration, and then it hands all billing routines over to your payment gateway. After that, s2Member will listen via IPN (Instant Payment Notification service) for any future payments that are processed, possible refunds, cancellations, chargebacks, and other related events. An EOT Time will be set automatically by s2Member whenever access to the site should be denied for one of many different reasons. See Also: Dashboard -› s2Member® -› PayPal® Options -› Automatic EOT Behavior Please let me know if problems persist :-) Thanks! |
|
Posted: Tuesday Mar 13th, 2012 at 1:49 pm #8025 | |
![]() |
|
Thanks for your patience.
This should work nicely for you. PayPal will charge the customer all at once for the Initial/Trial period of 13 months, because this period does NOT recur under any circumstance. So to answer your question, the charge would be $100 for 13 months of access, then it would recur at the rate of $100/year.
Yes, the customer will ALWAYS renew at that rate, even if you expire the coupon code. The coupon code expiration prevents it from being used to create any new recurring profiles, but it does not affect any existing billing profiles that were already created in conjunction with the coupon code in the past. |
|
Posted: Tuesday Mar 13th, 2012 at 1:08 pm #8020 | |
![]() |
|
Thanks for the heads up on this thread. |
|
Posted: Tuesday Mar 13th, 2012 at 1:04 pm #8019 | |
![]() |
|
Hi Lee. Thanks for the follow-up.
Yes, that is absolutely correct.
Yes, that is correct. I’m sorry for any confusion.
Yes, that is correct. I’m sorry for any confusion. |
|
Posted: Tuesday Mar 13th, 2012 at 12:58 pm #8018 | |
![]() |
|
Hi Rayna. That link seems to be working properly from my end now. Upon clicking the link I’m redirected to your Membership Options Page, which is expected, since I’m not logged into your site. If problems persist, please send us a Dashboard/FTP login and we’ll take a quick look for you. |
|
Posted: Tuesday Mar 13th, 2012 at 12:54 pm #8017 | |
![]() |
|
Hi Terri. Thanks for your inquiry.
s2Member is designed for end-users of a site, and not for Users/Members that actually gain access to your Dashboard in some way. This could certainly be accomplished, using s2Member as a framework on which to build such a site, but it’s not something that s2Member provides by default. Here are some links that might help in your work to integrate this.
See: http://codex.wordpress.org/Roles_and_Capabilities Regarding your specific request here to block and/or grant access to certain admin panels. This can be accomplished through custom coding, where the permissions required to view certain admin panels is dictated by whether a specific User has the Capability required. The required Capability is determined whenever WordPress and/or s2Member adds the menu page into the WordPress core. Your developer could begin their work by searching through WordPress and s2Member’s source code, for calls to these WordPress functions. By default, all s2Member menu panels require a site administrator with the create_users Capability. If you need to change that, you would need to modify code inside this s2Member source file: /s2member/includes/classes/menu-pages.inc.php starting at this line (see source file here). |
|
Posted: Tuesday Mar 13th, 2012 at 12:42 pm #8013 | |
![]() |
|
Hi Trina. Thanks for your inquiry. If you log into your Dashboard, and go to your list of installed plugins, you should find the s2Member Framework in that list. Alongside the s2Member Framework, there should be a bold note there regarding your current installed version of s2Member Pro as well. Is that not present either? If problems persist, please submit a Dashboard login for us here. We’ll install it for you :-) |
|
Posted: Tuesday Mar 13th, 2012 at 12:39 pm #8012 | |
![]() |
|
Thanks for your purchase Kim! |
|
Posted: Tuesday Mar 13th, 2012 at 12:38 pm #8011 | |
![]() |
|
Yes, that is something we’re working on :-) |
|
Posted: Tuesday Mar 13th, 2012 at 12:29 pm #8010 | |
![]() |
|
Hi there. Thanks for reporting this important issue. The error you reported:
When someone attempts to log into their account, and that request fails (i.e. wrong Username/Password combo); s2Member will record this failed attempt. If too many failed attempts occur within a short period of time, s2Member will start displaying the error message you reported, but ONLY to the User that caused the error. This is known as Brute Force IP/Login Restrictions. The options for this can be configured from your Dashboard here: If you’re seeing this error when you should NOT (i.e. something weird is going on), I would start looking at any plugins and/or server extensions that deal with caching. Is it possible that another User of your site caused this error, but now it’s been cached by some custom extension, so everyone sees it now? |
|
Posted: Tuesday Mar 13th, 2012 at 12:18 pm #8009 | |
![]() |
|
Hi there. Thanks for your inquiry.
No, I’m sorry, that won’t work. There is a difference in the way each of these APIs communicate. s2Member Pro is designed to communicate with the Website Payments Pro API. So you’ll need a PayPal Website Payments Pro account, and you’ll need Recurring Billing added to your Website Payments Pro account. Payflow Pro is something else entirely. s2Member does not speak the Payflow Pro language. See Also: Video » By PayPal®, Service Introductions (Highly Recommended) |
|
Posted: Tuesday Mar 13th, 2012 at 12:04 pm #8007 | |
![]() |
|
Hi there. Thanks for your inquiry. Well, this is getting into some custom coding, so not really within our Support Policy, sorry.
Yes, that sounds like it should work nicely for you.
The example that I gave in that KB article, would be considered a RESTful web service API, and I’d recommend cURL or just use |
|
Posted: Tuesday Mar 13th, 2012 at 11:31 am #8002 | |
![]() |
|
On a Multisite Network installation, you will choose either a sub-directory style configuration, or a sub-domain configuration. In other words, each of your Child Blogs are either in a virtual sub-directory, like http://www.domain.com/virtual-sub-directory/, or in a sub-domain like: mysite.domain.com. In either case, your File Download Links need to contain that information. For instance, this is correct:
If that link is not working for you, please confirm the following: Did you configure this instance of the s2Member plugin? Each Child Blog runs it’s own instance of WordPress and it’s own instance of s2Member. Each instance needs to be configured. It appears from your link that you’ve NOT yet configured any Basic Download Restrictions for s2Member on this particular Child Blog? |
|
Posted: Tuesday Mar 13th, 2012 at 11:20 am #8000 | |
![]() |
|
Thanks for the heads up on this thread. @ Lee Keels
Well, it’s not ccBill that pulls the EXPIRE status. It’s s2Member that pulls the EXPIRE status *from* ccBill. This works very well, and as ccBill mentioned, an EXPIRE status should always occur eventually (even after a cancellation has taken place) at the correct point in time. s2Member listens to all of these events, and it will respond appropriately for you. However, it’s ccBill’s job to notify s2Member about these events, so that a response is triggered by your website.
It’s important to understand that a “cancellation” does not always warrant an immediate EOT.
Taken from the documentation in your Dashboard:
s2Member will not process an EOT ( End Of Term ) until the User has completely used up the time they paid for. In other words, if a User signs up for a monthly Subscription on Jan 1st, and then cancels their Subscription on Jan 15th; technically, they should still be allowed to access the site for another 15 days, and then on Feb 1st, the time they paid for has completely elapsed. At that time, s2Member will remove their Membership privileges; by either demoting them to a Free Subscriber, or deleting their account from the system ( based on your configuration ). s2Member also calculates one extra day ( 24 hours ) into its equation, just to make sure access is not removed sooner than a Customer might expect. I’ve inspected your log files, and I see no details coming from ccBill with an EXPIRE status yet. So that’s why s2Member has not terminated access for those accounts. ccBill has not EXPIRED any of your customers yet, according to the ccBill DataLink service. Understanding WhyWhat was cancelled exactly? (i.e. what did the customer originally sign up for?). Does your customer still have time left, which they had already paid you for prior to cancelling? Was it an actual “cancellation”? Who processed the cancellation, ccBill? Or you as the site owner? |
|
Posted: Saturday Mar 10th, 2012 at 6:47 am #7827 | |
![]() |
|
Thanks for the follow-up Lee. I appreciate it. Yes, I can imagine. s2Member does pull the EXPIRE status already. You should have a log file indicating s2Member’s activity in this regard, inside /wp-content/plugins/s2member-logs/ccbill-dl.log |
|
Posted: Friday Mar 9th, 2012 at 5:36 pm #7799 | |
![]() |
|
You’re VERY welcome. |
|
Posted: Friday Mar 9th, 2012 at 5:22 pm #7794 | |
![]() |
|
Feature request accepted. Thank you! |
|
Posted: Friday Mar 9th, 2012 at 3:26 pm #7743 | |
![]() |
|
Investigation completed. Thanks for your patience. Upon further review, I find that your WordPress installation is running the CloudFlare plugin. This plugin creates a conflict with other plugins that attempt to read the value of I’ve corrected this on your site by modifying this file:
I’ve also notified the CloudFlare team about this issue. Email To CloudFlare
Hi there. I’m a WordPress plugin developer for s2Member®. We have several clients reporting conflicts with CloudFlare for WordPress. Upon investigation of these issues, we find that your plugin rewrites the $_SERVER[“REMOTE_ADDR”] value, and understandably so. However, this rewrite needs to occur MUCH earlier in the Hook priorities list, so that other plugins attempting to read the value of $_SERVER[“REMOTE_ADDR”] on the init action Hook, get the *right* value.
Suggested modification: |
|
Posted: Friday Mar 9th, 2012 at 2:04 pm #7738 | |
![]() |
|
@Mark R. I found that your installation of PHP was running in SAFE MODE, which has some side effects in WordPress, and triggers an invalid internal redirection due to a bug that exists in the WordPress WP_Http class. I’ll save you the rest of the boring details related to this minor WordPress bug. Long story short, we’ve found a way to work around this issue in the release of s2Member v120309, by forcing a WP_Http redirection value of 0 during Amazon S3/CloudFront configuration. This allows s2Member’s auto configuration routines to also succeed in PHP installations running in SAFE MODE. Your test WordPress installation has now been fully configured with Amazon S3/CloudFront. If you have other installations that you’d like to integrate, please make sure that you upgrade to s2Member v120309 first, or disable SAFE MODE in your /php.ini file. See Also: http://php.net/manual/en/features.safe-mode.php
See Also: s2Member® Unified Changelog » v120309
|
|
Posted: Friday Mar 9th, 2012 at 11:48 am #7734 | |
![]() |
|
FYI: Ratings widgets now work as expected. Some of you reported this recently. We’ve moved into using ONLY User Ratings here in the forum. A bug that existed previously was causing some rating widgets not to display when duplicated into multiple replies. Now works as expected. |
|
Posted: Friday Mar 9th, 2012 at 11:38 am #7733 | |
![]() |
|
Email received. Thank you. |
|
Posted: Friday Mar 9th, 2012 at 8:52 am #7726 | |
![]() |
|
Gotchya. Will do. Thanks. |
|
Posted: Friday Mar 9th, 2012 at 8:02 am #7721 | |
![]() |
|
This was made possible in the release of s2Member v120308. |
|
Posted: Friday Mar 9th, 2012 at 8:01 am #7720 | |
![]() |
|
Hi Mike. Thanks for the follow-up. Yes, that’s correct. I’m sorry, but we don’t have any immediate plans to support administrative permissions with s2Member. Our focus with s2Member and s2Member Pro is on User accounts only.
s2Member is designed for end-users of a site, and not for Users/Members that actually gain access to your Dashboard in some way. This could certainly be accomplished, using s2Member as a framework on which to build such a site, but it’s not something that s2Member provides by default. Here are some links that might help in your work to integrate this.
See: http://codex.wordpress.org/Roles_and_Capabilities |
|
Posted: Friday Mar 9th, 2012 at 7:17 am #7717 | |
![]() |
|
Investigation completed. Thanks for your patience.
No, I don’t believe that’s an issue. It’s not s2Member that’s adding the leading 0, it’s ccBill doing this. It’s related to the sub-account prefix they use in communication with IPN and DataLink services.
First off, a “cancellation” by a customer, which cancels any future payments, does NOT always warrant an immediate EOT on the s2Member side of things (they might still have time left, which they’ve already paid for). Also, with ccBill, the DataLink service connection is only made once per day. So any rebills/refunds/chargebacks/expirations that occur, will only be processed once each day, whenever s2Member pulls all of these events at once from ccBill in it’s scheduled routine, via the s2Member Auto EOT System.
See Also: Dashboard -› s2Member® -› ccBill® Options -› Automatic EOT Behavior However, in this test case — we actually have a two part problem. 1. By default, s2Member’s integration with the ccBill DataLink service handles ccBill expirations (i.e. EOTs that occur as a result of a Subscription expiring naturally, for one of many different reasons). s2Member also handles refunds, chargebacks, and rebill payments that occur on the ccBill side. However, s2Member does NOT handle customer “cancellations” by default, because ccBill does NOT enable this functionality until each merchant (i.e. YOU) request this to be enabled on your ccBill account, and ccBill approves your request to do so. Please note this screenshot. 2. Once you receive approval from ccBill, you will need to follow these instructions. This is a required step, telling s2Member that your ccBill account has been empowered with the ability to pull cancellation data from the DataLink Service Suite at ccBill.
I’m making a note of this now, so that in future releases of s2Member Pro, this will be included in the ccBill configuration panel. That way others won’t need to hunt this down like you did.
Please create this directory and file:
* Note. Do NOT enable this until ccBill has approved your request. Adding this before your request is approved, will result in errors being returned by the DataLink API, and s2Member would be unable to pull *any* events.
Why does ccBill require approval for DataLink cancellations?
That’s a question best answered by ccBill. However, I suspect it’s because a software application like s2Member, needs to be aware that a cancellation does NOT always warrant an immediate EOT (termination). In many cases, the customer will have already paid for X number of days/weeks/months/years. The cancellation itself does not always warrant a immediate termination. s2Member is aware of this, and it will handle things appropriately. If you are questioned about the integrity of your application, please let ccBill know that your application is aware of this concern. |