Thanks for reporting these important issues.First is the “Internet Explorer blocked this website from displaying content with security certificate errors”. This is annoying and presents a problem for users, but even worse:
When you set the Custom Field ( s2member_force_ssl = yes ), s2Member will force all embedded media to the https protocol to ensure these errors do not occur. However, depending on your theme, and other plugins that you're running, you could still have the type of errors you're seeing. This happens whenever some of your embedded media is stored on servers that do not support the https protocol. Or in your case, when one of the servers contains an invalid SSL certificate. Upon visiting your site in Firefox, I find this server does not have a valid SSL certificate, and this is why you're seeing this reported in Internet Explorer.
https://cdn.jquerytools.org/1.1.2/full/ ... ?ver=1.3.2Taken out of context. Here is the code snippet in your site's source code:
- Code: Select all
<script type='text/javascript' src='https://cdn.jquerytools.org/1.1.2/full/jquery.tools.min.js?ver=1.3.2'></script>
IE does not keep users logged in on the SSL pages. That makes it impossible for my free subscribers to upgrade to paid membership via IE.
I'm sorry, I've been unable to reproduce this under normal circumstances. The only case in which I'm aware of this possibility, is when a User/Member logs in through the SSL-enabled version of your site. So for instance, if you have a login form that points to `
https://yoursite/wp-login.php` instead of `
http://yoursite/wp-login.php`, WordPress will automatically force the authentication cookies to be valid ONLY on the SSL-enabled version of your site.
This is a built-in WP security measure.However, this only happens when a User/Member logs in on the SSL variation of your site, and does NOT happen when a Customer logs in on the non-SSL variation. In other words, if a User/Member logs in on the non-SSL variation of your site
( which is the most typical/recommended way ), they will be recognized on both the SSL and non-SSL variations. So, the way to work around this potential issue, is to make sure all of your login forms are using the non-SSL variation; or to make your entire site accessible via SSL instead of a selected set of pages. Since SSL encryption consumes a larger amount of server resources, and is usually required only for checkout forms, I recommend pointing all of your login forms to the non-SSL variation of your site. For example: `
http://yoursite/wp-login.php`.
Another workaround, is to tell WordPress® to always recognize Users/Members on both variations of your site; regardless of whether they logged in on the SSL or non-SSL variations. This can be accomplished by Filtering the built-in WordPress handling of this scenario.
Create this directory and file:/wp-content/mu-plugins/wp-hacks.php
Inside the file, do something like this:- Code: Select all
<?php
add_filter("secure_auth_cookie", "__return_false");
add_filter("secure_logged_in_cookie", "__return_false");
?>
If you continue to have trouble with this, please
email us an administrative Dashboard login and we'll test the functionality of your login form; just in case we've completely missed something in your bug report.
Posted: March 22nd, 2011, 4:51 pm