North2Doug

I second Krzysztof Dryja’s comment however I only discovered this on one of my sites which are on separate hosting accounts within the same company.

I had tried disabling and enabling the plugin and resaving individual modules without success.

I did disable “Allow iThemes Security to write to wp-config.php and .htaccess.”, saving settings and enabling that option again as Krzysztof suggested and that “fixed” the .htaccess file but not wp-config.php. If I were to guess it would be the act of actually changing one setting and saving it that “unsticks” the plugin. It could also be combined with a caching conflict as I had WP-SUPER CACHE enabled.

Problem is not resolved for me.

WordPress 3.9.2 – WordPress SEO 1.5.5.1 through to 1.5.5.3 will not allow custom entries on page or post to be saved. Example – change SEO Title or Meta Description and click UPDATE. It will not save.

Rolled back to 1.5.5 and functionality returns.

Did not experience any fatal error messages. Was working in Chrome Version 36.0.1985.125 m. Same results in IE and FF.

Problem is not resolved for me.

WordPress 3.9.2 – WordPress SEO 1.5.5.1 through to 1.5.5.3 will not allow custom entries on page or post to be saved. Example – change SEO Title or Meta Description and click UPDATE. It will not save.

Rolled back to 1.5.5 and functionality returns.

Did not experience any fatal error messages. Was working in Chrome Version 36.0.1985.125 m.

pseudogeek

Thank you for the tip. With regret this plugin is not working as advertised and support has been limited to one standardized suggestion.

The plugin will work if run manually. The Google Drive paid option will work if run manually.

The backup will not complete successfully on an automatic schedule and I suspect it is a conflict between the litespeed web server code and BackupWordPress. It will not resolve despite numerous advanced troubleshooting paths and hacks on my behalf.

I am disappointed that the paid support option 100% abandoned me despite being supplied with extensive information.

My advice is to forget this plugin if having trouble making it work. The numerous amount of non-replied support comments is a good indication of the state of the plugin. Too bad as it was a good plugin, will work if manually run but many, including myself, are having lack of success running it as an automatic function despite weeks if not a couple of months of trying.

@jnicol

Thank you. A very big thank you.

WP 3.9
BackUpWordPress 2.6
Upload to Google Drive ver 1.0.5

won’t complete
– Scheduled backups do not complete. Only spinning wheel for 24+
hours (500 kb database file and 42 mb of web files).
– Manual RUN NOW of weekly schedule (42 mb of files+database and files) will not complete. Only spinning wheel for 24+ hours.

will complete
– Manual RUN NOW of database only (daily backup) will run and complete to server and google drive.
– Manual RUN NOW of files only will run and complete to server and google drive.

Have tried excluding files and Uninstalling and reinstalling plugins.

I empathize. The words I hate to hear most “It worked for me”

I just reset a site on a subdomain using my steps above. One further step was that I made sure the .htaccess file was 100% default using the code in following link.

https://codex.www.ads-software.com/htaccess

I did search PHPMyAdmin for the custom login URL that I used via another plugin but in this site it appeared that the rewrite rule was still left in the .htaccess file. Sometimes deactivating a plugin and deleting doesn’t really delete it all.

Results on a site on a subdomain

The hide backend on the site on a subdomain appears to be functioning normally.

Couple of things of note:

– if you change the HIDE BACKEND slug I did not use a trailing slash. I thought I did and when I typed the login URL with the trailing slash….dumb mistake…I thought things were still broken but just mistyped. The ID-Ten-T error.

– if a site still gave me problems I did the above steps again. Perhaps I missed something….perhaps it had to be “convinced”. The second time around worked.

Ever since 4.0.2 the hide backend feature did not work. Errors, blank login page, 403 and 404 errors on logging out if the plugin, but not hide backend, was active.

4.0.23 with the steps mentioned in both my posts appears to have worked…for me. YMMV.

I hope this helps.

WP 3.8.3
iThemes 4.0.23
Shared webhost – successful on two different shared webhosts.

I tested 4.0.23 and was successful. BUT here is what I had to do.

As always…backup before changes and proceed at your own risk.

– ftp to site
– deleted wp-better-security folder (completely instead of renaming)
– deleted ithemes security folder from /uploads
– edited .htacess file to default settings. I removed everything between and including #BEGIN ithemes and #END ithemes
– Logged into PHPMyAdmin and deleted tables with itsec
– While in PHPMyAdmin I loaded options table, sorted A-Z and deleted entries with itsec

