Plugin Author
AITpro
(@aitpro)
The WordPress BEGIN and END placeholder text is no longer created in the BPS root htaccess file as of version .51.2. See this forum topic for why that is: http://forum.ait-pro.com/forums/topic/root-and-wp-admin-htaccess-file-significant-changes/
The thread in the link above is 3 years old so that is outdated info.
If you are still using WordPress placeholder text then delete it.
Thread Starter
mrppp
(@mrppp)
No, but the WP Super cache adds it in the Root htaccess
at the bottom
as so
# END WPSuperCache
# BEGIN WordPress
# END WordPress
But this is correct, the rewrite rule for this wp supercache to go in the root not protected htaccess?
seems to work
Plugin Author
AITpro
(@aitpro)
Oh ok. Yep it would not be a matter of working or not working in regards to WP Super Cache. We have built-in automated failsafes that keep a website from crashing if another plugin or theme is using/executing the flush_rewrite_rules() function and the root htaccess file is not locked.
WP Super Cache code goes in the BPS Custom Code text box for cache code. See the Custom Code video tutorial link on the BPS Custom Code page for examples.
Thread Starter
mrppp
(@mrppp)
Ok i,ll add there,
i guess if it is a cache code then i do not need the Speed Boost Cache Code i already have? or is this in addition, just put my plugin code for WP supercache before it?
assume still need it to set browser expirations.
You mention
root htaccess file is not locked.
Should this be locked for security?
Many thanks
Plugin Author
AITpro
(@aitpro)
Correct. If you are using WP Super Cache code then you can remove the Speed Boost Cache code. They do the same thing so there is no point in having duplicate code.
The root htaccess file lock was created to prevent the common flush_rewrite_rules() function problem which caused websites to crash. This is no longer a problem because there are several failsafes built-in to BPS that prevent websites from crashing if another plugin or theme executes the flush_rewrite_rules() function. In other words, this very common problem that was occurring before will no longer occur anymore.
Thread Starter
mrppp
(@mrppp)
Excellent, I,ll go delete that speed code
Thank You
Thread Starter
mrppp
(@mrppp)
Actually i will leave in,
it makes a difference with Leverage browser caching especially on jpg
i just commented out
# Test which ETag setting works best on your Host/Server/Website
# with Firefox Firebug, Firephp and Yslow benchmark tests.
# Create the ETag (entity tag) response header field
#FileETag MTime Size
# Remove the ETag (entity tag) response header field
#Header unset ETag
#FileETag none
Page speed prefers it, so so long as it is an improvement.
