Failed to update your /.htaccess file automatically.

[CotswoldPhoto]

ZenCache™ Pro v151216-RC

Testing the HTML Compression options. All HTML Compression Options set to on, but needed to switch set 'No, do not combine JS from into fewer files.' because this conflicts with jquery.nivo slider js file. This gives:

Failed to update your /.htaccess file automatically. Most likely a permissions error. Please make sure it has permissions 644 or higher (perhaps 666). Once you've done this, please try saving the ZenCache options again. But it is at 644!!

The options update OK.

Switching off the footer js scripts causes a 500 error. But the settings still save!!

The first time this happened, it corrupted the .htaccess file adding some random characters after the

# BEGIN ZenCache
# END ZenCache

section. and this 500 the site until I found the line and removed it.

[raamdev]

it corrupted the .htaccess file adding some random characters after the

@CotswoldPhoto Thanks for the report! Hmm, the latest release changes the .htaccess utils so that the following marker is added to the comment block:

# BEGIN ZenCache WmVuQ2FjaGU (the WmVuQ2FjaGU marker is required for ZenCache; do not remove)
# END ZenCache WmVuQ2FjaGU

Are those the "random characters" that you saw?

Would you be able to share a copy of your .htaccess file so that I can attempt to reproduce this issue on my test site?

---

Also, can I ask how you updated to the RC? Did you deactivate + delete the previous version, then add the RC via Plugins → Add New → Upload Plugin? Or did you do something else, like just overwrite the existing plugin folder on the server?

[CotswoldPhoto]

The WmVuQ2FjaGU was what was on a separate line. It has happened on one site so far. This is the htaccess file as I found it:

BEGIN ZenCache

END ZenCache

WmVuQ2FjaGU

order allow,deny deny from all

Prevent folder browsing

Options All -Indexes

# Enable expirations ExpiresActive On # Default directive ExpiresDefault "access plus 1 month" # My favicon ExpiresByType image/x-icon "access plus 1 year" # Images ExpiresByType image/gif "access plus 1 month" ExpiresByType image/png "access plus 1 month" ExpiresByType image/jpg "access plus 1 month" ExpiresByType image/jpeg "access plus 1 month" # CSS ExpiresByType text/css "access 1 month" # Javascript ExpiresByType application/javascript "access plus 1 year" AddOutputFilterByType DEFLATE text/plain text/html AddOutputFilterByType DEFLATE text/xml application/xml application/xhtml+xml application/xml-dtd AddOutputFilterByType DEFLATE application/rdf+xml application/rss+xml application/atom+xml image/svg+xml AddOutputFilterByType DEFLATE text/css text/javascript application/javascript application/x-javascript AddOutputFilterByType DEFLATE font/otf font/opentype application/font-otf application/x-font-otf AddOutputFilterByType DEFLATE font/ttf font/truetype application/font-ttf application/x-font-ttf

BEGIN WordPress

RewriteEngine On RewriteBase / RewriteRule ^index.php$ - [L] RewriteCond %{REQUEST_FILENAME} !-f RewriteCond %{REQUEST_FILENAME} !-d RewriteRule . /index.php [L]

END WordPress

BEGIN MainWP

END MainWP

[CotswoldPhoto]

I shared the .htaccess on github. The first time I overwrote the plugin
using ftp. The second time I deleted it and installed it via plugins in
Admin. Both ways produced the error. The first time it gave the .htaccess
you see on github, the second time (doing it by removing and installing via
upload) it put those characters before the rest of the file. Same effect
both times.

On Wed, Dec 16, 2015 at 7:56 PM, Raam Dev notifications@github.com wrote:

it corrupted the .htaccess file adding some random characters after the

@CotswoldPhoto https://github.com/CotswoldPhoto Thanks for the report!
Hmm, the latest release changes the .htaccess utils so that the following
marker is added to the comment block:

BEGIN ZenCache WmVuQ2FjaGU (the WmVuQ2FjaGU marker is required for ZenCache; do not remove)

END ZenCache WmVuQ2FjaGU

Are those the "random characters" that you saw?

Would you be able to share a copy of your .htaccess file so that I can

attempt to reproduce this issue on my test site?

Also, can I ask how you updated to the RC? Did you deactivate + delete the
previous version, then add the RC via Plugins → Add New → Upload Plugin?
Or did you do something else, like just overwrite the existing plugin
folder on the server?

—
Reply to this email directly or view it on GitHub
#633 (comment).

[raamdev]

@CotswoldPhoto Thank you. I will try to reproduce this. Two more quick questions: What version of PHP are you running and what web server are you running?

[CotswoldPhoto]

Centos7.1 with Apache/2.4.16 (Unix) OpenSSL/1.0.1e-fips mod_bwlimited/1.4 PHP/5.6.16, using the cPanel/WHM Easyapache 3 stack.

[jaswrks]

@raamdev I was able to reproduce a portion of this.

As requested, I ran the following test...

Install ZenCache v151114, enable Static CDN Filters + save options, deactivate Static CDN Filters + save options, leave ZenCache enabled+active, and then update to the RC.

There is a minor problem in this test. Whenever I toggled Static CDN Filters off in v151114 and saved options (with ZC still enabled), I ended up with: https://gist.github.com/jaswsinc/f795b76f42fda25529b7

# BEGIN ZenCache
# END ZenCache

That problem is resolved by the VS upgrade routine in 151216-RC via this file.

However, when I was testing and I....

leave ZenCache enabled+active, and then update to the RC.

