There is nothing inherently wrong of course or all users would have the same problem which clearly they do not. The right question for me to ask is – what else changed? But if you have waited a couple of releases of SP to ask the question then you probably will not remember. But ideally you should look at any changes to your WordPress theme or updated/additional WordPress plugins.

You most probably – almost certainly – have a JavaScript conflict – your WP theme or another plugin – which needs to be fixed. This codex article explains what this means and what to look for:

https://simple-press.com/documentation/codex/faq/troubleshooting/what-is-this-jquery-conflict/

A quick way of finding out is by using the browsers web console and have it set to show errors. Then by running an action that fails you will see what gets reported. We would be happy to do that for you but would need a link to the forum page and, of course, permission to try at least one of the failing actions.

Using the Console, the following appears on the Usergroups screen:

Blocked loading mixed active content “http://site.com/index.php?sp_ahah=memberships&action=del&sfnonce=xxxxxx&target=sfmsgspot&totalNum=1&forum-adminform_memberdel=c539beef86&usergroupid=5&usergroup_id=-1&list-filterdmid5=&dmid%5B%5D=13&startNum=0&batchNum=50

And the following on the User profile screen (admin panel)

Blocked loading mixed active content “http://site.com/index.php?sp_ahah=profile&sfnonce=xxxxxx&action=popup&user=13”

We force HTTPS for the admin panel (both with the wp-config.php FORCE_SSL_ADMIN, and this plugin – although the latter only acts as a failsafe for the wp-config.php file based on how we’ve configured it), whereas SP seems to be forcing http, causing this not to load.

Disabling Firefox’s mixed content protection (which itself is not a suitable fix, even if it worked) then results in the following error.

Cross-Origin Request Blocked: The Same Origin Policy disallows reading the remote resource at http://site.com/index.php?sp_ahah=memberships&action=del&sfnonce=xxxxxx&target=sfmsgspot&totalNum=1&forum-adminform_memberdel=c539beef86&usergroupid=5&usergroup_id=-1&list-filterdmid5=&dmid%5B%5D=13&startNum=0&batchNum=50. (Reason: CORS header ‘Access-Control-Allow-Origin’ missing).

Which means the only solution appears to be either disabling HTTPS for the admin panel, or installing a third party browser plugin to disable CORS protection/disabling Chrome’s web security functionality across the board, on top of disabling Firefox (or Chrome’s) mixed content protection.

I’d call this a bug – SP should respect the protocol used.

I am sure that @mr-papa can shed more light on this but I will say that SP DOES indeed respect the protocol being used – as reported to us by WordPress. Do not forget that Simple:Press is a WordPress plugin. It does not make arbitrary decisions but relies on core WP API functions and if the WP API informs us that the protocol being used is SSL then SP will use https URLs.

yes, we have many users that use SSL and simple press (though the majority do it for full site)…  there has been an issue or two here and there that popped but its been pretty smooth for a while now…  In fact, ran through a whole battery of tests just a version or two ago related to some auto updates that were mixing content and resolved…

interestingly, the couple of messages you show there are links from the front end…. so will have to look around…

out of curiosity, what is the purpose of using SSL only on the admin?  I know wp uses it and its valid, so not questioning that part of it, but it loses most effects of SSL for site by only securing the admin – especially if you already have the certificate…

@smartrecovery can you try a quick test for me?  my localhost test site is whacked for ssl so need a bit of confirmation…

in sp-control.php, around line 37 you should see:

$home = trailingslashit(site_url());
define('SFHOMEURL', $home);

can you try changing it to:

if (is_admin()) {
    $home = trailingslashit(site_url('', 'admin'));
} else {
    $home = trailingslashit(site_url());
}
define('SFHOMEURL', $home);

and see if that helps your issue?

Hi Mr. Papa,

You can read about the FORCE_SSL_ADMIN functionality here: https://codex.wordpress.org/Administration_Over_SSL

