WF Cache Code

Resolved

(@aspasa)

I’m not understanding why the #WFCACHECODE lines in my .htaccess are there – specifically because I’m not using WF’s Webcaching engine?

For example with no WF Webcaching turned on and All Live Stats Info. in full display the below code has been written to my site’s .htaccess:

#WFCACHECODE - Do not remove this line. Disable Web Caching in Wordfence to remove this data.
<IfModule mod_deflate.c>
	AddOutputFilterByType DEFLATE etc.
	<IfModule mod_headers.c>
		Header append Vary User-Agent env=!dont-vary
	</IfModule>
	<IfModule mod_mime.c>
		AddOutputFilter DEFLATE js css htm html xml
	</IfModule>
</IfModule>
<IfModule mod_mime.c>
	AddType
</IfModule>
<IfModule mod_setenvif.c>
	SetEnvIfNoCase Request_URI \.html_gzip$ no-gzip
</IfModule>
<IfModule mod_headers.c>
	Header set Vary "Accept-Encoding, Cookie"
</IfModule>
<IfModule mod_rewrite.c>
	AddDefaultCharset utf-8

	#Cache rules:
	RewriteEngine On
	RewriteBase /
	RewriteCond %{HTTPS} on
	RewriteRule .* - [E=WRDFNC_HTTPS:_https]
	RewriteCond %{HTTP:Accept-Encoding} gzip
	RewriteRule .* - [E=WRDFNC_ENC:_gzip]
	RewriteCond %{REQUEST_METHOD} !=POST
	RewriteCond %{HTTPS} off
	RewriteCond %{QUERY_STRING} ^(?:\d+=\d+)?$
	RewriteCond %{REQUEST_URI} (?:\/|\.html)$ [NC]
	RewriteCond  %{REQUEST_URI} !^/revslider/$
	RewriteCond  %{REQUEST_URI} !^/downloads\-manager/$
	RewriteCond  %{REQUEST_URI} !^/captcha/$
	RewriteCond  %{REQUEST_URI} !^/wp\-symposium/$
	RewriteCond  %{REQUEST_URI} !^/test\.html$
	RewriteCond  %{REQUEST_URI} !^/\?author\=2$
	RewriteCond  %{REQUEST_URI} !^$
	etc.
</IfModule>
#Do not remove this line. Disable Web caching in Wordfence to remove this data - WFCACHECODE

So, my Web caching IS disabled in Wordfence and yet the above appears in .htaccess?

Also, the blocked URL’s referred to in my prior post a half hour ago are referred to above in #Cache Rules: RewriteConds

I am confused as to why WF’s .htaccess code is appearing when Webcaching is turned off.

Thanks for any help here…

https://wordpress.org/plugins/wordfence/

Viewing 13 replies - 1 through 13 (of 13 total)

Plugin Author WFMattR
(@wfmattr)

10 years, 6 months ago

Anna,

Are you using the latest version of Wordfence, 6.0.15?

If Wordfence is up to date, it may be that your .htaccess file is not writeable by the web server user, but it must have been before. I think the code above is from an older version of Wordfence, so the file may have been that way for a while.

Before making any changes, make sure to keep a copy of the current .htaccess file, just in case of problems.

If you know how to check the permissions and owner of the .htaccess file, I would check that first. The “right” permissions depend on your host’s setup, so they may need to help, if you are not sure what to use. (It should be similar to other WordPress core files.) It could also be that the host blocked writing to that file intentionally, if they are too aggressive with security.

Turning caching on, then turning it off again should clear those rules out, but it will only work if the permissions/owner are correct.

Alternately, you could save a backup of the .htaccess file manually, and remove only those lines from the file, that you posted above. Be very careful not to remove anything else, and make sure you know how to put the backup copy back if needed, since any errors could stop the whole site from working temporarily.

acekin
(@acekin)

10 years, 6 months ago

I have reported this problem several times. On my systems I can still make it happen on demand by editing the Options in Wordfence and adding, or deleting, a URL to the “Immediately block IP’s that access these URLs” field. Never fails, WF will dutifully add the Falcon caching code block and I have to go and edit the htaccess file to remove it. Tim will remember my reports from the time when I was a premium member.

I am using the latest version of WF and I have just checked to make sure this still happens, it does.

Plugin Author WFMattR
(@wfmattr)

10 years, 6 months ago

@acekin: Thank you for the input — I will check the status of the bug report and see if it can be corrected soon.

@anna: If this was the cause of your issue above, you may still need to follow the steps above once, to remove the code that was originally added.

Thread Starter Brian North
(@aspasa)

