The parameter s2member_force_ssl = yes is not intended to be used on a page where the site is already set to https.
It is intended to be used where the site is generally http, but where it’s important that the specific page be served over https.
Since your site is evidently set to https, you should not use this parameter at all.
I do not understand – What do you mean my site is set to https? I have an SSL certificate, but isn’t this just a basic requirement of using the parameter s2member_force_ssl = yes?
Any further clarification would be greatly appreciated as I’m having a difficult time understanding this.
OK. What do the entries say in Settings -> General in the boxes marked WordPress Address (URL) and Site Address (URL)?
By default, WordPress actually creates two sites: one beginning http and one beginning https. Normally, of course, you’d only access https with an SSL certificate because otherwise you’d get security warnings.
If you change your two settings to begin https, you make the http version inaccessible. Then you don’t need the s2member_force_ssl = yes parameter (and shouldn’t use it).
Because you were getting an error message, that’s what I thought you had done. But it seems you haven’t, so are using the parameter appropriately. Equally, though (using Firefox and Chrome) I am not seeing any mixed content warnings on your pages.
Thank you again for your response. For anyone else with this issue, I need to make two points before concluding:
First: To avoid confusion, I want to provide updated links here that drop the ‘www’ that was causing another unrelated error.
FORCE_SSL: https://statsdoesntsuck.com/adms-2320/checkout/copy-of-adms-2320-full-course-bundle/?s2-ssl=yes
No FORCE_SSL: https://statsdoesntsuck.com/adms-2320/checkout/no-s2member_force_ssl/
Second: You are correct that neither of the links shows a mixed content error in Chrome or Firefox, HOWEVER – the FORCE_SSL link (https://statsdoesntsuck.com/adms-2320/checkout/copy-of-adms-2320-full-course-bundle/?s2-ssl=yes) does show me a mixed content error when I am logged in as administrator…BUT the No FORCE_SSL link (https://statsdoesntsuck.com/adms-2320/checkout/no-s2member_force_ssl/) when viewed by someone who is not logged in will keep that user on the https version of my site once they exit that particular page. This is a bigger problem and leads to many more mixed content errors.
My Conclusion: I figure the best plan is to use the custom field: s2member_force_ssl = yes for my pages requiring SSL and do all of my final checks logged out of my site.
By definition, registrants will always be logged out, so you should ALWAYS test this when logged out.
I suspect you have an image (maybe your own avatar?) that loads when you are logged in, and that’s being served from http (because that’s what your site is set to), and that’s what causes mixed content warnings. The only remedy for that is to set your site to be wholly https.
As for a user being kept on https and seeing mixed content warnings after registration, you need to go to s2Member -> General Options -> Login Welcome Page and set Always Redirect non-Administrative Users (after login) using HTTP to Yes. Then they will be redirected back to http and so won’t see the warnings. (Or, alternatively, you can just set the whole site to https.)
Ok – Thanks for the in-depth answer. I will mark this as resolved, but I do have a follow-up question.
Are there drawbacks to setting the whole site as https? Doesn’t this slow the site down with everything needing to be encrypted?
You’re welcome.
Are there drawbacks to setting the whole site as https? Doesn’t this slow the site down with everything needing to be encrypted?
It’s true that the encryption before serving and subsequent decryption in the user’s browser will add some time to the experience (though how much will vary according to host, route, and user’s equipment).
However, this may often be more than offset by another factor. If a page is served over http, it will often be “inspected” (that’s probably not the correct term) at various points along its journey to the user’s browser. Each such inspection adds time. Unless the NSA (or similar) is involved, there’s no point trying to inspect an encrypted page, though, so pages served over https don’t generally get interrupted like this.
My own experience has been that my sites run at the same speed or slightly faster over https than they previously did over http.
