Plugin Author
AITpro
(@aitpro)
Is this blog on a different web host?
Did you click the AutoMagic buttons before activating BulletProof Modes?
Is the original .htaccess file a standard default WordPress .htaccess file?
Also additional troubleshooting help and steps can be found here – http://www.ait-pro.com/aitpro-blog/297/bulletproof-security-plugin-support/bulletproof-security-wordpress-plugin-support/
Thanks for the prompt response.
Is this blog on a different web host? – No, same host (HostGator)
Did you click the AutoMagic buttons before activating BulletProof Modes? – Yes
Is the original .htaccess file a standard default WordPress .htaccess file? – It is a BulletProof Security pre version .47.3 htaccess file.
You helped me add Better WP Security custom code to some other sites which worked fine. On this site it crashes when I try the same process.
I will try the updated BPS bullet proof htaccess process without adding the Better WP Security custom code and see if that works and report back here.
Thanks
Plugin Author
AITpro
(@aitpro)
it looks like better wp security is now adding a lot of new .htaccess code and some of that .htaccess code is redundant and very simplified .htaccess coding compared to BPS .htaccess coding – http://pastebin.com/yRdEgqAX.
I have not had a chance to test that plugin yet, but my guess is that the best thing to do would be to just not choose some of the better wp security options since those options are attempting to do what BPS is already doing. BPS does not bother with attempting to block bots so the bot blocking code in better wp security can stay without causing any problems. I should be able to test better wp security today so once i have done that i will post my findings here.
Plugin Author
AITpro
(@aitpro)
Testing is completed and it looks like the only area where there would be a conflict is if you choose and use any of the Server Tweaks in better wp security. BPS already has all these areas covered and in a much more advanced way so there is no need to use any of the better wp security Server Tweaks.
When enabling the Ban features the better wp security plugin is adding this .htaccess code to the beginning of your root htaccess file and this code should be added to the end of your root .htaccess file instead because it is not .htaccess code that needs to be processed first where the Begin WordPress rewriting loop should be processed first before this code and BPS security filters are combined into the WordPress rewrite loop so that they are one and the same thing. So the solution is just to cut the better wp security .htaccess code and then paste it into the BPS Custom Code Bottom text box for your root .htaccess file, save it. Then of course you would need to click the AutoMagic buttons and activate BulletProof Mode for your Root folder again.
When enabling the Hide backend then this htaccess code is grouped together with Ban .htaccess coding and is not tied into the WordPress rewrite loop so it is fine to move this to the end of the root .htaccess file using the method described above. Basically you would be taking the entire better wp security .htaccess coding out of your root .htaccess file and then adding it to the BPS Custom Code Bottom text box, save it. Then of course you would need to click the AutoMagic buttons and activate BulletProof Mode for your Root folder again.
And the same would probably apply to any other better wp security .htaccess coding, BUT if any of that coding is doing rewriting that should be incorporated into the WordPress rewrite loop then some customization’s would have have to be done directly to the root .htaccess file to combine the code instead of using Custom Code. i did not find any coding that needed to tied into the WordPress rewrite loop.
NOTE: better wp security may try to continue to add its htaccess code to the top of the root .htaccess file if you add additional features within that plugin so what you may end up doing is having to repeat the steps above if you add, remove or change settings in better wp security.
NOTE: I did not test with a caching plugin installed, but if the wp better security .htaccess coding is being written to the root .htaccess file before caching .htaccess code this could be a problem for a caching plugin like W3TC for example. And may actually interfere with website load speed. I don’t think it would, but caching code should always come first in an .htaccess file as a standard before any other .htaccess coding.
Thanks so much for going above and beyond the call of duty. Your support is the best.
I tried your suggestions but there is something about this blog that won’t allow these plugins to play nice together. On this blog I will probably have to choose BulletProff Security and give up on adding Better WP Security.
Thanks again
Plugin Author
AITpro
(@aitpro)
Very welcome and thanks for the Kudos. 🙂 Maybe there is another plugin that is involved in the issue. have you tried deactivating all plugins except for BPS and better wp security and also switching to a default WordPress Theme?
Yes. Tried everything except the default theme. I will give that a go early next week and if it works will report back. I wish all support were as wonderful as yours has been. Thanks so much.
Plugin Author
AITpro
(@aitpro)
Hmm yeah switching the theme to a default WP theme is probably not going to make a difference in this case, but you might as well eliminate that as a possibility since you’ve gone this far. 😉
Just a heads up – I looked around and apparently the caching plugin issue i thought might be a problem is actually a problem. I see that a few people have reported that there is a conflict with WP Super Cache and better wp security and it is probably caused by the bwp .htaccess code being added to the top of the .htaccess file instead of being appended to the end of the file. And i assume the same problem would also happen with W3TC.
Interesting. Thanks for that. I stopped using WP Super Cache because it can be absolutely satanic if you have problems with it and uninstall it without doing it a certain way. I switched to WP Quick Cache and did clear the cache but will try clearing the cache again and turning it off as I go through the BPS setup routine. Thanks.
Plugin Author
AITpro
(@aitpro)
I don’t think Quick Cache adds .htaccess code to your .htaccess file and the caching coding is all done with php coding so there would not be any conflicts or problems with bwp.
Update: I had at least two blogs that were working with the latest versions of WP Better Security and BulletProff Security. Although they worked initially they stopped working at some point over the past few days (it may have happened when I did a recent update of WP Better Security). I think I need to go with BPS and find another way to “hide” the back end. I have another plugin that does that and may try it and forget WP Better Security.
Plugin Author
AITpro
(@aitpro)
Hmm that sounds a lot like the cPanel Broken HotLink Protection Tool problem – See this sticky thread for details – http://wordpress.org/support/topic/plugin-bulletproof-security-broken-cpanel-hotlink-tool-404-errors-unable-to-edit-htaccess-files?replies=4
Or if wp better security automatically changes things on regular intervals by using a cron job then most likely the wp better security .htaccess code will continue to be added to the top of the .htaccess file at intervals, which of course is going to continue to cause website problems. When i did my testing i only tested for about an hour and then deleted the plugin so i do not know if it schedules cron jobs. maybe check with them and see what they say.
Thanks again for all your patience and kind support AITpro. If I ever get this to work I will post back. I certainly don’t want you to continue to spin your wheels on this, but do appreciate all you have done.
Plugin Author
AITpro
(@aitpro)
No problem and i have another person experiencing what appears to be either the exact same problem or a very similar problem.
http://wordpress.org/support/topic/plugin-bulletproof-security-changing-login-url-disables-bps?replies=10
My hunch looking at the .htaccess code that wp better security is creating is that the section of coding that deals with rewriting the login page in order to hide it needs to included inside the WordPress rewrite loop and cannot exist outside of the wordpress rewrite loop as stand alone code.
I guess what i will need to do is fully turn on everything in wp better security to find out the full extent of the problems. If i thought hiding things had any value at all i would add this to BPS, but trying to hide things is silly – you cannot hide from bots – 99% of hacker recon is done with bots so just plain silly.
Plugin Author
AITpro
(@aitpro)
i found this good example of how to hide the wp-admin login in a way that i might actually do it myself and as i suspected the login hiding coding is incorporated/included into the wordpress rewrite loop so since wp better security is trying to do this outside of the loop then that is what is causing the problems. going by this example you could probably piece together the wp better security coding in a way that it would work, but what a royal pain. instead if you want them to permanently fix their coding then they will need to check the root .htaccess file for a reference string in the WordPress Rewrite loop and then build up/add their .htaccess code by using str_replace and file_put_contents instead of trying to dump it into the root .htaccess file as stand alone code.
RewriteEngine On
RewriteBase /
##### ABOVE THIS POINT IS ALREADY INSERTED BY WORD PRESS
##### Michi’s code is BELOW #####
RewriteCond %{REQUEST_URI} wp-admin/
RewriteCond %{QUERY_STRING} !YOURSECRETWORDHERE
RewriteRule .*.php [F,L]
RewriteCond %{QUERY_STRING} !YOURSECRETWORDHERE
RewriteRule ^ADMINFOLDER/(.*) wp-admin/$1?%{QUERY_STRING}&YOURSECRETWORDHERE [L]
##### Michi’s code is ABOVE #####
##### BELOW THIS POINT IS ALREADY INSERTED BY WORD PRESS
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
Read more: http://www.phpmagicbook.com/hide-wordpress-wp-admin-login-page/#ixzz241vwWZ36
But like i have already said previously this is completely silly because bots will still always find the login page 100% of the time with very simple probes.
And if you want a good laugh my site was being attacked for 1 week straight by the google-bot. LOL yeah don’t get me started on how silly trying to block bots is. user agents, hostnames and IP’s can all be very easily faked/spoofed. 😉
