BPS Setup Wizard is not adding WP Super Cache custom code

This probably just means that you have an nginx server or that you have not selected Browser caching code = htaccess code. WPSC used to call this something like “mod_rewrite” for the option setting name. If you have an nginx server then I think WPSC does not create any htaccess code.

Another possibility is that your Root htaccess file is locked on the BPS > htaccess File Options > htaccess File Editor tab page. Unlock your root htaccess file if it is locked, Resave your WPSC option settings and run the Setup Wizard again.

If you cannot use htaccess code on your website/server or just want the BPS message to go away then add the placeholder text below in this BPS Root Custom Code text box: 1. CUSTOM CODE TOP PHP/PHP.INI HANDLER/CACHE CODE, click the Save Root Custom Code button and activate Root folder BulletProof Mode again.

# BEGIN WPSuperCache
# END WPSuperCache

Scratch the nginx possibility. I forgot that I added a condition to check for nginx server types. So you will not see the BPS error message if you have an nginx server.

Thank you for the response. I was hoping I could get the wizard to work as intended, it would just be easier than manually entering code with each change. However, maybe I am at fault, forgetting to unlock, decrypt the htacess file before running the wizard? Maybe the wizard could learn to unlock and decrypt, add the necessary code from other plugins and then lock up after it’s done. You can mark this resolved unless you have more to add. BPS is the best security plugin I’ve used, so I’m keeping it. Thanks again for the quick response.

• This reply was modified 2 years, 9 months ago by zeuspress.

The Setup Wizard does not need to encrypt or decrypt any htaccess code because it works in the background/internally where ModSecurity cannot breaks things. ModSecurity only breaks things when you use POST or GET forms (manual Form submissions). That is caused by your web host techs configuring ModSecurity CRS rules to check the body content (Source Code) of WordPress wp-admin area pages.

Obviously ModSecurity CRS rules should not be applied to the /wp-admin/ area, but unfortunately ModSecurity CRS is not very flexible and uses a very crude/outdated method of whitelisting. The ModSecurity CRS folks are all volunteers that do not have the spare time to rebuild or update CRS in a way that would make it user friendly. I know that because I have spoken to them directly regarding this.

Currently the Setup Wizard does handle locking and unlocking of the root htaccess file and even the wp-config.php file for WPSC AutoSetup by the Wizard. The problem occurs here in the BPS code below. If you have not selected/chosen/saved WPSC htaccess code option settings > Browser Caching then when BPS AutoSetup grabs WPSC option settings it sees that you do not have or want to use WPSC Browser Caching option settings. BPS is literally using WPSC functions to get your WPSC option settings.

The only thing I can think of to make the problem and solution easier to diagnose would be to add additional help information to the BPS WPSC message. Something like this: “…the WPSC Browser Caching option setting is not chosen. This will cause problem X. To solve problem X do these steps Z.”

## Important: These WPSC functions need to be executed in this order and also executed before any htaccess code stuff.
// Writes this WPSC wp-config.php file code: define('WP_CACHE', true);
wp_cache_check_global_config();
// Writes this WPSC wp-config.php file code: define( 'WPCACHEHOME', '/path/wp-content/plugins/wp-super-cache/' );
wp_cache_create_advanced_cache();
					
extract( wpsc_get_htaccess_info() );

• This reply was modified 2 years, 9 months ago by AITpro.
• This reply was modified 2 years, 9 months ago by AITpro.

I’m looking at this today to figure out the best solution. I see that WPSC has changed the way it does htaccess code creation. WPSC used to automatically create htaccess code in the root htaccess file, but now I see this WPSC message: “Rewrite rules must be updated. The rewrite rules required by this plugin have changed or are missing. Scroll down the Advanced Settings page and click the Update Mod_Rewrite Rules button.”. What I assume is that WPSC checks the root htaccess file for any other custom htaccess code and does not automatically create the WPSC htaccess code if it sees other custom htaccess code.

So running the Setup Wizard no longer works to automatically grab and setup WPSC option settings or htaccess code. So that means I will need to change the BPS code that is using WPSC code/functions or take a different approach instead of trying to setup WPSC htaccess code automatically.