Full instructions are here.

https://www.ads-software.com/support/topic/how-to-reset-ithemes-security-plugin-to-fix-issues?replies=76

Now here is what threw me for the longest time. The HIDE LOGIN option of Ithemes was causing errors from ver 4.0.2 onwards. Everything else worked. I got around this by using a custom admin login plugin. Problem was that deleting it didn’t actually remove the custom login URL from the database. I had to hunt for that and delete that entry from the database through PHPMyAdmin.

So if you are using a custom admin login plugin then make sure it’s completely removed …just not deleted from the plugins.

Once I had done that I tested on my localhost enabling 1 option at a time. Logging out. clearing browser cache and history and logging back in. Checking and re-checking. Yes it took a long time.

Happy to report that on localhost and on my webhost ver 4.0.23 appears to be functioning. The Hide Backend option is working for me. I pretty well enabled everything but SSL group and the RPC setting.

Version 4.0.16 still producing blank login page with hide backend enabled.

The problem persists.
– upgraded from 4.0.2 which is functioning properly and the custom admin login produces a blank/empty webpage.
– Also unsuccessful results uninstalling plugin and deleting itsec tables and then installing clean.
– tried in FF, IE, Safari, Chrome
– tried wp-admin url after initial activation…onscreen message was You do not have sufficient permissions to access this page.
– if disabled it will function normally but, of course, it’s reverted back to sitename/wp-admin URL.

WP 3.8.1
PHP Version: 5.4.24
Multisite: Multisite is not enabled
MySQL Database Version : 5.5.36-cll
MySQL Client Version: 5.5.36

UPDATE: reverted back to 4.0.2 and the hide backend problem resolved. When I logged out of the site the URL read https://www.sitename.com/?loggedout=true

With the 4.0.12 version the You do not have sufficient permissions to access this page. error message appeared.

I can confirm this as well. I upgraded from 4.0.2 to 4.0.12 and hide backend stopped functioning. Unchecking it allowed access via wp-admin url. I deleted plugin and dropped itsec tables from db and removed the ithemes folders from the directory to ensure I was troubleshooting from a clean install.

Re-installed with same settings and same problem. Enabling hide backend resulted in an inaccessible site via the custom URL.

If this occurs FTP into the site and rename the plugin folder putting any character such as old_ in front of the plugin folder. Log back into your site via sitename/wp-admin and rename the wp-better-security folder back to original. Then refresh your admin page and uncheck hide backend. At least you’ll have all the other security functions operating…just hide backend seems to be buggy in, as I can only guess….somewhere between 4.0.5 and 4.0.12.

I hope this helps.

Update: reverted back to 4.0.2 and the hide backend problem resolved. When I logged out of the site the URL read https://www.sitename.com/?loggedout=true. With the 4.0.12 revision the insufficient privileges error message appeared.

This may help or get you one step closer. The upgrades worked on live sites however the localhost developed problems. What worked for me was:

1. FTP to themename\plugins (if using wp 3.8.1) and rename the better-wp-security folder placing OLD at front of folder name.

2. I was then able to login using the wp-admin path

3. Once logged in to the site you’ll see that the iThemes security plugin is deactivated.

4. Rename the better-wp-security folder to original name – removing the OLD

5. Re-activate the plugin and it should work now. Should…at least it did for me.

Things I noticed before the problems. With 3.x version of better-wp-security there was the ability to rename the 3 login paths. With 4.x version this was reduced to 1 and it displayed a login path that I had set for the author but not the admin. I updated that path name and things started to go wrong from there.

I also had the custom-login plugin active so my login path, custom or wp-admin, only showed a blank webpage.

I had do rename the custom-login plugin to OLD and reactivate it after testing the previous 5 steps.

Hope this helps.

mypp –

I upgraded 3.65 to 4.02 on another site which is on a different host altogether. The .htaccess file wrote properly. The only guess that I have is

1) Before upgrading set the .htaccess file permissions to disable (unticked) in the 3.x Better WP Security > Save and then upgrade.

2) it could be how the host has the server set up but that’s a long shot guess.

I’m puzzled why it would work on one host but not the other. I am still encountering the away mode and Change User Id 1 issues but those are other threads.

FYI: confirmed on 2 different installs on 2 different hosts. Only AM times appear to take. PM times reset and clear the away mode.

This may provide a clue to an answer for you.

https://www.ads-software.com/support/topic/settings-arent-saving-to-htaccess-after-update-to-402