|
|
Thanks for the heads up on this thread :-)
This issue has been identified and will be corrected in the next maintenance release. Until then, I’m attaching a PATCH file. Please unzip and upload the attached file, allowing it override your existing copy of /s2member/includes/classes/roles-caps.inc.php
The underlying cause was not really that s2Member® was removing any caps, but that it was filtering the list of caps that bbPress uses; thereby causing an indirect removal of the read, level_0 and access_s2member_level[0-9]+ caps whenever bbPress was uninstalling and/or deactivating itself.
http://d1v41qemfjie0l.cloudfront.net/s2member/uploads/roles-caps.inc_.php_.zip
Thanks for reporting this Ross!
|
|
|
Thanks for the heads up on this thread :-)
I think that would be a good idea for s2Member® to include the first/last names by default. Currently, it searches only the Display Name field. We’re going to have this updated in the next maintenance release.
Until then, I’m attaching a PATCH file for you. If you’d like to patch your existing installation, please download and unzip the attached file. Please upload the file to your installation, allowing it to override your existing copy of: /s2member/includes/classes/users-list.inc.php
http://d1v41qemfjie0l.cloudfront.net/s2member/uploads/users-list.inc_.php_.zip
If you look at s2Member’s source code in this file, you will find that it exposes several additional WP filters that would allow you to customize user searches even further. Please see class method users_list_query in this file.
|
|
|
Thanks for the follow-up :-)
Remove this file also and you should be good:
/wp-content/plugins/wp-settings.php (should not exist)
|
|
|
Thanks for the heads up on this thread :-)
This is a problem in the existing release, because Authorize.Net actually allows charges up to $99,999.00 now; if approved by your underlying merchant bank. We’re having this updated for the next maintenance release of s2Member® Pro.
Until then, I’m attaching a patch file for you; which will allow you to change the ra="" value in your Shortcode without triggering an error in the Pro Form. If you would like to implement this patch, please download the attached ZIP file; extract and upload the file; overriding your existing copy of: /s2member-pro/includes/classes/gateways/authnet/authnet-responses.inc.php
http://d1v41qemfjie0l.cloudfront.net/s2member/uploads/authnet-responses.inc_.php_.zip
|
|
|
Thanks for the heads up on this thread :-)
1] I am getting recurring = 5 in logs (It is taking the value of mc_amount3) even if I set recurring=1 in notify url.
Is this normal?
This is normal, and to be expected. Some of the variables that you pass are actually translated by s2Member® into data that can be passed into API Notifications and processed by site owners in some creative ways.
Since you are passing recurring=1, it indicates that mc_amount3 will recur; and s2Member® sets the value of recurring to 5 (indicating that amount will be charged on a recurring basis).
You can make a little more sense of this here.
See: Dashboard -› s2Member® -› API / Notifications -› Signup Notifications
(click screenshot to enlarge please)
2] If the above behaviour is normal, how do I process the recurring payments? Do I need to create a system to monitor and trigger the recurring payments?
The above behavior is correct. Yes, any recurring billing that occurs, must take place remotely; and then you will need to send s2Member® an IPN (like PayPal® does) with txn_type=recurring_payment or txn_type=subscr_payment. This lets s2Member® know that a payment took place.
|
|
|
Thanks for the heads up on this thread :-)
There is no way to accomplish this without modifying the code; or using a custom Pro Form template; unfortunately. The section that you depict in your screenshot is strictly designed for tax calculations to be displayed before checkout.
If you want to display other custom details, you can either use the desc="" Shortcode Attribute, or create a custom Pro Form template and perform some additional calculations of your own. In the mean time, I will accept this is as a feature request. Thank you!
See also: Knowledge Base » s2Member® Pro Forms -› Custom Templates
See also: Dashboard -› s2Member® -› PayPal® Pro Forms -› Shortcode Attributes (Explained)
Specifically the desc="" Shortcode Attribute.
|
|
|
Thanks for the heads up on this thread :-)
The reason for this occurring on your installation is because this file actually DOES exist on your installation:
/wp-content/plugins/wp-load.php I’m not sure why though. Seems like a mistake to me :-)
s2Member® will start searching from it’s own directory on back up the directory tree until it finds /wp-load.php. In this case, you have a /wp-load.php file inside the /wp-content/plugins/ directory. I suspect it’s there by mistake, because that is a non-standard location.
|
|
|
Thanks for the heads up on this thread :-)
That specific functionality is not built into s2Member. However, you could certainly accomplish such a thing by simply providing a member with a link that leads to the page where your s2Member® File Download link is displayed. s2Member® generates the URL for you; so you can do whatever you like with that URL. If you would like to push it to browser for an automatic download; you might do something like this.
<script type="text/javascript">
setTimeout(function(){
location.href = '[s2File download="example-file.zip" /]';
}, 5000);
</script>
See also: Dashboard -› s2Member® -› Download Options -› Shortcode Attributes & API Functions
See also: http://www.w3schools.com/jsref/met_win_settimeout.asp
|
|
|
Thanks for the heads up on this. PayPal appears to be moving lots of things around right now. I’m not aware of this rule having been changed. It’s still in all of the most recent API docs.
The 20% rule still applies. It is still mentioned here in the latest docs. Although it is no longer mentioned specifically for PP Standard, it does impact both PayPal® Standard and PayPal® Express Checkout (in my sandbox testing).
However, it does NOT impact s2Member® Pro Forms because we workaround this issue by retiring the previous Recurring Billing Profile during an upgrade/downgrade; and simply replace it with a new one. Therefore, this is not of concern w/ s2Member® Pro; only with PayPal Standard Buttons where an existing customer is upgrading/downgrading through a Subscription Modification Button.
We will have the inline docs for s2Member® updated in the next maintenance release. Thank you!
|
|
|
Regarding stutter; this could be caused by a buffer length that is too short for some devices.
You can add this to your s2Stream Shortcode.
[s2Stream player_option_blocks="rtmp:{bufferlength:10}" /]
Regarding this option for JW Player…
http://www.longtailvideo.com/support/jw-player/28854/using-rtmp-streaming
See also: Knowledge Base » JW Player® w/ s2Stream Shortcodes
|
|
|
Thanks for the heads up on this thread :-)
I am VERY sorry. You are correct on this point; I was wrong.
I’m having the s2Member® documentation updated to better explain this.
MAX FAILED PAYMENTS
rra="2" Reattempt billing when/if a recurring payment fails; exactly X number of times; and then automatically suspend the customer’s account (e.g. the customer loses access). By default, PayPal® will retry a maximum of 2 times whenever rra="2"; after that, a Subscription would be terminated due to Max Failed Payments having been reached. The value of this attribute configures Max Failed Payments. A setting of rra="2" means that you allow a maximum of 2 failed payments. Setting rra="0" means that you allow an infinite number of failed payments.
From the PayPal® API docs…
|
|
|
Thanks for the heads up on this thread :-)
I just did a quick review of your log files.
I find that your existing Payflow integration is configured properly, because API calls are succeeding; so your Payflow Credentials are correct.
Regarding Express Checkout…
I see the following in your most recent paypal-ipn.log file entry.
'charset' => 'windows-1252',
'first_name' => 'Rob',
'mc_fee' => '0.04',
'notify_version' => '3.7',
'custom' => '',
'payer_status' => 'unverified',
'txn_type' => 'web_accept',
'txn_id' => '31B920102P4550115',
and so on —
's2member_log' =>
array (
0 => 'IPN received on: Sat Mar 2, 2013 12:41:27 pm UTC',
1 => 's2Member POST vars verified through a POST back to PayPal®.',
2 => 'Unable to verify `$_SERVER["HTTP_HOST"]`. Please check the `custom` value in your Button Code. It MUST start with your domain name.',
),
If you are absolutely sure the custom="" Shortcode Attribute is defined in the original PayPal Button or Pro Form Shortcode; I would look elsewhere. The custom="" value is empty in this IPN log entry; indicating there is a problem somewhere. Are you running a central IPN processor or anything non-standard that might be losing the custom value?
On further inspection, it seems this transaction did NOT originate from the Shortcode you posted earlier, because this is a Buy Now transaction (web_accept) and your Pro Form Shortcode is setup for Recurring Billing. If you have a second Shortcode for Buy Now transactions, it could be that one that’s missing the custom="" Shortcode Attribute.
It’s also possible that this particular IPN is being sent to s2Member; but it actually originated from somewhere else (which is why it could be missing the custom="" value). I noticed it is ALSO missing the item_number value as well as other details that s2Member always defines when it processes a transaction through PayPal®. This is why s2Member® will check for the custom="" value to begin with, to ensure that it’s NOT processing a transaction from another integration on the same PayPal® account (perhaps from another site that you operate).
Regarding this paypal-ipn.log entry…
's2member_log' =>
array (
0 => 'IPN received on: Wed Feb 27, 2013 10:59:05 pm UTC',
1 => 's2Member POST vars verified with a Proxy Key',
2 => 's2Member originating domain ( `$_SERVER["HTTP_HOST"]` ) validated.',
3 => 'Not processing. Duplicate IPN.',
4 => 's2Member `txn_type` identified as ( `web_accept|subscr_signup` ).',
5 => 'Duplicate IPN. Already processed. This IPN will be ignored.',
),
This indicates one of two things.
1. It’s actually a duplicate IPN that s2Member® really should ignore.
2. s2Member® is unable to properly get/set WordPress® Transient data due to plugin conflicts; and is therefore unable to properly detect duplicate IPN data because it does NOT have proper return values from get_transient() or set_transient(). See: http://codex.wordpress.org/Transients_API
Object caching plugins are known to cause issues like this.
~ On your installation I found the following potential conflict.
|
|
|
Also, are you dealing with a custom template (i.e. custom PHP code)?
If so, what WordPress® function is being used to query posts? Please show some example code. Thanks!
|
|
|
Thanks for your inquiry. ~ We appreciate your patience :-)
s2Member® does support Custom Post Types through Alt View Restrictions; so I’d like to find out more about why this is causing trouble for you. So far I’ve been unable to reproduce this behavior.
How have you protected your Custom Post Type content exactly with s2Member?
Through Post Access Restrictions, URI Restrictions, or how exactly? Thanks!
I would also run a quick test to be sure this function is working properly on your installation.
|
|
|
Thanks for the heads up on this thread :-)
If the plugin “Social Login from OneAll” is providing a separate interface for registration; you would need to contact the developer of that plugin and inquire about this possibility. I would ask the developer if it’s possible to use a custom template; and if so, that would be a good road to follow I would think.
On the other hand, if the plugin integrates with the default WP Login/Registration form like s2Member® does, you could simply add a new Custom Registration/Profile Field with s2Member® and make sure it’s associated with “all” Membership Levels (or at the very least, with Membership Level #0) for Free Subscribers.
See: Dashboard -› s2Member® -› General Options -› Registration/Profile Fields
(click to enlarge screenshot please)
|
|
|
If you are on a Cloud computing model, I would check with your hosting company about the /wp-content/cache/ directory. Ask them if this directory is being served from a CDN; or from local file storage; or from a network file storage? Ask them why PHP scripts would have trouble reading/writing (and locking) files in that directory.
|
|
|
Thanks for the follow-up :-)
I would suggest that you contact your hosting company and ask them to investigate this for you. It sounds there could be an incompatibility in the Apache configuration of some kind. An email to hosting support about Quick Cache compatibility may help. I would ask them specifically why PHP scripts would be unable to write to a .lock file. Another thing you can try is to open this file:
/wp-content/plugins/quick-cache/includes/templates/handler.tpl.php
At line #252 find these two PHP calls where you see the @ sign. Remove the @ sign to unsuppress server error notices; and this may result in an error message on-site that could give you some direction on where to go next.
$mutex = @fopen (WP_CONTENT_DIR . "/cache/qc-l-mutex.lock", "w"))
@flock ($mutex, LOCK_EX);
After removing the @ signs, visit your Dashboard and disable (then re-enable) Quick Cache.
Monitor your PHP and Apache error logs now. Anything useful there?
|
|
|
Thanks for the follow-up :-)
I went to your test page and published it, complete the registration form and it when out to paypal ($0.01) and returned back to the same registration page with a feedback message at the top. In snooping the source I see the expected google tracking code for the transaction in the footer…soooo it all looks good, including the transaction showing up in Google!
So whats the deal with our version of the shortcode – Is it because we are using a custom return page?
success=”/congratulations/”
OK. So it’s working in the default implementation because you verified the snippet is there. Have you been able to verify the snippet is there on your /congratulations/ page as well? It’s just not showing up in Google Analytics?
If that’s the case, you might check your GA account and be sure there are no exclusions for the /?s2p-v=value that s2Member® passes your Custom Return URL on Success. See also: Dashboard -› s2Member® -› PayPal® Pro Forms -› Custom Return URLs Upon Success -› Verifying Integrity of Replacement Codes w/ s2p-v
Also, you might check to be sure your /congratulations/ page is not configured as a Goal or Funnel page in your GA account; just in case there is some conflict in your GA configuration that’s preventing ECOM tracking from working as expected on that page. Also, testing this with a different success="" value might help.
To answer your question though, no. I don’t see any reason why this would not work on your /congratulations/ page, so long as it uses a WP template that calls upon wp_footer() as it should. Which it is; I verified this on your installation.
If problems persist, I would suggest setting up a quick test installation of WordPress® and making an attempt to reproduce this there. I’ve run a few recent tests against a clean installation — running a default WP theme; and I was unable to reproduce the issue you’ve described. Even with the success="" attribute in use. If nothing else, this type of testing might shed light on the underlying cause for you; allowing you to narrow things down.
|
|
|
Thanks for the follow-ups :-)
If this file exists: /wp-content/cache/qc-l-mutex.lock, it means that Quick Cache was either configured to use the FLOCK method for file locks; or the Semaphore method was not possible on your hosting platform; so Quick Cache is reverting the the FLOCK method as a good backup choice.
It is normal for this file to be 0 kbs: /wp-content/cache/qc-l-mutex.lock
This file exists simply as a locking mechanism (i.e. it simply needs to exist); so that Quick Cache can obtain an exclusive lock over files in this directory while it’s writing cache entries.
If you receive this error in Quick Cache comments:
Quick Cache: failed to write cache, unable to obtain a mutex lock at the moment. Quick Cache will try again later.
Here are the steps to resolve the issue.
1. Delete the existing file: /wp-content/cache/qc-l-mutex.lock
This will release any existing locks on that file, making it possible for Quick Cache to recreate the file and obtain an exclusive lock on this file once again; as it needs to.
Why would Quick Cache lose the ability to obtain an exclusive lock on this file?
It’s very uncommon for this to occur, but we have seen it happen on sites that move or change directory permissions on the /wp-content/cache/ directory; or on sites that are struggling to keep up with traffic volume; where Apache or PHP is crashing or being restarted periodically.
2. Check directory permissions on the /wp-content/cache/ directory. You need 755 or higher. Whatever is necessary for Quick Cache to have write-access to that directory. If 755 does not do it (755 does the trick on most hosting platforms); but if it does not, you may have to go all the way up to 777 with your permissions.
3. If the error continues to come back periodically, it could indicate a slow disk on the underlying server that is hosting your site (i.e. disk writes are not occurring fast enough to keep up with your traffic volume). Raising your Cache Expiration Time in the Quick Cache configuration panel can help to resolve this, because that results in fewer cache files being written by Quick Cache.
So what is the purpose of a Mutex Lock File exactly?
If two or more visitors hit the same page at the same time, and Quick Cache needs to cache (or re-cache) that page as it’s being served, only one of these visitors will trigger the cache writing routine. This is where a Mutex Lock comes in. Only one of these visitors (i.e. instances of Quick Cache) will obtain a Mutex Lock; and thus only one instance of Quick Cache creates (or recreates) the cache file for that page. The other one fails to obtain an exclusive lock; because another cache file is being written from another page view (e.g. from another instance of Quick Cache). Which is good, only one cache file should be written at a time.
This ensures that Quick Cache is only writing one new cache file at a time; and never attempting to write multiple simultaneous cache entries on a single installation. Seeing Mutex Lock notices in Quick Cache comments periodically is normal. Seeing them all the time is not. If you are seeing them all the time, it indicates a problem.
I have checked the /wp-content/cache/ directory. Permission is 755. There was a file called qc-l-mutex.lock. It was completely blank, no text. I deleted the file, it keeps coming back, still blank.
It is normal for this file to keep coming back, and it is normal for this file to be 0 kbs.
What if this file does NOT exist at all?
/wp-content/cache/qc-l-mutex.lock
That would indicate that caching is either not enabled on your installation, or that you’ve selected the Semaphore method for your Mutex Locks (see: Quick Cache Options -> Mutex File Locking). With the Semaphore method (if that’s possible on your server), Quick Cache maintains a lock through a Semaphore on the server, and this lock file is not necessary. See: http://php.net/manual/en/function.sem-get.php
The Semaphore method is recommended for extremely high traffic sites (if possible). If you configure Quick Cache to use the Semaphore method, but this file is created automatically by Quick Cache: /wp-content/cache/qc-l-mutex.lock, it means the Semaphore method is not possible in your current hosting platform; so Quick Cache is reverting to the FLOCK method automatically. See: http://php.net/manual/en/function.flock.php
|
|
|
Thanks for the heads up on this thread :-)
I’ll see what we can do about this in a future release. For now if you’d like to accomplish this in the existing release; please use CSS in the customizable footer.
<style type="text/css">
html { background: url('/wp-content/uploads/bg.jpg') no-repeat top center !important; }
</style>
See: Dashboard -› s2Member® -› General Options -› Login Registration Design
|
|
|
Thanks for your patience.
I too was able to reproduce this issue. It’s not always been the case, but it appears that AWeber now considers these duplicates; and they will do as I suspected originally; they will simply ignore (or possibly delay) the second confirmation email when two attempts are made simultaneously through email commands.
I contacted AWeber about this, and the following workaround was suggested.
Please see: https://help.aweber.com/entries/21696463-Can-I-Add-Subscribers-to-More-Than-One-List-At-Once-
|
|
|
Thanks for reporting this important issue.
Yes, that is a bug. We’ve had this corrected in the development copy and the fix will be pushed out in the next maintenance release. Coming in the next day or two.
|
|
|
Thanks for your patience.
Your test Network has been setup and configured as an s2Member® Blog Farm. The issue that you described in a previous post does not exist on this installation, so please review the example configuration and let us know if problems persist; or if there are other questions/concern. Thanks!
|
|
|
When you say create a test – do I need to activate multisite and everything on it or just the wp install?
Yes, just a plain WP installation is fine. We can activate Networking for you :-)
I’ve done exactly what you said above. I create my user, and go to /wp-signup.php but it keeps saying “registration disabled” even though I’m logged in a a user.
OK. I just received a Dashboard login to your test site; so I’m going to set this up for you there. Let’s come back to this after you’ve seen this on the test installation. If this is still a problem then, I will be happy to investigate the issue on your existing Network.
Details received. Thank you!
Setting up an example installation now.
|
|
|
I would try switching to a default theme next then. This issue does not exist in a default WP installation. I can confirm that Quick Cache is compatible and tested today against WordPress® v3.5, v3.5.1 and v3.6-alpha. Please let me know what you find out!
|
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 
