I ended up renaming the plugin folder, logging in to admin, going to the plugings, clicking on Delete All In One, renaming the plugin folder back, and click Yes Delete Files a couple of times. Then I used WDBSpringClean to remove the tables from the database. Then I edited the .htaccess file and removed all the AIO entries from the #BEGIN ALL IN ONE to the #END ALL IN ONE.
After doing all of that, if I try to reinstall AIO, I end up getting the same issue. Unable to access the Admin for the site and either get file not found or “Please log in to access the WordPress admin area.”
I already had the Admin login set to use a slug
I’m not sure what you mean by this? If you are already using another plugin which does something similar then I advise that you leave this feature disabled.
This feature will prevent you from going directly to the wp-admin and wp-login.php pages because it is designed to hide the login page so nobody can try to hack their way in.
When you enable it, you can only access your WordPress login page by using your new URL which was given to you when you saved this feature.
ps: after renaming the plugin folder to get back in, there was no need to remove the plugin’s tables – all you need to do is rename the plugin folder back to original name and then activate the plugin and go to the rename login page settings and disable and save that feature.
“I already had the Admin login set to use a slug”
Sorry, wrong choice of words.
I already had the option enabled to replace using
mysite.com/wp-admin
to
mysite.com/?mychars
to be able to login to the admin of the site.
I already had the option enabled..
Are you referring to the setting in this plugin or another one?
I believe that the new Brute Force Rename Login Page conflicts with the Firewall Brute Force Prevention. Having both of these options enabled prevents me from being able to actually being able to reach a login page that I can use, but instead either directs me to the home page, page not found, or “Please log in to access the WordPress admin area.”
I had the Firewall Brute Force Prevention enabled and it was working. After upgrading to v3.3, I enabled the Brute Force Rename Login Page, and then when I tried to login a few days later, I was not able to do so.
For the Firewall Brute Force Prevention, I had that set to (for example)
ab01 or mysite.com/?ab01
Then when I enabled the Brute Force Rename Login Page, I set that to
abc01 or mysite.com?abc01
I believe that the new Brute Force Rename Login Page conflicts with the Firewall Brute Force Prevention
Not exactly but I think the behaviour deserves an explanation.
If you have both the cookie based brute feature AND the rename login page feature active then you will have to get past TWO security barriers in order to get to the login page.
You will see the following behaviour:
1) First to get the cookie in your browser you will need to type in your special cookie based URL with the secret word, ie,
yoursite.com/?yoursecretword=1
This will get you past the first security barrier.
2) After doing the above, you will be redirected and the “rename login page” feature will show you a warning message:
“Please log in to access the WordPress admin area”
3) After seeing the above message, you will then need to enter the special URL you set when saving the “rename login page” feature.
This will then get you past the second security barrier and you will be taken to the login page.
In a future plugin release we will modify the behaviour slightly so that when both brute force features are simultaneously active it is more intuitive and user-friendly by displaying a special message to the user.
3) After seeing the above message, you will then need to enter the special URL you set when saving the “rename login page” feature.
This will then get you past the second security barrier and you will be taken to the login page.
For me, this is not happening. I am ending up at the homepage of the site.
How can I remove all of this behavior and reinstall AIO? Apparently uninstalling AIO, removing the tables from the database, and reinstalling AIO from the store does not reset things back to normal as if AIO had never been installed. Are there other settings stored in the database?
To clear all settings from the plugin –
from PHPMyAdmin, go to the WordPress “options” table and delete the following entries:
aio_wp_security_configs
aiowpsec_db_version
In the meantime, if you reinstall this plugin I recommend that you activate only one of either the cookie based or rename login page brute features.
THANK YOU! This is allowing me access again to reinstall the plugin, which I love, and configure it again without making the mistake of enabling both brute force options.
