BPS setup steps:
1. Click the AutoMagic buttons
2. Activate All BulletProof Modes.
3. Setup complete.
Note: In order for BPS Pro to work correctly you MUST be using a Custom Permalink Structure: http://codex.wordpress.org/Using_Permalinks#Choosing_your_permalink_structure
BPS removal steps:
1. Activate Default Mode on the Security Modes page.
2. Use the Delete wp-admin .htaccess feature on the Security Modes page.
3. Deactivate and delete BPS on the WP Plugins page.
Does BulletProof Security work on every type of Server?
Compatible With: Apache CGI configured Servers, Apache DSO configured Servers (May require file permission and/or Ownership changes), Nginx frontend Server with Apache backend Server and LiteSpeed Servers
A custom permalink structure must be created in Settings >>> Permalinks: http://codex.wordpress.org/Using_Permalinks#Choosing_your_permalink_structure
I used automagic buttons in my initial installation but not after updating that plugin. Is it necessary to rebuild the .htaccess files after an update?
Normally you would not have to do anything after upgrading, but here are 2 very common problems where you end up having to activate BulletProof Modes again.
The cPanel broken HotLink Protection Tool problem:
The WordPress flush_rewrite_rules function problem:
Both of these problems can be prevented from occurring repeatedly by locking your Root .htaccess file if your Host allows this. There is a Lock htaccess File button on the BPS Edit/Upload/Download tab page. If your Host does not allow this then you will see a 403 error and will have to delete the root .htaccess file via FTP, log back in, click the Turn Off AutoLock button and activate Root folder BulletProof Mode again.
Also if you update your permalinks on the WordPress Permalinks page then the WordPress flush_rewrite_rules function is processed. So if do not want your root .htaccess file to be flushed (code removed) then locking the root .htaccess file will prevent that from happening.
Hello, absolutely great plugin, I’ve been using it for long time. Thank you and congratulations for your work.
Please I have a doubt: I use as a basis for my themes the ‘Roots’ starter theme, thar uses rewrite URLs and needs to write some rewrite rules in .htaccess. I got it to work with Bulletproof by editing bulletproof secure.htaccess and putting my rewrite rules just after the line:
# BPS needs to find the - BPSQSE - text string in this file to validate that your security filters exist
In this way when permalinks are reflushed, I can turn on bulletproof security again without losing my rewrites.
The thing is: ‘Roots’ theme also provides some of the goodness of HTML5 Boilerplate .htaccess, and in previous versions of Bulletproof security I putted the Boilerplate htaccess code at the end of bulletproof secure.htaccess, like this:
# BEGIN HTML5 Boilerplate ... # END HTML5 Boilerplate
But when I try this with the current version, I get a 403 error and the changes in secure.htaccess are not saved. What would be the right place in secure.htaccess to put my custom code? Thank you very much in advance!
If you have additional custom .htaccess code then you can add it to BPS Custom Code to save it permanently and that custom .htaccess code will always be added/written to your .htaccess files if you ever need to use the AutoMagic buttons again.
Post the Boilerplate .htaccess code and I will tell you which BPS Custom Code text area/box it should go in.
New/additional setup step since Login Security was added to BPS.
Choose Login Security options and turn On Login Security.
Explanation required regarding how the installation of BPS affects the parent and child theme.
I am using a child theme and was advised not to make changes to the parent files. When I installed the BPS I had to create .htaccess files as part of the process/prompts so I assume this qualifies as a change to the parent?
Are both levels of my theme/site protected?
Can these additions/changes to the parent potentially create issues?
What are the experiences of child theme users with this plugin?
.htaccess files work at the folder/directory level. .htaccess files are heirarchical/recursive. If you have an .htaccess file in /folderA then those security rules will be applied to all folders and files in /folderA and all subfolders of /folderA – /folderA/subfolder1, /folderA/subfolder1/sub-subfolder1, etc.
So to sum this up in laymans terms since BPS adds a root .htaccess file to your website then the /wp-content/themes folder has BPS security rules applied to it and all Parent and Child Themes have BPS root .htaccess security rules applied to them.
Parent/Child Theme relationship
I was attempting to revert to default mode, so that another wordpress plugin can create database/ file backups.
However, I cannot revert back to the default mode, I get this error: “Failed to Activate Default htaccess Mode!”
How do I allow it to activate default mode again?
All permissions match recommended folder permissions.
What happens when you click the Create secure.htaccess File AutoMagic button?
Thanks for the reply;
“The file /var/www/4corners/wordpress/wp-content/plugins/bulletproof-security/admin/htaccess/secure.htaccess is not writable or does not exist.
Check that the file is named secure.htaccess and that the file exists in the /bulletproof-security/admin/htaccess master folder. If this is not the problem click HERE to go the the BulletProof Security Forum.”
I activated the automagic buttons a few days ago and they worked fine. I’m wondering if some folder permissions got changed?
Yep it looks like you have a file/folder permissions issue or Ownership issue (DSO Server type). Is this a CGI or DSO Server? You will find that info on the BPS System Info page.
It appears DSO
“Server API: apache2handler – Your Host Server is using DSO”
I noticed the following permissions:
“wp-config.php ../wp-config.php 644 0666”
But as I understand this means I should be able to read and write the directory, so that wouldn’t be the issue, would it?
666 file permissions for the wp-config.php file on a DSO Server type will allow you to write to the wp-config.php file.
The optimum choice would be of course to use CHOWN to change Ownership so that the PHP Script Owner and the PHP File Owner are the same. This would allow WordPress to use the “direct” Filesystem API Method and everything would just work.
See the other options available for DSO Server types in this WP Codex link.
Or you can always do everything by making file and folder permissions changes, but the ideal choice is to use CHOWN to change Ownership so that the PHP Script Owner and the PHP File Owner are the same.
- The topic ‘BPS setup steps, removal steps, requirements and compatibility’ is closed to new replies.