jrivett

I installed the test version before seeing your warning about the Setup Wizard, but it seems to be fine anyway. No issues with missing Dashboard functionality. BPS itself seems fine. I even ran the Setup Wizard but it didn’t seem to do any harm.

Thanks!

I did try running an Mscan, but it just kept looping, calculating the scan time but never really getting anywhere. The log is empty.

Sounds like you’re in the process of figuring out a fix. Can I help in any way? Is there any more information I can provide?

I did see the ‘..’ path, which was why I was asking about /var/www (the directory referred to by ‘..’ in the example I provided).

Well, that certainly explains what I’m seeing.

Unfortunately, I don’t want to stop using open_basedir, and I don’t want to add the site’s parent directory to the open_basedir directive. Why does BPS need access to that directory?

Looking at the errors I’m seeing in the Apache error log (below), it seems clear that unless I disable open_basedir completely, to fix this, I’d have to add ‘/var/www’ to the open_basedir directive. Not something I want to do.

Apache error log example:

PHP Fatal error:  Uncaught exception 'RuntimeException' with message 
'SplFileInfo::isDir(): open_basedir restriction in effect. 
File(/var/www/mysite/..) is not within the allowed path(s): (/var/www/boot13)' 
in /var/www/mysite/wp-content/plugins/bulletproof-security/includes/general-functions.php:891
referer: https://mysite.com/

• This reply was modified 7 years, 6 months ago by jrivett.

One other issue: I’m getting these emails from BPS every five minutes, even though it’s disabled: ‘BPS Alert: The /bulletproof-security/ plugin folder has been renamed or deleted’.

I moved the plugin folder to plugins.disabled. That fixed the problem, but obviously BPS is no longer functioning. I then tried installing BPS from a new download, but the same thing happened. So I disabled it again.

The BPS htaccess files are still in place, so the problem must be in other BPS functionality.

I wasn’t aware of that GMail setting; thanks.

Sadly, it only seems to affect email sent using the GMail web client. When I send email via GMail remotely (eg. from a web store), the setting seems to be ignored.

I’ve switched to a different plugin that allows me to specify REPLY-TO (for free), and it’s working fine.

Thanks for your help.

I just tried it again, and was able to reconnect to Google+. Mystery.

I reverted one of my test sites to an earlier version of Responsive. On checking the theme details, I no longer see the scary warning message. Instead I see this:
—–
Update Available
There is a new version of Responsive available. View version 2.5 details or update now.
—–

So it looks like this problem is resolved at last.

Confirmed: the page linked from the warning message is still down. The address is https://content.cyberchimps.com/responsive-2-migration. What I see is:
Expired Account
The HubSpot account associated with the domain “content.cyberchimps.com” has expired.

I installed 2.1.1 but I guess there’s no way to know whether the broken link and the confusing message are fixed until the next update becomes available.

The link still isn’t fixed. It’s disturbing to be told that there’s a big update, only to find that the link that should explain that doesn’t work.

Please fix the link, or remove the warning, or change the wording of the warning so it makes SOME sense.

While you’re at it, you might want to consider changing the name of Responsive II to distinguish it from Responsive 2.0. It’s currently very confusing.

And just like that, I found a solution. I had recently installed the diagnostic plugin Query Monitor, and although it was disabled, parts of it were still apparently running, because when I deleted the plugin completely, my admin dashboard came back to life. I’m now able to use New User Approve as before.

@stormlux: I just started having this problem as well. In my case I have less than 1000 users, but most of them were denied registration using New User Approve.

Anyway, I tried your solution, but sadly it didn’t seem to make any difference. I guess my next step is to delete all those denied users, but that’s a temporary solution at best.

Please post here if you have any additional information abut this.

Regarding User Agent: thanks for that. At least one WordPress security plugin does indeed (by default) block based on User Agent: BPS.

Regarding method: I believe they wanted to know if WPPSO is performing a GET request, or something else, perhaps a HEAD request.

Meanwhile, I’ve run into a separate problem with WPSSO and I’ve had to disable it for now. I think WPSSO is a terrific plugin, and very much want to use it, but I’ll have to re-evaluate it again later. I’ll post the new issue in a separate thread.

Question from the hosting provider: when WPSSO tries to access the URL in question, what HTTP method and user-agent are used?