The VS upgrade did not run. It looks like that happened because of all of my testing though; i.e., the version in my array of options was higher than the version of the software I was actually running. Still trying to verify that.

What resulted from this:

• Whenever I tried to enable Static CDN Filters in the upgraded copy of v151216-RC, I got...

  Failed to update your /.htaccess file automatically. Most likely a permissions error. Please make sure it has permissions 644 or higher (perhaps 666). Once you've done this, please try saving the ZenCache options again.

  That error occurs because of these lines that still exist in my .htaccess file.

  # BEGIN ZenCache
  # END ZenCache
  

  Only the VS upgrade deals with those, and since it didn't run during my last test (due to a version conflict in my options array), I am getting that error now.

---

I have been unable to reproduce this though:

# BEGIN ZenCache
# END ZenCache

WmVuQ2FjaGU

That almost looks to me like there was some corruption in the file before ZC tried to work on it. Perhaps we can avoid further corrupting a file like this by running the contents of the .htaccess file through: wp_check_invalid_utf8. If that check fails, we should just bail. Otherwise we may corrupt the file even further and bring down the site; i.e., what mild corruption may exist, after running a replacement on that file, we could end up with something that actually breaks the syntax itself.

[jaswrks]

So I propose two small changes:

• We could try to do a better job of keeping the version that's in the array of options in sync. That way it remains as it should, even when you're running RC tests like this.
• Run the contents of the .htaccess file through: wp_check_invalid_utf8. If that check fails, we should just bail. Otherwise we may corrupt the file even further and bring down the site; i.e., what mild corruption may exist, after running a replacement on that file, we could end up with something that actually breaks the syntax itself.

[patdumond]

I tested the install on 2 sites:

Installed ZenCache RC151216 via FTP on one site where it had never previously been installed. I then enabled HTML compression (all options set to "Yes") and saved the settings. No error messages. Checked .htaccess and found the correct settings as listed by @raamdev above. Deactivated and deleted ZenCache. Checked .htaccess and ZenCache settings had been properly removed.

I then installed ZenCache RC151216 on a site where ZenCache had previously been installed. I first deactivated and deleted the existing ZenCache installation and then installed the RC using the Add New Plugin panel. I then enabled HTML compression (all options set to "Yes") and saved the settings. No error messages. When I checked the .htaccess file, however, it only had the following ZenCache entry:

# BEGIN ZenCache
# END ZenCache

[raamdev]

@patdumond writes...

. I then enabled HTML compression

Enabling the HTML Compressor does not write anything to the .htaccess file at this time, only the Static CDN Filters do, so the behavior you observed is normal.

[raamdev]

@jaswsinc writes...

The VS upgrade did not run. It looks like that happened because of all of my testing though; i.e., the version in my array of options was higher than the version of the software I was actually running. Still trying to verify that.

I was not able to reproduce what you saw. I used the same scenario you referenced:

Install ZenCache v151114, enable Static CDN Filters + save options, deactivate Static CDN Filters + save options, leave ZenCache enabled+active, and then update to the RC.

("update to the RC" was done by simply overwriting the wp-content/zencache-pro/ directory with a copy of the v151216-RC, and then reloading my WP Dashboard.)

Before the "update", my .htaccess file had this:

# BEGIN ZenCache
# END ZenCache

After the update, as soon as I loaded the WordPress Dashboard, the .htaccess file was updated to this:

# BEGIN ZenCache WmVuQ2FjaGU (the WmVuQ2FjaGU marker is required for ZenCache; do not remove)
# END ZenCache WmVuQ2FjaGU

Also, the "ZenCache detected a new version of itself. Recompiling w/ latest version... wiping the cache... all done :-)" Dashboard message popped up, which told me that check_version() had run. That method attaches to admin_init, and it also calls the VS upgrade routine.

The version check that runs in that routine checks out too:

    $prev_version = $self->options['version'];
    if (version_compare($prev_version, VERSION, '>=')) {
        return; // Nothing to do; up-to-date.
    }

The VERSION (after the update) would be 151216-RC and $prev_version would be 151114, so the VS upgrade would run as expected. The fact that the "detected a new version" message popped up confirms that the VS upgrade routine was called (it comes before the line that creates that Dashboard notice).

---

So I'm still not seeing any issue with the upgrade process.

---

@jaswsinc writes...

So I propose two small changes:

We could try to do a better job of keeping the version that's in the array of options in sync. That way it remains as it should, even when you're running RC tests like this.

As I described above, I'm not seeing any issue here.

Run the contents of the .htaccess file through: wp_check_invalid_utf8. If that check fails, we should just bail. Otherwise we may corrupt the file even further and bring down the site; i.e., what mild corruption may exist, after running a replacement on that file, we could end up with something that actually breaks the syntax itself.

I agree. That sounds like a great idea. I'll submit a PR for this shortly.

[raamdev]

Next Pro Release Changelog:

• Bug Fix: Fixed a bug where ZenCache could inadvertently corrupt the .htaccess file if it contained invalid UTF-8 characters. This has been fixed by first checking the .htaccess file for invalid UTF-8 characters via wp_check_invalid_utf8(). See Issue #633.

[raamdev]

Next Pro Release Changelog:

• Enhancement: Improved .htaccess utilities so that an exclusive lock is acquired when reading+writing to the file. This helps avoid inadvertently corrupting the .htaccess file in scenarios where another process might be reading/writing to it at the same time. See Issue #633.

[raamdev]

ZenCache 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 (#633).