Multisite cache/minify folder .htaccess updating issue

I tried making the .htaccess file immutable with:

RewriteBase /wp-content/cache/minify/

But that stopped sub-sites from loading entirely so that won’t work.

Although, since multisite’s have the cache/minify folder segmented into subsite ID folders, would it make sense on mutlisites to not have the constantly changing .htaccess file directly in the minify folder, but place sub-site specific .htaccess files in each ID subfolder.

So a regular site’s structure is the .htaccess alongside the css and js files:

/wp-content/cache/minify/.htaccess
/wp-content/cache/minify/*files*

A multisite has the .htacess no alongside the files directly:

/wp-content/cache/minify/.htaccess
/wp-content/cache/minify/1/*files*
/wp-content/cache/minify/2/*files*
/wp-content/cache/minify/3/*files*

causing the .htaccess to constantly be rewritten.

If it could work like this instead:

/wp-content/cache/minify/1/.htaccess
/wp-content/cache/minify/1/*files*
/wp-content/cache/minify/2/.htaccess
/wp-content/cache/minify/2/*files*
/wp-content/cache/minify/3/.htaccess
/wp-content/cache/minify/3/*files*

…with no .htaccess at the minify root, you could have static htaccess files with the correct RewriteBase with no need for constantly updating 1 htaccess file and the .htaccess files would be directly alongside the css and js files again just like on a regular site.

Or if needed maybe it could split up and have the .htaccess in cache/minify read:

# BEGIN W3TC Minify cache
FileETag MTime Size
<IfModule mod_mime.c>
    AddType text/css .css_br
    AddEncoding br .css_br
    AddType application/x-javascript .js_br
    AddEncoding br .js_br
</IfModule>
<IfModule mod_deflate.c>
    <IfModule mod_setenvif.c>
        SetEnvIfNoCase Request_URI \.css_br$ no-brotli
        SetEnvIfNoCase Request_URI \.js_br$ no-brotli
    </IfModule>
</IfModule>
<IfModule mod_expires.c>
    ExpiresActive On
    ExpiresByType text/css A31536000
    ExpiresByType application/x-javascript A31536000
</IfModule>
<IfModule mod_headers.c>
    Header set X-Powered-By "W3 Total Cache/2.4.1"
    Header set Vary "Accept-Encoding"
    Header set Pragma "public"
    Header append Cache-Control "public"
</IfModule>
# END W3TC Minify cache

…and then have the .htaccess files in the ID number subfolders like cache/minify/1/ read:

# BEGIN W3TC Minify core
<IfModule mod_rewrite.c>
    RewriteEngine On
    RewriteBase /site1/wp-content/cache/minify/
    RewriteCond %{HTTP:Accept-Encoding} br
    RewriteRule .* - [E=APPEND_EXT:_br]
    RewriteCond %{REQUEST_FILENAME}%{ENV:APPEND_EXT} -f
    RewriteRule (.*) $1%{ENV:APPEND_EXT} [L]
    RewriteRule ^(.+\.(css|js))$ /index.php [L]
</IfModule>
# END W3TC Minify core

…since the RewriteBase in this block is the only thing that changes at least for my configuration.

If this moving would work, it would eliminate the need for rewriting the htaccess file all the time and remove the chance of corruption.

Hello @endymion00

Thank you for reaching out and I am happy to help!

If possible, please share the URL of the website. We need to replicate this and figure out what is happening so we need to run some tests.

Is there a specific moment when the website breaks that you can share?

Thanks!

Keeping the client’s site private. A link wouldn’t make any difference anyway since I don’t leave the site broken.

You can recreate the htaccess file changing situation by just creating your own multisite with subfolders for the sub-sites since the htaccess updating appears to occur on different multisites I have access to, so that would seem standard procedure at the moment that should be easily replicable. Just clear the cache and then browse the sub-sites while watching the wp-content/cache/minify/.htaccess file change for each sub-site that is visited.

The corruption at the end of the htaccess file isn’t easy to replicate unless you manually add it to the end just to see it’s effect. I’m presuming the corruption happens from traffic because there had been a nearby load spike across the sub-sites and it would make sense when each sub-site is hit, and it updates the htaccess, that their may be some issue when simultaneous / rapid hits cause updates.

The other multisites I have access to haven’t shown the corruption part of the issue, but they get a very small fraction of the traffic this one site does, so the updating of the htaccess file is likely just not happening rapidly enough to expose the issue.

So, best case would be a structure that avoids the need for changing the htaccess file in the first place. Going to duplicate to a test site to try some of my ideas, I’ll let you know if I find anything, but the developers should be familiar with how this works enough to see the problem.

Is there any update on this issue? We’re experiencing similar issues where the .htaccess file has multiple/duplicate/incomplete rewrite rules/conditions which breaks the minify caching completely. Deleting the file and flushing the cache resolve the issue but it keep appearing on “random” intervals.

The .htaccess will re-write whenever a new uncached page is loaded for a sub-site from what I can see since it changes the Base url. Once cached it doesn’t seem to care if the .htaccess is currently for another sub-site.

I ended up just turning off minify for now because it was not worth the random breaking of the site at times when I may not be around and ready to fix and not have the client freak out and blame it on me.

Hello @endymion00

Thank you for your patience.

Just to be able to replicate this, are you using the single configuration for all sites or are you using the individual settings for each site?

Thanks!

I actually tried both configurations with the same problem.

I was using individual configurations, but always had issues with the Purge All Caches not working, which then required me to use the Purge Modules –> Minify, Browser and Page cache options separately for each subsite which is rather tedious. So with the htaccess file problem as well I decided to finally switch over to the single configuration to see if it helped with either problem.

I reset the plugin settings and then implemented the single configuration. It did solve my Purge All Caches problem, but the htaccess problem was still as it was before. So you should be able to test with either since it appears to be shared code/logic used in both situations.

We’re having a very similar problem. We have CSS minification active, with combine and minify and we are using a single configuration across all multisites.

The website gives an error 500 when trying to access the minified file at “/wp-content/cache/minify/0/343d0.default.include.a6987e.css”, and we also had a wrongly appended htaccess file.
We apparently solved our issue by disabling the option “Rewrite URL structure”.

One thing that could be a coincidence is that while the htaccess file was wrong the plugin created a folder in the “/wp-content/cache/minify/” with the name “343d0” and filename of “default.include.css.id” with the following inside it:
s:6:"554741";

• This reply was modified 1 year, 1 month ago by goncalomarquesgs.

@vmarko is there any update on this issue?
Multiple user report a problem and we have multiple sites with this issue.
@endymion00 have given clear instructions on how the issues can be replicated.

There is still no fix for this and it is still happening to websites of our clients. Here another example of a multisite installation where the .htaccess file in the minify folder was faulty again:

# BEGIN W3TC Minify cache
# END W3TC Minify cache
# BEGIN W3TC Minify core
<IfModule mod_rewrite.c>
    RewriteEngine On
    RewriteBase /wp-content/cache/minify/
    RewriteCond %{REQUEST_FILENAME} !-f
    RewriteRule ^(.+\.(css|js))$ /index.php [L]
</IfModule>
# END W3TC Minify core
    RewriteEngine On
    RewriteBase /wp-content/cache/minify/
    RewriteCond %{REQUEST_FILENAME} !-f
    RewriteRule ^(.+\.(css|js))$ /index.php [L]
</IfModule>
# END W3TC Minify core

This is the file after regenerating it (deleting and clear caches):

# BEGIN W3TC Minify cache
# END W3TC Minify cache
# BEGIN W3TC Minify core
<IfModule mod_rewrite.c>
    RewriteEngine On
    RewriteBase /wp-content/cache/minify/
    RewriteCond %{REQUEST_FILENAME} !-f
    RewriteRule ^(.+\.(css|js))$ /index.php [L]
</IfModule>
# END W3TC Minify core

If you don’t want to risk your site going down, I suggest for now just turning off minification. The .htaccess file will no longer constantly rewrite itself. Of course this means no reduced css / js files in the interim. but it’s much better that random site problems disrupting the client’s business.

@endymion00 thanks for the advice, most certainly not ideal but unfortunately necessary, a real shame because this plug-in most often gives great results.

Any progress update? Still running the multi site with Minify disabled to avoid the issue on a busy site. It’s fine if something isn’t ready yet, but always good to know if a better method is being worked on rather than an .htaccess file constantly being rewritten.