Support Forum
Support Forum
Offline
I have two issues related to editing various parts of user accounts.. These worked initially, but after an update to S:P a few versions ago, they stopped working. We've just updated once again to the latest 5.5.8 (on WP 4.2.2), and that has not fixed the issues, so I am posting here in the hopes of getting this fixed. We have not edited any of the S:P files.
1. When you click the woman with pink shirt icon under "Actions" in Users -> Member Information (hover text "view member profile"), the popup does not show any items in it: https://db.tt/l10zUAdm
2. When trying to add/remove members from groups in User Groups -> Manage User Groups, after clicking the respective blue action button, a top notification comes up that confirms the action (eg. "Users Deleted/Moved") which is then replaced by another that says "Please Wait - Processing". Upon refreshing, the action was not completed, and everything remains the same as it was.
3. There are other similar issues in other portions of the admin panel where user-related actions will not work, either hanging on "Please Wait - Processing", things not showing at all, or saying they have completed but in actuality they have not. I don't have examples beyond #1 and #2 on hand because it's been a while since I've tried other administrative actions, but could find them if necessary.
Thanks in advance.
Offline
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/docum.....-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.
 |
YELLOW
SWORDFISH
|
Offline
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_a.....atchNum=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.
Offline
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.
|
YELLOW
SWORDFISH
|
Offline
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...
Visit Cruise Talk Central and Mr Papa's World
Offline
@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?
Visit Cruise Talk Central and Mr Papa's World
Offline
Hi Mr. Papa,
You can read about the FORCE_SSL_ADMIN functionality here: https://codex.wordpress.org/Ad.....n_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).
Offline
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..
Visit Cruise Talk Central and Mr Papa's World
Offline
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...
Visit Cruise Talk Central and Mr Papa's World
Offline
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?
All RSS1 Guest(s)