Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Changes in style.css not updating due to the caching of asset files #126

Open
josevarghese opened this issue Jun 30, 2020 · 5 comments
Open
Labels
enhancement New feature or improvement high

Comments

@josevarghese
Copy link
Contributor

Like mentioned in detail by a user over WordPress.org forum the styles are not getting updated over the front end. It's due to the current caching strategy which caches styles, if the version of theme is not get updated by the developer.

Solution:

A version update option over the settings panel will help the users to increment the value of service worker file name and manifest. This tells the browsers to update the device service worker and manifest file, if a change occurs over the style.css even without incrementing the theme version.

Note: Some users won't like to increment their respective themes version, as it may get confused if a new update is available and most of them are using premium themes.

@arunbasillal
Copy link
Contributor

The reason why the versioning exist is to bust browser cache. Let me explain.

CSS files usually have a long expiry time, usually a year. This means, once the file is loaded on the browser, it will be saved in the browser cache for one year. So if the user does not change the version number, end users will not see the change until they clear the browser cache (Control + F5 will do it).

User said:

but from a customer point of view and someone who is not familiar with clearing cache (imagine an old person using the website) if we change something about css it won’t load the new setting for them and it will read it only from the cache on users device

Since most users , won't use Control +F5 on their daily browsing, this will be the case even without SuperPWA. Yes, with SuperPWA, now they have to clear both caches.

The right solution here is to educate the user on why versioning exist. The user might not be aware of it.

@josevarghese
Copy link
Contributor Author

Educating user even though have a limitations in different scenarios. As for premium themes, I think this versioning won't be a great a solution. For eg, if the theme version is 2.1, and if the user increment it to 2.1.1 after some CSS changes. And once after that over about a week of time, if premium theme developer provided a new version with 2.1.1 as a patch with some changes. It would be hectic job for SuperPWA plugin user to find why the recent won't get updated. So the solution is to provide an option to increase the version of SuperPWA manifest and service worker. This also helps to get update the SW and manifest if any changes occurs over both than clearing the browsing data or cache.

@odedta
Copy link

odedta commented Jul 4, 2020

@arunbasillal I don't think educating the user is the right way to go about it, take my case for example:
I use this plugin to create the appearance of an app, now I updated the CSS file for the website, are you saying I have to wait 1 year until the user will see that change? if that's the case the plugin is useless...

Maybe i'm not understanding you well, anyway, I've been experiencing a lot of cache related issues while developing and using SuperPWA and i'm worried that once I launch, users will not be able to see changes. :/

@armorasha
Copy link

Please add "Version" update option to manifest, so that the developer can change manifest versions to test new settings (like updating PWA icons, changing standalone to fullscreen) on their mobile devices.

@sinxwal
Copy link

sinxwal commented Sep 21, 2020

The best solution is to add extra vesioning number inside service-worker settings. It can be optional, but advanced theme developers will have an ability to increment it and force cached assets to update.

@supernation supernation added enhancement New feature or improvement high labels Nov 18, 2020
@supernation supernation added this to the 2.1.4 milestone Nov 18, 2020
@Sanjeevsetu Sanjeevsetu removed this from the Possible Milestone milestone Aug 23, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or improvement high
Projects
None yet
Development

No branches or pull requests

7 participants