Ingrid Moyle

Thank you – perfect!

Solved – re-ran the Soliloquy update this morning and it now all works.

Having the same issue with a new client site.

Running SEO version 1.5.4.2
Soliloquy version 1.5.7.1
Wordpress 3.9.1
Genesis framework

When SEO plugin is activated, then the javascript interferes with uploading images for the slider.

I have the same configuration running on existing sites, but they have been around for a while and had updates applied. There is no conflict with those sites – only for the new install site.

Any suggestions?

Thanks

Ingrid

I have exactly the same issue – running a standard 2012 theme. All my other sites updated with no hassles.

OK – no worries. Thanks!

I used to use iThemes security, and then with the changeover it was just not delivering a stable solution. I changed to the paid version of Wordfence and have never looked back.

Yes … you need solid backups before changing anything.

Changeover notes – I found Better WP Security/iThemes had made changes to my htaccess files and a few other things that were not removed on uninstalling the old plugin, and I needed to go in and manually delete their traces. (There’s quite a few Google articles and a few forum posts out there on how to manually remove all traces). Hopefully iThemes have improved in removing all traces of their plugins over recent weeks.

I also had caching traces left behind from other caching plugins that interferred with Falcon. Once I ferreted them out, Falcon has been brilliant.

Bits that are a major improvement – if caching is not an issue for you, geoblocking is great if you are getting hammered from particular geographic locations. I also am a massive fan of the latest changes to autoblock on particular names being entered admin, administration etc. This was superb over the weekend for my sites.

Love the username block! Thanks for adding that feature.

Finally gave up and uninstalled it from across my sites and all my client’s sites (after manually having to delete code from htaccess files that were not removed after the uninstall).

I put in Wordfence. Smooth install, no buggy code, and the paid option already has working 2 factor identification & geoblocking. Thanks for whoever in these threads put me onto it – a much better option.

Given the increased vulnerability across the web at the moment, the risk of buggy code was too great.

Hi rwnfrnnd – yes I did all the usual configurations including grant access to write to .htaccess. I am either rolling back yet again to version 3.6 that continues to work correctly or working through how to fully uninstall (not a simple one-click uninstall process unfortunately) and putting in other solutions. I was a rabid supporter of this plug-in (and happily donated for its support)- not any more.

Same issue here – Unable to write to your .htaccess or nginx.conf file. If the problem persists contact support.

I tried Wombat’s method but on reinstalling the plugin I noticed that the .htaccess file didn’t show ANY Better WP Security code, although the plugin registered as being active. And the error message remained, so I reinstalled my backup htaccess file just to have something working on the site.

It seems like Better WP is not writing at all to htaccess with the latest update, as no ban ips have also been added to my htaccess files since the changeover – even through the dashboard neatly shows the thousand added in ip addresses that have been blocked in the past week.

I have checked permissions, and all are as per normal – 644 for htaccess.

Solved the mystery of the redirect on exit. There were some extra lines of code in the .htaccess file that somehow were not removed during the plug-in deletion & updates.

Took all this out and it all works beautifully. <secret code string> is the long list of numbers/letters were created in an early version of Better WP Security when choosing to hide the backend.

RewriteRule ^login/?$ /wp-login.php?<secret code string> [R,L]

RewriteCond %{HTTP_COOKIE} !^.*wordpress_logged_in_.*$
RewriteRule ^admin/?$ /wp-login.php? <secret code string>&redirect_to=/wp-admin/ [R,L]

RewriteRule ^admin/?$ /wp-admin/?<secret code string> [R,L]

RewriteRule ^register/?$ /wp-login.php?<secret code string> &action=register [R,L]

RewriteCond %{SCRIPT_FILENAME} !^(.*)admin-ajax\.php
RewriteCond %{HTTP_REFERER} !^(.*)com.au/wp-admin
RewriteCond %{HTTP_REFERER} !^(.*)com.au/wp-login\.php
RewriteCond %{HTTP_REFERER} !^(.*)com.au/login
RewriteCond %{HTTP_REFERER} !^(.*)com.au/admin
RewriteCond %{HTTP_REFERER} !^(.*)com.au/register
RewriteCond %{QUERY_STRING} !^ <secret code string>
RewriteCond %{QUERY_STRING} !^action=logout
RewriteCond %{QUERY_STRING} !^action=rp
RewriteCond %{QUERY_STRING} !^action=register
RewriteCond %{QUERY_STRING} !^action=postpass
RewriteCond %{HTTP_COOKIE} !^.*wordpress_logged_in_.*$
RewriteRule ^.*wp-admin/?|^.*wp-login\.php /not_found [R,L]

RewriteCond %{QUERY_STRING} ^loggedout=true
RewriteRule ^.*$ /wp-login.php? <secret code string> [R,L

Thanks Viktor – your instructions were brilliant. I followed them step by step and it solved 99% of the hassle.

My only addition was before I edited the database, I went into my site after renaming the better-wp-security plug-in and then deleted the plugin through the dashboard. I then edited the database following your steps; logged in and did a clean reinstall and reconfiguration. Tricky but it all seems to work now (woohoo!)

The only minor quirk is when I log out of that site I get taken to the old hidden backend page which triggers a 404 error. There has to be another itsec code somewhere in the database to do with logging off the site. But if that is so minor I can live with it!

Same issue here – one site was not a problem, the next one I encountered this error. I have temporarily renamed the plugin folder now via FTP so I can access the site.

Hang in there ithemes! It will be worth it once you get through the teething problems.