10 years, 6 months ago

@acekin thanks for the moral support there. Yes, I am constantly and frequently changing the “URL Block” field as I can’t figger why it’s not working for me! Despite the cachecode/htaccess issue does the “Immediately block IP’s…” work for you?

@wfmattr I have several times on a few sites removed this code and then, as the Immediately Block IP’s… isn’t working for me, I re-edit that field and thanks to acekin’s comment above, I find the cachecode back in my htaccess.

as an aside, the last time I did this [and only the last time] the site wouldn’t come back up with a php error line 15 or something. Searched the web and thousands of similar WF errors appeared.

Anyways I’m just off to see if the re-install of WF works for blocking IP’s accessing URL’s.

Thanks all for your input.

acekin
(@acekin)

10 years, 6 months ago

@anna, yes that feature works for me. I see the results in the Blocked IPs list, the reason will be given as “Accessed a banned URL”. Those I manually block because of suspicious code injection attempt (or at least that’s how I interpret that long gibberish URL) show as manual block by admin. If I manually block an IP I generally make it permanents in the same page.

I have documented and demonstrated the Options changes adding the Falcon code to htaccess file quite a while ago and decided to live with it since no solution came through, I still do!

Thread Starter Brian North
(@aspasa)

10 years, 6 months ago

Confirmed – on new install after having cleared database and tables.

Made 2 entries into “Immediately block IP’s that access these URLs” and .htaccess was overwritten with new WF cachecode. [And yes, WF caching was turned off.]

acekin
(@acekin)

10 years, 6 months ago

Glad to hear I’m not alone, sorry to hear you are having this problem too. I don’t know why this has eluded them to find a fix, it is a problem that can be replicated on demand, at least on some systems.

Oh, well …

Plugin Author WFMattR
(@wfmattr)

10 years, 6 months ago

Thank you both for the additional details. I’ll post back here soon when I know more. If you haven’t already, you can click “Subscribe to Topic” in the right sidebar of this post, to get email updates when there are any new replies.

Thread Starter Brian North
(@aspasa)

10 years, 6 months ago

also, as an addendum to this unrequited ‘write to htaccess file’ issue;

When ‘some’ other change is made to the WF Options – e.g. changing the block/lock timeouts from 20 to 10 days – WF writes a 1 byte change to the .htacess.

what is this 1 byte change please?

Plugin Author WFMattR
(@wfmattr)

10 years, 6 months ago

I can’t seem to trigger a one-byte change by saving other Wordfence options. It might only happen with a combination of Wordfence and another plugin.

Does it add or subtract a byte? And does it only happen once, or every time you save another option?

It is most likely just a line break before or after one of the sections or the end of the file — but if you want, you can save a copy of your .htaccess and then save another copy after the change happens, then email both files to me at mattr [at] wordfence.com.

(By the way, he main issue above is in the system, and I hope it can make it in the next release, but can’t say for sure yet.)

Plugin Author WFMattR
(@wfmattr)

10 years, 6 months ago

I’m marking this as resolved since it is being tracked in our internal system, and it should be fixed in a future version of Wordfence.

Thanks for the reports of this issue.

If there is still a problem with the one-byte change, feel free to email me the before-and-after copies of .htaccess at the address above (and include a link to this post) — if it’s not causing any problems and only happens when the original issue is occurring, it is likely a newline character and may depend on your other installed plugins, since I couldn’t reproduce it here.

-Matt R

FB861

Thread Starter Brian North
(@aspasa)

10 years, 6 months ago

@wfmattr

the “one-byte change” i can forget about for now thank you.

Unfortunately I am in Tech. support for over 25 years and it seems, these days, that Updates ‘surprises’ from Software vendors add to a constant ‘instability creep’. And also, a measurably growing consumer frustration that is not ‘monetizable’ for anyone.

The current trend of Software Updates are also an awful, yes awful, productivity loss – as I’m sure you are aware.

Thank you for bumping the OP’s issue to your programmers. Much appreciated and please forgive me if I don’t get too ‘into’ other, less major, Software issues.

Plugin Author WFMattR
(@wfmattr)

10 years, 6 months ago

Yes, I understand — I had two sites break with different issues from the recent WP security updates! One was caused by the change in shortcode handling, and another with a change in handling javascript in posts that caused code to wrap onto the same line as single-line comments (commenting out the rest of the script).

That’s ok about the minor issue — I just didn’t want to leave it hanging if you thought it might be changing something important. Thanks for the follow-up!

Viewing 13 replies - 1 through 13 (of 13 total)

The topic ‘WF Cache Code’ is closed to new replies.