[de] Problem with Cachebuster plugin - reload required to make it work


Problem en:

The cachebuster plugin generates the right filename with token, but the page needs to be reloaded to see any changes.


Ich habe eine Kirby-Seite am laufen die ich gerne mit dem Cachebuster-Plugin betreiben würde.

Im Prinzip funktioniert das Plugin auch, siehe Screenshots:

Doch immer wenn ich eine CSS-Änderung auf den Server lade und die Seite in einem neuen Tab öffne muss ich erst auf Reload drücken damit die Änderungen sichtbar werden.
Das ist doch nicht der Sinn, oder?

Hat jemand ähnliche Erfahrungen gemacht und kann mir vielleicht helfen?

Hier noch die .htaccess

# Kirby .htaccess
# rewrite rules
<IfModule mod_rewrite.c>

# enable awesome urls. i.e.:
# http://yourdomain.com/about-us/team
RewriteEngine on

# make sure to set the RewriteBase correctly
# if you are running the site in a subfolder.
# Otherwise links or the entire site will break.
#
# If your homepage is http://yourdomain.com/mysite
# Set the RewriteBase to:
#
# RewriteBase /mysite
RewriteCond %{REQUEST_FILENAME} !-f
RewriteRule ^(.+)\.(\d+)\.(js|css)$ $1.$3 [L]

# block text files in the content folder from being accessed directly
RewriteRule ^content/(.*)\.(txt|md|mdown)$ index.php [L]

# block all files in the site folder from being accessed directly
# except for requests to plugin assets files
#RewriteRule ^assets/plugins/([a-zA-Z0-9\.\-_%=]+)/(.*)$ site/plugins/$1/assets/$2 [L,N]
#RewriteCond $1 !^plugins/[a-zA-Z0-9\.\-_%=]+/assets/.*
RewriteRule ^site/(.*) index.php [L]

# block all files in the kirby folder from being accessed directly
RewriteRule ^kirby/(.*) index.php [L]

# make panel links work
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule ^panel/(.*) panel/index.php [L]

# make site links work
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule ^(.*) index.php [L]

</IfModule>

# Additional recommended values
# Remove comments for those you want to use.
#
# AddDefaultCharset UTF-8
#
# php_flag short_open_tag on

## EXPIRES CACHING ##
<IfModule mod_expires.c>
ExpiresActive On
ExpiresByType image/jpg "access 1 year"
ExpiresByType image/jpeg "access 1 year"
ExpiresByType image/gif "access 1 year"
ExpiresByType image/png "access 1 year"
ExpiresByType text/css "access 1 month"
ExpiresByType text/html "access 1 month"
ExpiresByType application/pdf "access 1 month"
ExpiresByType text/x-javascript "access 1 month"
ExpiresByType application/x-shockwave-flash "access 1 month"
ExpiresByType image/x-icon "access 1 year"
ExpiresDefault "access 1 month"
</IfModule>
## EXPIRES CACHING ##

Hi,

have you checked the cachebuster-token (bundle.token.js) before opening in new tab, after openining in new tab and after reload?
Are they always different?

@andalusi:

In your .htaccess you write:

This prompts the browser to check whether or not these versions are newer after one month is gone. In the meantime, they are fetched from the cache of the browser.
Typing the key<F5> instructs the browser to ignore this default setting of the web server.

So simply disable the above two lines by inserting “#” at the beginning of the line.

Good luck!

HeinerEF

Hi Svnt,
the tokens are always different when pushing changes to the server.
So, the plugin does its job pretty good :slight_smile:

Even when disabling these two lines the browser uses the cached versions until I open an private tab :frowning:

So my clients won’t see any changes until they press reload or open an private tab?
Is the the right procedure, not sure at all …

Those .htaccess settings should do nothing, it’s the whole purpose of the cachebuster plugin to enable caching of the files and then to bust the cache when changes have been made.

I tested the behaviour and could not reproduce it, the changes were visible as soon as I opened the site in a new tab.

Glad you made it!
Unfortunately, I don’t get the whole cachebuster thing to work.

The plugin is doing its job, but I have to force the browser to reload the page until I see any changes.

The .htaccess is pretty simple, see above. So what else could it be?

Have you tried in different browsers?

Chrome, Safari, Firefox – no luck at all

Did you restart your webserver after the change in the file?
Did you delete his cache, If he uses something like this?
Did you delete the Kirby cache, if you use it?

Can’t restart the webserver, because it is shared hosting.
Don’t use the kirby cache, because it won’t work with the cachebuster plugin.

Do you have a chance to test if it works with a fresh Starterkit?

I’ll give it a try …

It turns out that godaddy is the problem.
They use a very strong cache and it is not possible to change settings due to shared hosting.

I tried my best but my client wasn’t aware of that:

“If you buy cheap you buy twice”

3 Likes

Try to disable the cache in the browser. (devTools, developerToolbar,…)

Und was soll das bitte den Besuchern meines Kunden bringen, wenn ich bei mir den Cache deaktiviere?

Just disable it for development or use a local dev-environment maybe?

The web is full of goDaddy rants because of the cache.

Good luck, dude!

S.

Again: How does that help on the customer’s end?

It doesn’t. But I guess what was meant was that this is a temporary fix for development until the client has a new hosting provider.

1 Like

@texnixe @andalusi

Can we at least edit the title to an english one? …and maybe the body as well?

1 Like