peter-a

I am using BuddyBoss and having a similar issue with email notifications. I am seeing this text in emails:

Anna <span class="bp-verified-badge"></span> accepted your invitation to connect.

@romanbon this is almost impossibly difficult. This theme is designed around LiveComposer, but the LiveComposer instructions do not match the theme controls. Creating a gallery requires creating a template, and that is missing.

So basically the option of creating a gallery in this theme is broken.

Thank you @mikejolley —?adding something unique between /shop/ and /%product_cat%/ solved the problem for me, and I was looking everywhere for a solution!!

Thank you @mikejolley —?adding something unique between /shop/ and /%product_cat%/ solved the problem for me, and I was looking everywhere for a solution!!

• This reply was modified 8 years ago by peter-a.

I’m having the same problem

OK, sorry. In any case it turns out this was due to a bit of bad code in my .htaccess file causing some mixed content warnings. Now your plugin is working great.

I’m getting the same error as @reiner030 on WP 4.3.1 even with all other plugins disabled.

Also on the setup page it doesn’t display a QR code, only the code number.

Because of this conflict, I am unable to still use the rename-login feature, and I am now seeing more attempted attacks on my site. Any progress or suggestions?

Unfortunately I need to use some kind of force-http function for my site to function properly —?otherwise Google sends people to https, which breaks some site elements.

Our images are served by nginx, and I see that hotlink protection is handled by an .htaccess rule, so this might be beyond your control.

But it’s strange that most of our images are not affected —?only icons and sprites.

I apologize —?I was mistaken: The problem exists in 3.7.9 as well (I just rolled back to check). I must not have noticed it.

I also tried the 3.7.9.2 update and it still has this issue, so for now I have hotlink protection switched off.

Yes.

@wpsolutions,

Yes, that is correct. We had hotlink protection enabled in the previous version (3.7.9) and we weren’t seeing that issue.

I should mention that I edited the RewriteCond to include secretloginword

OK, I did a quick test of Cookie Based Brute force prevention.

I observed the results in Safari, because Safari appears to show redirect activity more clearly than other browsers. (Even so, I had to make a screen movie and watch it in slow motion to catch all the changes!)

My .htaccess rule not active:

When entering https://mydomain.com/?secretloginword=1
it redirects to https://mydomain.com/wp-admin
then to https://mydomain.com/wp-admin/
then to https://mydomain.com/wp-admin/
and finally to https://mydomain.com/wp-login.php?redirect_to=https%3A%2F%2Fmydomain.com%2Fwp-admin%2F&reauth=1

With my .htaccess rule active:

it redirects to https://mydomain.com/?secretloginword=1
then to https://mydomain.com/wp-admin
then to https://mydomain.com/wp-admin
then to https://mydomain.com/wp-admin/
then to https://mydomain.com/wp-admin/
and finally to https://mydomain.com/wp-login.php?redirect_to=https%3A%2F%2Fmydomain.com%2Fwp-admin%2F&reauth=1

I don’t see any of that kind of redirecting happen if I use the hidden login URL (unless I type in https://mydomain.com/mysecretloginurl …in which case it is redirected to https://mydomain.com/mysecretloginurl).

By the way, my hosting provider requires

RewriteCond %{HTTP:X-Forwarded-SSL} =on

but on most hosts it would be

RewriteCond %{HTTPS} =on