Can't flush cache about cachelite HOT 14 CLOSED

Have you tried changing file permissions on the cache folder? is this a local build? or live server.

from cachelite.

@nathanhornby are you running the latest version ?

from cachelite.

Definitely latest version - permissions, didn't think of that (as it's able to write), could well be a factor. Does using that URL parameter also bypass the cache (as well as clearing it), thereby explaining why it appears to work when using it?

This is on a live build by the way, I pulled some minor code changes that weren't being reflected after thinking I'd flushed the cache.

On 12 Jan 2015, at 15:45, Nicolas Brassard [email protected] wrote:

@nathanhornby are you running the latest version ?

—
Reply to this email directly or view it on GitHub.

from cachelite.

Definitely latest version - permissions, didn't think of that

Sometimes you can write but can't delete...

Does using that URL parameter also bypass the cache (as well as clearing it), thereby explaining why it appears to work when using it?

It should not (https://github.com/symphonists/cachelite/blob/master/extension.driver.php#L259-L268) If it is, it's a bug...

Can you check for error in Symphony log ? (/symphony/system/log/)

And I am pretty sure that I am asking this for nothing, but you are logged in Symphony's backend right ?

from cachelite.

And I am pretty sure that I am asking this for nothing, but you are logged in Symphony's backend right ?

Now you've got me thinking. This was while testing some changes to the markup intended for mobile, and although I know I ran the flush on desktop at least once (where I would have been logged in), I'm not sure if that was before noticing the issue - so I might have had the frustration on a device I wasn't logged into.

If that is the issue, then it looks like the URL parameter bypasses the cache if you're not logged in. I don't know if that's really an issue though.

Edit: No errors relating to that in the logs by the way.

from cachelite.

then it looks like the URL parameter bypasses the cache if you're not logged in

The cache is url based, including any query string: so adding ?flush should give you a different version.

But the ?flush query-string must only work when the user in logged in Symphony.

BTW: https://github.com/DeuxHuitHuit/cache_management may help you clearing all the cache (instead of going with FTP or SSH...)

from cachelite.

I might try to add some output in the log to be able to debug this a little bit easier..

@brendo what do you think about this idea ?

from cachelite.

Ah of course, hadn't thought of it that way.

On 12 Jan 2015, at 18:40, Nicolas Brassard [email protected] wrote:

then it looks like the URL parameter bypasses the cache if you're not logged in

The cache is url based, including any query string: so adding ?flush should give you a different version.

But the ?flush query-string must only work when the user in logged in Symphony.

BTW: https://github.com/DeuxHuitHuit/cache_management may help you clearing all the cache (instead of going with FTP or SSH...)

—
Reply to this email directly or view it on GitHub.

from cachelite.

@nathanhornby I've rested on a live site and everything seems to work... flush does what it's supposed to do.

from cachelite.

@nathanhornby Which version of Symphony are you running ?

from cachelite.

It's 2.5.something - I have a feeling it might just be the logged in thing I'm afraid. I'll confirm tomorrow.

On 12 Jan 2015, at 21:11, Nicolas Brassard [email protected] wrote:

@nathanhornby Which version of Symphony are you running ?

—
Reply to this email directly or view it on GitHub.

from cachelite.

Well I've tested it on a live site and everything seems to work. I'll be sending a PR with the log soon.

from cachelite.

Just done a quick test and it seemed to work as expected when logged in. Sorry to have wasted your time @nitriques - seems I must have been logged out on the device I ran the URL parameter on. What tricked me was that this appeared to work, but as pointed out this would have been because the URL parameter would have created a new page to be cached, so the content would be different when using that parameter.

from cachelite.

No problems Nathan! Those kind of things happens to me all the time.

I'll close the issue for now. Please re-open if anything gets weird again!

from cachelite.