So when you enable this: "Minify Javascript and CSS files"
Followed by set the caching to "Level 1 Caching"
Then you Empty the Cache "Run Task Now"
Then what happens is, the whole forum is loaded without CSS at all.
And when you "View Source", and click on the "bla.com/elk2/cache/hive-cf06b319f3add4ba93d874b2fa2a083cab0fa14a.css?673e6c39", it gives you an ERROR 403.
Any thoughts on this guys? :(
Note: Tested on a fresh new install of 1.1
Kyboard no batteries, virtual kb.
Tomorrow...
Cools! :D
When the cache is cleaned (file-based) the htaccess that "protects" the directry from external access is removed as well. But the htaccess of that directory is a bit special and this peculiar behaviour was not ported to the function that generates the new htaccess that blocks everything.
So it's actually a bug. And I feel it affects 1.0 as well.
If you need to restore the css, you can just replace the content of the htaccess with:
https://github.com/elkarte/Elkarte/blob/development/cache/.htaccess
YAY NICE IT WORKS NOW! :D
I would just delete all of them as I prefer them to be regenerated rather than using the older ones.
But the thing is, deleting them all doesn't work. It will somehow screw everything up. But the fix above helps to solve the problem already :D
It works for me. I even replaced cached css back to css folder and change fixed url in css to '..'.
Ooh did you enable this:
"Minify Javascript and CSS files"
The point is that the regeration is broken. ;)
I did. I am the fan of caching. ;)
If level 1 caching caused that, why htaccess is being blamed?
From my experiment, that was caused by my caching software (i.e. memcached, xcache or opcache). From the experiment, xcache cannot work well with opcache which is the default with php 5.5 and above.
In my case, what I did was, I disabled it totally and I followed the instructions to exclude cache folder from opcache.
I think one should look for the real cause of error 403 that was being reported. To keep replacing htaccess contents could be a little bit of too much?
By the way, when I said I deleted everything, it means js and css files, not index.php nor .htaccess files.
Full specifications of the problem:
1) use file-based cache
2) enable the minification of css and js
3) set cache to any level
4) use the maintenance task "Empty the cache".
=> expected: the cache is emptied and everything else works the same,
=> observed: index.php and .htaccess are removed
When the two files are removed, the security checks kick in and re-add a new .htaccess file, but the content of this.htaccess is different from the original one and blocks the access to any resource of the directory.
Sorry but I am not a mind reader and I don't see that in the OP but I can see that in your reply though. Other than that I better :-X
Don't worry, I didn't imply you should.
It just happened that when I read the description I realized what the problem was and described it (probably not enough in details), seeing that you were looking at the wrong type of cache I stepped in and wrote down the steps to reproduce the issue (that is usually the most important thing of a bug report :)).
It was not mean to close your mouth, but it was a way to avoid you to dig into an issue from the wrong perspective and waste quite a bit of time. ;)
Fixed in https://github.com/elkarte/Elkarte/commit/81e84ed2fca2d2e3436b711964f8a4c85534e9c7