IN
http://wordpress.org/support/topic/plugin-better-wp-security-away-mode-uses-wrong-time?replies=3
Sorry, im a bit of an ass i guess...
Was a bit confused with PM and AM
*shame*
Bit51
Member
Posted 1 month ago #
Glad you're back in. If you need to delete manually you'll have to delete the field with bit51_bwps from the options table in your database (note these are all the plugin options which will then require reconfiguration).
I similarly mixed up away-mode and on-mode and entered a wrong time.
I could not even correct this issue, I was directly logged out from the WP admin, after entering a wrong away time frame.
Then I deleted the "bit51_bwps" row from the options inside php admin,as you suggested. But still I am redirected, when I want to log in.
PLEASE HELP !
http://wordpress.org/extend/plugins/better-wp-security/
it seems to be a caching issue.
After a certain time I can login again.
But from now I will test Better WP Security on my mirror server first, too dangerous this plugin.
One issue already found:
The Wass Up plugin did not allow for the table renaming.
Interesting Peter. What caching are you using?
Total W3 Cache.
P.S: WassUp might be another issue. Still I maintained table names wp_wassup...
Are the tables written in any special way (different engine, encoding, etc)? I've successfully changed the names of tables created by dozens of plugins without issue. The plugin simply loops through each table in the database looking for the prefix.
One more question for away mode... Is your server set to UTC or local?
It was UTC, then Better WP Sec told me to look on the time and I realized that I was on UTC. Then I changed to local (UTC+2)
Thanks Peter, I've reworked the function a bit, particularly to properly handle caching and a little better login for daily lockouts. Can you please see if the dev version at http://downloads.wordpress.org/plugin/better-wp-security.zip is working for you?
Is the version 3.4.1. ? The one display in plugins ?
No, this is the "Development Version" under the "Development" tab. I usually ask folks to test the fix I've added for their issue (where possible) before officially releasing it.
Where is the development tab ?
I have only Dashboard UserAwayBanDirBackupPrefixHideDetectLoginSSLTweaksLogs
I can upload the zip file here.
Sorry, it's under the developers tab on WordPress.org. (http://wordpress.org/extend/plugins/better-wp-security/developers/) if you can't update that's OK, it's always worth a try...
I deleted the old one and uploaded the zip. Do I need to deactivate and reactivate ?
Nope. Everything should function normally.
There were a few issues where awaymode could get stuck thanks to caching. I do believe those should be fixed and it should be using slightly better logic to determine the time a redirect.
Do you set wp-config.php to 444 permission ?
W3 Total Cache is telling me:
Plugin could not be activated because it triggered a fatal error.
.../FilesAug04/wp-config.php could not be written, please edit config and add:
define('WP_CACHE', true); before require_once(ABSPATH . 'wp-settings.php');
If you have selected to disable write permissions in "System Tweaks" the plugin will set .htaccess and wp-config.php to 0444
W3 Total Cache does not like it.
Just remove the Tweak ?
Yep. You can just turn it off. If W3TC is already installed it shouldn't complain (I use both). It's only during W3TC configuration that it needs to write to wp-config.php. When I do hit a plugin that does this I turn off the write permission features, configure the other plugin, and turn it back on.
I disabled W3TC after I had the caching issues. Now I cannot reactivate with config access.
But switching the Tweak off, does not change permissions back to 644.
So I do it manually.
Try saving "System Tweaks" one more time. It always changes to 0644 to confirm it can write then changes back to 0444 if the option is selected. If the options are cached however (apc, etc) it may take an extra save to make it work.
Too late. W3T is activated.
OK. Thanks. Working on clearing opcode caches throughout a little better (it can hold up a LOT of settings).
activated. But .htaccess still 444.
So I retry tweak enable disable.
Hmm, I can confirm that it is working for me with the dev version, w3tc, and php 5.4.4. If I set the "Remove write..." option it goes to 444 if I turn it off it goes to 644
I switch on and off this:
Protect Files
Prevent public access to readme.html, readme.txt, wp-config.php, install.php, wp-includes, and .htaccess. These files can give away important information on your site and serve no purpose to the public once WordPress has been successfully installed.
Warning: This feature is known to cause conflicts with some plugins and themes.
We are speaking of the same ?
Ahh. No. In the last section turn off "Remove write permissions from .htaccess and wp-config.php"
I know.. I need to find a way to make this less confusing...
I mixed the two up. One is external read, the other write...
I have checked the box now for Write to WordPress core files. It was unchecked since I changed it before. htaccess still444
