Problem/Motivation

At present the device caching has been commented it out.

Although it did work in terms of saving cached pages to devices, it became stale as soon as a user signs in or out. So to keep what was working useful, the caching was commented out.

Furthermore, at present there are no settings for configuring anything related to the device caching, so that it can be tailored to individual use cases.

After uninstalling the module, client-side service workers were left in tact. This resulted in returning visitors seeing device cached content.

Proposed resolution

1) Clear cache on login - Completed.
2) Clear device cache on logout - Completed.
3) Add settings form for device caching. It should allow the following
- Turn on/off - Completed.
- Ability to exclude URL's from device caching - Completed.
4) Create a sub-module to delete client side service workers. If we uninstall this module, all code is removed. Making it impossible to ensure that returning users received content from the server and not the service worker. By creating a sub-module that we can turn on after uninstalling the module, we can load a little js to look for and delete our service worker. - Completed.
5) Develop setting to turn on device caching by role. - Completed.

CommentFileSizeAuthor
#14 caching tab.png134.95 KBfreddy rodriguez
#7 Settings.pdf211.37 KBfreddy rodriguez
advanced_pwa-improved_device_caching-3446012.patch15.05 KBgmaximus

Issue fork advanced_pwa-3446692

Command icon Show commands

Start within a Git clone of the project using the version control instructions.

Or, if you do not have SSH keys set up on git.drupalcode.org:

About issue forks

Comments

gMaximus created an issue. See original summary.

gmaximus’s picture

gmaximus commented
Related issues: +#3446012: Logout: Cookies and service worker
gmaximus’s picture

gmaximus commented
Title: Develop the device caching within the service worker » Develop the device caching & settings form
gmaximus’s picture

gmaximus commented
Issue summary: View changes
gmaximus’s picture

gmaximus commented
Issue summary: View changes
gmaximus’s picture

gmaximus commented
Related issues: -#3446012: Logout: Cookies and service worker
freddy rodriguez’s picture

freddy rodriguez
Location Bogotá
commented
Related issues: +#3446012: Logout: Cookies and service worker
StatusFileSize
new Settings.pdf211.37 KB

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!.

gmaximus’s picture

gmaximus commented
Issue summary: View changes

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.

gmaximus’s picture

gmaximus commented

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

gmaximus’s picture

gmaximus commented

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

That's what I've been doing during development

freddy rodriguez’s picture

freddy rodriguez
Location Bogotá
commented

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 cache.

Given this, what if the Service Worker checks for the presence of a Drupal session cookie on every request? If that is true, the SW cache can be skipped; otherwise, load the SW cache.

Would this solution introduce too much overhead?

freddy rodriguez’s picture

freddy rodriguez
Location Bogotá
commented

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);
      })
  );
});
gmaximus’s picture

gmaximus commented

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.

freddy rodriguez’s picture

freddy rodriguez
Location Bogotá
commented
StatusFileSize
new caching tab.png134.95 KB

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!

gmaximus’s picture

gmaximus commented

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

gmaximus’s picture

gmaximus commented
Issue summary: View changes
gmaximus’s picture

gmaximus commented

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.

gmaximus’s picture

gmaximus commented

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

freddy rodriguez’s picture

freddy rodriguez
Location Bogotá
commented

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 working 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

gmaximus’s picture

gmaximus commented

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.

gmaximus’s picture

gmaximus commented

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.

gmaximus’s picture

gmaximus commented
Issue summary: View changes
freddy rodriguez’s picture

freddy rodriguez
Location Bogotá
commented

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

gmaximus’s picture

gmaximus commented

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.

gmaximus’s picture

gmaximus commented

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.

gmaximus’s picture

gmaximus commented
Issue summary: View changes
gmaximus’s picture

gmaximus commented
Status: Active » Needs review

gMaximus opened merge request !8

  • gMaximus committed 0aad0348 on 8.x-1.x 
    Issue #3446692 by gMaximus, Freddy Rodriguez: Develop the device caching...
gmaximus’s picture

gmaximus commented
Status: Needs review » Fixed
freddy rodriguez’s picture

freddy rodriguez
Location Bogotá
commented
gmaximus’s picture

gmaximus commented

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

gmaximus’s picture

gmaximus commented
Status: Fixed » Closed (fixed)
gmaximus’s picture

gmaximus commented