ZenCache removes custom htaccess rules that use # BEGIN/END ZenCache comment markers

[raamdev]

Steps to reproduce this bug

1. Install and activate ZenCache Pro v151114

2. Add some rules to your .htaccess file that include start and end marker comments like the following:

   # BEGIN ZenCache 
   [...]
   # END ZenCache
   

3. Enable the ZenCache Pro Static CDN Filters (ZenCache → Plugin Options → Static CDN Filters)

4. Click "Save All Changes" at the bottom

Expected Behavior

ZenCache should add any necessary rules to the .htaccess file and not touch any existing custom .htaccess rules in the file.

Observed Behavior

ZenCache deletes everything in between the # BEGIN ZenCache and # END ZenCache comments and replaces it with a copy of the Static CDN Filters rules, which means that I lose any custom .htaccess rules I may have added to my .htaccess file!

---

Note: As of ZenCache Pro v151114, the only time that ZenCache will attempt to write to the .htaccess file is when Static CDN Filters are enabled. If you do not use the Static CDN Filters feature, you are unaffected by this bug.

[raamdev]

@raamdev writes in #617 (comment)...

I think the best solution to this whole problem is to use a somewhat unique key of some sort in our start and end markers, something like this so that we can look for something specific:

# BEGIN ZenCache (Please do not remove this comment key: 2hetel1r&TekIF0)
[...]
# END ZenCache (Please do not remove this comment key: 2hetel1r&TekIF0)

@jaswsinc writes in #617 (comment)...

I love this idea. That would be perfect.

[raamdev]

The original bug reported by @Kalfer in #617 exhibited itself by the following Dashboard message that appeared when saving the ZenCache options despite the .htaccess file being writable:

The issue there was that @Kalfer's existing .htaccess file already included the word zencache in the comments, which caused this conditional to pass and return false.

Fixing the bug reported at the beginning of this issue will solve both problems: the inadvertent removal of existing .htaccess rules that might be already using # BEGIN/END ZenCache markers and the invalid "Most likely a permissions error" Dashboard message.

[raamdev]

@jaswsinc writes...

I love this idea. That would be perfect.

So a simple static string in the comment should suffice, right? I was thinking we could dynamically generate a unique string on a per-site basis, but that seems unnecessary and asking for trouble (e.g., if the .htaccess gets copied to another site/server the generated string won't match).

[jaswrks]

Yeah, good point. I agree, something that is always the same in every copy of ZenCache, but unique enough that it will not clash with anything else in that file; e.g., ZenCache base64 encoded: WmVuQ2FjaGU=

[raamdev]

Next Pro Release Changelog:

• Bug Fix: Fixed a bug that was generating a "Failed to update your /.htaccess file" error message. The routines that update your .htaccess file were failing if your .htaccess file already contained the word "ZenCache" (case-insensitive). See Issue #617 and Issue #620.
• Bug Fix: Fixed a bug that in some scenarios could cause custom .htaccess rules to be lost if your .htaccess file was using the exact same comment start and end markers as ZenCache (# BEGIN ZenCache and # END ZenCache). If you were using those exact same start and end markers, ZenCache was replacing whatever was between them with a copy of the ZenCache .htaccess rules. ZenCache now uses a unique marker (WmVuQ2FjaGU) to identify its own code blocks inside your .htaccess file. See Issue #620.

[raamdev]

ZenCache Pro v151220 has been released and includes changes worked on as part of this GitHub Issue. See the release announcement for further details.

---

This issue will now be locked to further updates. If you have something to add related to this GitHub Issue, please open a new GitHub Issue and reference this one (#620).