I’ve had to make changes in BPS Setup Wizard AutoSetup code numerous times for caching plugins (WP Super Cache, W3 Total Cache, Comet Cache Plugin (free & Pro), WP Fastest Cache Plugin (free & Premium), LiteSpeed Cache and WP Rocket). Each time a caching plugin changes its code then I need to make changes in BPS code that will work with the new changes in caching plugins. Bit of a headache to say the least.

Going back to the method I was using years ago before creating the Setup Wizard AutoSetup feature, which was to only check for existing caching plugins htaccess code in the root htaccess file, is not a good solution. ie If caching plugin htaccess code is found then combine it into BPS htaccess code. ie If it is not found then do nothing and do not display a warning message. Using that method is less sophisticated and does not alert folks about problems happening with their caching plugins. Example: If htaccess code is not being created by a caching plugin due to an option setting not be enabled by mistake in a caching plugin then the person will not be aware that a problem exists with their caching plugin. That is assuming of course that the caching plugin does not display its own error message and some of them don’t because they use the simple logic that someone has opted out of using htaccess code.

I’m not really happy about going that route though. I would rather have someone be irritated by the BPS message and figure out the caching plugin problem. So what I think is the best solution is to not try to figure out why a caching plugin is not doing what it should be doing in BPS Setup Wizard code, but let someone know that things are not right with their caching plugin. This can be achieved by using the same method I am doing now, but instead of displaying a lengthy BPS message about the problem it would be better to make the BPS message very simple with a link to an external forum topic with possible causes for the caching plugin problem. By doing that I will be able to update the forum topic if/when things change in each caching plugin.

I can still have the Setup Wizard do AutoSetup for caching plugins, but what needs to happen first is that someone needs to make sure their caching plugin is setup correctly/fully and then run the Setup Wizard instead of the Setup Wizard trying to automatically fix the caching plugin problem on its own.

• This reply was modified 2 years, 9 months ago by AITpro.

Thank you for your effort and detailed response.

You wrote “I would rather have someone be irritated by the BPS message and figure out the caching plugin problem.”

The issue with this approach, if the BPS message remains as written, is that many (most?) plugin users are novices like me and may assume that the problem is with BPS, delete it and give it a 1 star review.

WPSC has a simple option that does not involve the htaccess file. It also warns that the other options may require manually changing files that could bring down their site if not done correctly. Perhaps a BPS message that says if they use the WPSC simple method, then just dismiss the BPS message. But if they use the other methods, they need to follow the instructions on the plugin’s wordpress page to add the required code to the htaccess file using the correct custom code box.

You can mark this as resolved if you wish, I’m just using the simple code for now.
Thank you for the support.

• This reply was modified 2 years, 9 months ago by zeuspress.
• This reply was modified 2 years, 9 months ago by zeuspress.

Yep, you are correct on all issues. The problem arises when BPS tries to figure out what is going on based on using option settings/code/functions from another caching plugin because when that plugin changes its code then the BPS checks/code will no longer work.

So I need to step away from that approach altogether or continually check other caching plugins regularly and make changes in BPS code. Yeah don’t really want to go there. ??

I guess the best solution for BPS personally is just to simply add caching plugin htaccess code if it exists or do nothing if it does not exist. This works out ok for people as long as caching plugins display their own warning/error messages. If a caching plugin is not displaying their own warning/error messages then people get screwed. ??

I don’t like doing the “it’s not my problem” thing, but yep you are correct that the blame will and does fall on BPS. ??

Resolving this thread. The next version of BPS Setup Wizard AutoSetup for caching plugins will use a simplified method of setting up caching plugins htaccess code.

Wow this is really funky > WPSC will not add its htaccess code to the root htaccess file if it does not find the generic WP Rewrite htaccess code in the root htaccess file. I guess WPSC is now assuming that no one will ever create their own custom htaccess code. Very odd. Also I found 2 bugs that occur based on WPSC not allowing writing to the root htaccess file. So yeah glad you mentioned this issue. I don’t want anything to do with handling WPSC options/functions at all now after testing what WPSC is doing now. LOL

The plugin could not update /xxxxx/public_html/.htaccess file: WordPress rules empty.
The new rules go above the regular WordPress rules as shown in the code below: