Disable cache for logged in users

Kirby 3 Suggestionsđź’ˇ
1

Hello guys,

In Kirby 2 i could disable the cache for logged in user with the following code

c::set('cache', isset($_SESSION['kirby_auth_username'])?false:true);

What is the right way to do this in K3?

1 Like
2

There is an issue in the ideas repro:

[Cms] Don’t cache requests of logged-in users #40

I don’t know, if it is the same issue.

3

This problem that you describe in the issue exactly where i struggle with, hope it will be solved soon.

1 Like
4

I want to turn off the if the cache if the cookie kirby_session exist, isset is not the right way. What would work?

  'cache.pages' => [
    'active' => isset(Cookie::exist('kirby_session'))?false:true,
    'ignore' => array('error', 'contact'), 
    ],
5

There are some issues here:

  • the method is called exists not exist, i.e. with a s at the end
  • you can’t use isset(), so Cookie::exists('kirby_session') ?? false would be enough
  • but, it doesn’t help with what you want to achieve, because the session is not only created when the user is logged in.
6

unless you have some other frontend logic getting kirby()->user()might do the trick. problem is that you can not do that in the config and using a closure is not supported (yet). but that could be done as easy as for the ignore option. you could file an idea issue for that.

1 Like
7

This has long been a personal itch of mine. Based on a quick test, it appears that this mostly works:

'cache' => [
  'pages' => [
    'active' => Cookie::exists('loginsession') ? false : true
  ]
],

…though, as pointed out above, it is not 100% accurate:

So, as far as I understand and appear to see from my tests, this solution works to not use the cache when a user is logged in (this is my use case, I just don’t want pages rendered with admin links to end up in the cache), though it indeed does not reliably use the cache for all users who are not logged in (as for some reason that cookie might be set; all I can think of would be users who had been logged in before?). Occasionally, an external user might not see the cache copy but have it rendered live.

If that is the case, I personally could live with this workaround for now - but am I overlooking something important?

1 Like
8

To answer my own question: yes, I overlooked something important - using my hack presented above, the pages cache does not get emptied when updating content in the panel (likely, because the Panel checks whether caching is active, which it appears to be not, as the backend user has that cookie present).

A workaround is to use custom hooks to replicate the behaviour (empty pages cache on content updates). Not a pretty solution, but based on my tinkering this seems to be the only way to enable caching “for the masses” while presenting logged-in users with pages rendered on the fly.

9

I summarized the results of my experimentation to the ideas issue on Github: https://github.com/getkirby/ideas/issues/40#issuecomment-611995031

In short: extending the active option to support Closures (as suggested by @bnomei above) is easy, as would - if desired - adding a separate setting for this particular use case. With the $page->isCacheable() function returning different values between logged-in and public users, there however seems to be at least one issue with emptying the page cache during edits.