Develop the device caching & settings form

Hello gMaximus,

I have conducted tests on my logged-in site and noted the following issues:

The software's caching feature is functioning correctly as a cache layer for non-authenticated users. However, it is caching everything, including admin forms, content creation forms, and updates. Consequently, changes made to content are not being reflected.

The login feature is functioning properly. However, the logout process still encounters the problem described in issue 3446012.

Perhaps a solution could involve incorporating an option within the module to disable the SW caching features, similar to the quicklink module.

Thank you!.

Hey @Freddy Rodriguez,

I've just committed device caching settings to this fork. Perhaps, this will resolve the issues you've reported?

I'm not experiencing the logout issue. When I logout, it redirects to the home page (logged in cached page), when the device cache clears, it reloads the page. I don't like this solution! It's looks like it jumps. I'll look into other options. Do you have any ideas?

If I logout and open a new browser window, I get the logged out page.

The service worker remaining active is expected. Am I missing something on that note?

After updating the code, flush the caches, logout and then unregister the service worker via the console.

That's what I've been doing during development

I see where the problem lies on my side, and it's because I'm using the SSO from the o365 module. The logout process is different in this case because the final redirect leads to an Office screen that asks the user to close all windows and even the browser. Therefore, it doesn't perform the redirect and reload you implemented to clear the Service Worker (SW) cache.

Given this, what if there is a check during the initial site request looking for an active session or the presence of a Drupal session cookie? If either of these conditions is true, the SW cache can be skipped; otherwise, load the SW cache.

In this scenario, there's no need for any redirects after login.

Something like this:

self.addEventListener('fetch', function(event) {
  event.respondWith(
    fetch(event.request)
      .then(function(response) {
        // Check if the response includes the Drupal session cookie
        if (response.headers.has('Set-Cookie') && response.headers.get('Set-Cookie').includes('DRUPAL_SESSION')) {
          // Skip caching for requests with active Drupal session
          return response;
        } else {
          // Cache the response using the Service Worker
          return caches.open('your-cache-name').then(function(cache) {
            cache.put(event.request, response.clone());
            return response;
          });
        }
      })
      .catch(function(error) {
        console.error('Fetch error:', error);
      })
  );
});

So a few things. Currently this reacts on the click of any link pointing to /user/logout. When those links gets clicked, we tell the service worker to flush the device cache, then it reloads the current page. I didn't think about people who use an alternative method that doesn't use that link. So I'll have to think of another route to trigger the flushing of device cache.

In your setup, would hook_user_logout be fired? Perhaps that might be a route to explore. I'm not sure if it is viable. I had wondered whether that would be a better route. However, at that point it was working for me and it was late.

Currently the service worker caches all pages for all users on their devices, excluding URL's specified on the new "Device Caching" settings tab. Where you can also turn off device caching altogether. We'd need to expand on your idea so that we can activate the cache by role perhaps. Then it would cater for everyone.

I need to supply defaults to the excluded URL's field. I ran out of time last night. These are the ones I have in mind:

• /admin/*
• /node/*/edit
• /node/*/delete
• /system/ajax
• /views/ajax

Are there any others that I should add in your view? I think they're the ones applicable to everyone.

What we do have now, in code, is a json endpoint where we can output any data from Drupal. The service worker then fetches that json to use in the service worker. So cool things are now possible.

Thanks, gMaximus.

The caching options seem to be the way to go, and yes, I will try using the hook_user_logout.

In the URL fields to exclude: /user/*

Perhaps there's a possibility to add some custom URLs, in my case: o365/callback.

I'm using the code from this fork: https://git.drupalcode.org/issue/advanced_pwa-3446692, but I can't find the "Device Caching" settings tab - image attached.

This kind of work inspires people to keep improving Drupal.

Thanks for your great work!

It is in this module where hook_user_logout will need to be implemented. Currently, it is a JS file loaded on all pages. See js/logout.js. That JS then tells the service worker to flush device cache and then reload the page. It reacts on links being clicked that point at /user/logout. I wonder if I could attach that logout.js to the hook somehow. Hmm...

I've just done another commit that adds cache by role settings.

The code you want can be found here: https://git.drupalcode.org/issue/advanced_pwa-3446692/-/tree/3446692-dev.... To ensure you have the right code, run "git log" inside this modules directory. The last commit at this point should be "Added device caching by role setting."

I appreciate you testing things for me. This is what I love about the opensource eco-system. We're working with each other for a common goal without a financial exchange. Where else does that happen? lol

I've just done another commit to add defaults to the exclude urls field. The last commit message is "Added default setting for excluded urls's."

Separately I've just released https://www.drupal.org/project/advanced_pwa_rules → . There's a video of using it on there.

The defaults didn't work correctly. Just done another commit. Message - Fixed defaults for excluded urls.

GMaximus, I have some good news regarding the latest code update. Everything is now working fine, including the cache for authenticated users, which appears to be functioning correctly.

The only issue I'm encountering at the moment is with the logout functionality.

To recap:

#8: "When I logout, it redirects to the home page (logged in cached page), when the device cache clears, it reloads the page"

Response: During my testing, the redirection to the home page after logout is occurring, but the page isn't reloading. Perhaps clearing all the SW cache associated with the home page during logout could resolve this?

#13: "Currently this reacts on the click of any link pointing to /user/logout. When those links gets clicked, we tell the service worker to flush the device cache, then it reloads the current page. I didn't think about people who use an alternative method that doesn't use that link. So I'll have to think of another route to trigger the flushing of device cache."

Response: In the case of o365, the module utilizes /user/logout and employs a Symfony event. Here are the implementation details: LogoutController.php.

Another noteworthy scenario occurs when the site employs the autologout module. In this case, logout management is handled here: AutologoutManager.php

Both of those look like they wouldn't break hook_user_logout implementations. I'll work on this now and see what I can come up with. That hook feels right. I might be wrong though, we'll find out soon enough. I feel like we're close to having this production ready.

I haven't stopped working on this. I'm stuck though since my last comment. If you know how to code, an answer here would be good: https://drupal.stackexchange.com/questions/320003/why-isnt-my-eventsubsc...

I think the JS will work and we'll be laughing. That is ready hopefully. I'm just stuck on firing the event.

The idea is that the subscriberevent will attach the library when a user logs out. That library has one JS file, it sends a message to the service worker that the user has logged out. The service worker listens for that message and then clears the device cache.

I really need to do some cash work but feel so close.

Hello gMaximus, I have been exploring some alternatives suggested by the gpt. This is the conversation:

https://chatgpt.com/share/b49f7190-7087-4098-89ec-0a1de25e2da6

Well, I'm excited to share that I think we should be good to go. Well I hope so, because I can't put in any more time.

Pls test the latest commit and let me know if it works for you.

p.s Chat GPT is my new best friend thanks to you. It's not perfect though. Well, not yet.

If you preserve the logs in the console, you'll see logs relating to caching. Prior to merging, these will be removed. They're useful for testing purposes though.

@Freddy Rodriguez. Did it work you in your setup?