Skip to main content
Topic: Caching issue? (1.1) (Read 3252 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

Caching issue? (1.1)

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
Facta, non verba.

Re: Caching issue? (1.1)

Reply #1

Kyboard no batteries, virtual kb.
Tomorrow...
Bugs creator.
Features destroyer.
Template killer.

Re: Caching issue? (1.1)

Reply #2

Cools! :D
Facta, non verba.

Re: Caching issue? (1.1)

Reply #3

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
Bugs creator.
Features destroyer.
Template killer.

Re: Caching issue? (1.1)

Reply #4

YAY NICE IT WORKS NOW! :D
Facta, non verba.

Re: Caching issue? (1.1)

Reply #5

I would just delete all of them as I prefer them to be regenerated rather than using the older ones.

Re: Caching issue? (1.1)

Reply #6

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
Facta, non verba.

Re: Caching issue? (1.1)

Reply #7

It works for me. I even replaced cached css back to css folder and change fixed url in css to '..'.

Re: Caching issue? (1.1)

Reply #8

Ooh did you enable this:
"Minify Javascript and CSS files"
Facta, non verba.

Re: Caching issue? (1.1)

Reply #9

Quote from: ahrasis – I would just delete all of them as I prefer them to be regenerated rather than using the older ones.
The point is that the regeration is broken. ;)
Bugs creator.
Features destroyer.
Template killer.

Re: Caching issue? (1.1)

Reply #10

Quote from: niloc – Ooh did you enable this:
"Minify Javascript and CSS files"
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.

Re: Caching issue? (1.1)

Reply #11

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.
Bugs creator.
Features destroyer.
Template killer.

Re: Caching issue? (1.1)

Reply #12

Quote from: emanuele – Full specifications of the problem:
1) use file-based cache
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

 

Re: Caching issue? (1.1)

Reply #13

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. ;)
Bugs creator.
Features destroyer.
Template killer.