It not only makes the admin area SSL, but also all logins, and is standard WP functionality. Making the admin panel and WP logins go through SSL adds a layer of protection so that sensitive details do not go out in plaintext (of which there are potentially many within the various uses of the admin panel). I don’t think that making the admin panel secured via SSL makes the site any less secure or “loses most effects”, as there is still sensitive information that gets passed behind the scenes. Though it is nice to have SSL everywhere, that presents its own difficulties (mostly with plugins misbehaving) and so although is on the roadmap for us, we have opted for protecting logins and the admin panel as a temporary compromise.

After applying the code, the exact same mixed content errors came up. If you need an SSL certificate for testing, you can get certificates for $9.99 per year (PositiveSSL) from n-@-m-e-c-h-e-@-p (don’t want to seem like I’m advertising – they just have the best deals I’ve found).

on localhost, I can certify my own…  and have…  just always changing configurations – too many possible combos out there we have to test…  the certificate is not the problem, but the server config… just have to find the time to put it back…

yes, know all about that page… but its still only partial protection…  most ‘experts’ say its minimal gain… of course, take experts with a grain of salt… 😉

hmm… surprised you got the same answers – expect the couple I looked at to change… will have to dig further… unfortunately, might be next weekend (on business travel this coming week) before I can set ssl back up locally to test..

managed to get ssl set up today locally…

and unfortunately, cannot duplicate your mixed content issue at all… that is, with no changes, ssl is working fine in the admin and for logins…   the members profile in users admin panel and others seem to be just fine…

so something else must be at play here…  Can you try your tests again with that extra ssl plugin deactivated?  and see if similar response…  when trying, please revert the sp-control.php back to the original form…

Hi,

I’ve tracked down the issue to a conflict with the following setting in WordPress HTTPS: https://db.tt/FhXMMD3k

Unfortunately, this is a critical feature. Basically, by default, WordPress will force the protocol in use on all dynamically linked URLs (eg. all navigation elements). The point of the WordPress HTTPS plugin in the first place is to convert insecure elements to secure ones, because accessing pages through HTTPS normally will cause all kinds of warnings due to resources in WP not being loaded in HTTPS dynamically. As a result, since we secure our login page but not much more than that on the front-end, without this feature, people who pass through the login page or one of the few other pages that use SSL, will begin to navigate the entire site via SSL. While we can apply rules in .htaccess to mitigate this, by default WP will still show all links as HTTPS once they have gotten onto a single HTTPS page, and having every single link on the site as a 301 is not acceptable.

Any ideas?

not sure how one can have it both ways…  either you have the front end in ssl and ‘tell’ plugins that – or you dont…  WordPress tells us the protocol in play… we can’t possible know about another potential plugin (without explicit coding) and what they are doing… 

basically, if I follow this, we are using the wp schema for the pages as per wp api, but your https plugin is redirecting our https urls in the admin back to http because of the ‘appearance’ of them being front end pages not covered by the force_ssl option…  but we are in the admin and governed by force_ssl, so it would seem it should not dork with any urls in the admin as they are by definition force_ssl…

Afraid I have no idea how they are doing that, but if they allow you to hook into the process (ala like wp or other plugins do), seems like you could add your own check for is_admin() and bypass the force_ssl if you are in the wp admin…

Looks like you’re right, it is because Simple:Press uses index.php, which is a frontend page. I presume there are no plans to change the functions to use another file, so we will likely have to find a workaround on our side. Thanks again, for all the help and quick response time.

I will need to leave Steve to answer that one but I am not sure I see any reasonable alternative to index.php…

currently, no plans to change using the primary WordPress entry point for those ajax type activities…

but as I mentioned, think the best answer might be in the https plugin…  see if it has standard wp hooks that can be used to adjust how it works (like core, simple press and many other plugins)…  do you have a link to that plugin?  we might be able to see if it provides those kind of usability features…

Yes: https://wordpress.org/plugins/wordpress-https/

It hasn’t been updated in a while but still works properly (except the Simple:Press issue).