• Resolved sunrises

    (@sunrises)


    Dear Plugin Developers,

    I tried the Cachify plugin and noticed something unexpected. To narrow down the problem exactly, I disabled all other plugins on the website and cleaned up the .htaccess file.

    It so happens that I use Jeff Starr’s 7G Firewall* in the .htaccess file to protect my website. This works along with Cachify as long as I use “database” as the caching method. If I select “hard disk”, the website will only show “403 forbidden” to the visitor. Until the cache is cleared, but then immediately again. Using a SFTP program, you can see that Cachify does not create the /wp-content/cache/cachify folder at all.

    * https://perishablepress.com/7g-firewall/

    But what is interesting is the following: If you do NOT put the code snippet that Cachify wants you to put in the .htaccess file when using the disk method above, suddenly everything works fine despite 7G firewall. If you look at the page source, you can see that a cached web page is being delivered. And the whole thing is also gzip compressed if I add another block with “AddOutputFilterByType DEFLATE” rules in the .htaccess.

    What do you think, is it really necessary in my case to put the Cachify code snippet in the .htaccess – it seems to work fine without that.

    Thanks for your good work and best wishes!`

Viewing 6 replies - 1 through 6 (of 6 total)
  • Hi,

    What do you think, is it really necessary in my case to put the Cachify code snippet in the .htaccess – it seems to work fine without that.

    As you noticed already, it’s not strictly necessary, but it’s strongly recommended. The rules in .htaccess file make it possible to read the file from cache without loading WordPress (without even invoking PHP or any database access). Only Apache webserver is involved, so it runs very fast.

    When Apache delivers the file from cache, it internally runs a request to which the rules in .htaccess file are applied again (including 7G rules). My guess is that one of the rules in 7G:[REQUEST URI] section is breaking such requests because these rules target strings that are part of URL, but should not be present in path part under normal circumstances (like /https/ etc.) Cachify however has to store entire URL as file path (including scheme and domain), so this can lead to conflicts. Try to disabling the rules in 7G:[REQUEST URI] section one by one and find the offending one.

    Cheers,
    ?eslav

    Thread Starter sunrises

    (@sunrises)

    Dear ?eslav,

    thank you for your reply.

    I had already tried what happens when you remove the request-uri part in the firewall. The result is that the 403 forbidden error no longer appears. But still no cached website is delivered, the directory /wp-config/cache/cachify is not created. I had also tried replacing the 7G firewall with the 6G firewall, but that doesn’t work together with Cachify either. Do you have any more ideas about this? If I can’t solve the problem, maybe I should go for the database cache method?

    Best wishes and thank you!

    But still no cached website is delivered, the directory /wp-config/cache/cachify is not created.

    This is strange. I cannot see any reason why this directory would not be created when 7G is active as the directory is created from within PHP.

    If you use database cache method, you certainly go around the problem, but I run a caching plugin very similar to Cachify disk method and had to only disable one of the rules in 7G:[REQUEST URI] section.

    I would suggest the following: try disabling the 7G (or 6G) firewall completely. See whether disk caching method works. If not, there is another problem – perhaps file permission issue. If disk caching works, then you can reactivate 7G and try to tweak (by disabling one by one) the rules in 7G:[REQUEST URI] section. If you cannot make it work, go with database caching.

    Thread Starter sunrises

    (@sunrises)

    Dear ?eslav,

    now it works without any problem.

    I have found that I only need to remove three characters from the request uri part of the 7g firewall:

    Before:

    fla|git|gz|hg|inc|ini|

    After:

    fla|git|hg|inc|ini|

    You have to remove “|gz”.

    Now I can use the disk cache method with the cachify rules in the .htaccess file. No idea why I had previously stated that there must be other conflicts besides the one in the request uri part.

    Thank you!

    • This reply was modified 3 years, 1 month ago by sunrises.

    Hi @sunrises,

    I’m glad I could help ??

    Btw. would you mind marking the thread as resolved?

    All the best,
    ?eslav

    Jeff Starr

    (@specialk)

    Hey just fyi for anyone interested, the next version of 7G Firewall (v1.5) implements the above change (to remove the match for .gz extension). Thank you @sunrises for bringing to my attention.

Viewing 6 replies - 1 through 6 (of 6 total)
  • The topic ‘Conflict with the 7G firewall by Jeff Starr’ is closed to new replies.