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

Updating to a new Piwik version should automatically force the browser to update the cache for JS/CSS files #712

Closed
mattab opened this issue May 13, 2009 · 9 comments
Labels
Bug For errors / faults / flaws / inconsistencies etc. Major Indicates the severity or impact or benefit of an issue is much higher than normal but not critical.
Milestone

Comments

@mattab
Copy link
Member

mattab commented May 13, 2009

This issue has always existed in Piwik, after each upgrade where some JS or CSS were updated, some users would experience issues as their browser would still use the old cached JS or CSS and this would break some bits of Piwik. This became a more important issue with 0.2.35 where a lot of the JS files were updated and broke the dashboard for most users; to fix it they had to find out the issue (eg. looking at the forum) and delete their browser cache, which is not a good user experience.

There are several ways we could fix this:

  • Quick fix: route all JS/CSS inclusions through a common mechanism (smarty function or similar) and automatically add a parameter jquery.js?piwik=0.2.35 to force the browser to refresh all the cache after each upgrade
  • Ideal solution: a better solution would be to route all JS/CSS inclusions requests through a simple merge + minify script which would: make Piwik faster (only one http request for all inclusions, and return smaller minified content) and fix this issue (we would add the &piwik=0.2.35 parameter to this merge script). See solution described in Make Piwik UI faster: merge all Javascript and CSS files together, minify, cache the merged files on disk #660

If anybody wants to help please shout! This feature is def a good one for a developer new to the project.

@till
Copy link

till commented May 15, 2009

Use a rewrite rule.

E.g.:

jquery.js?piwik=0.2.35

... as you said, this fixes the issues for all users. However, this also prevents browsers from caching the .js file ever.

Pushing it through a PHP script doesn't really do any good either. Point taken, it may fix issues in the short run, in the long run, you need PHP to execute static files.

What you want is something like this:
/js/0.2.35/jquery.js

A matching rewrite rule:

RewriteEngine On
RewriteBase /js
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule ^(.*)/(.*)\.js$ $2.js?piwik=$1 [L]

This makes sure that if the file (or directory) exists, no redirect is done. And it'll only catch /js.

@till
Copy link

till commented May 15, 2009

For nginx, I think this should do:

location /js/ {
    if (!-f $request_filename) {
        rewrite ^(/js/)(.*)/(.*)\.js  $2.js?id=$1 last;
    }
}

(No guarantees, though. Haven't had a chance to try it.

@anonymous-matomo-user
Copy link

another easy thing to do, reload all .js with a global include
"name_of_js.js?do=nothing" which only reload js and do nothing...

no guarantee too.. i begin in php ;)

@anonymous-matomo-user
Copy link

CTRL+F5 works well too ;)

"Welcome to the new version of piwik, to be sure to have latest widget enhancements, please refresh your browser thanks to CTRL+F5"

very efficient method ;)

@robocoder
Copy link
Contributor

Thanks for all the suggestions. We will use something in the URL as a cache buster. The url rewriting rules are web server specific. I try to avoid .htaccess files (because of the performance hit), but not everyone has access to their httpd.conf.

@mattab
Copy link
Member Author

mattab commented May 16, 2009

the browser will correctly cache $NAME.js?version=$VERSION so both propositions in the ticket are valid and efficient (cache would just be refreshed at each update which is the desired effect).

@till
Copy link

till commented May 16, 2009

If in doubt you could always make a performance wiki page that tells people the pros and cons of .htaccess. I guess if it's really an issue, people will have access to the httpd.conf (or nginx.conf for that matter).

I think this would be most def. better than piping it through a PHP script.

I guess the question is if the piwik frontend needs to make use of caching per se. After all, the intense part is the collection and the crunching.

@mattab
Copy link
Member Author

mattab commented May 16, 2009

what are the issues of "piping" it through a php script considering it's cached and should only be executed once?

also, .htaccess is not a solution as it's server dependant and this sort of functionnality should be handled at the application level.

@robocoder
Copy link
Contributor

(In [1152]) quick fixes #712 - add Smarty output filter to add cache busting string
to external CSS stylesheets and JavaScript script files

@mattab mattab added this to the Piwik 0.4 milestone Jul 8, 2014
This issue was closed.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Bug For errors / faults / flaws / inconsistencies etc. Major Indicates the severity or impact or benefit of an issue is much higher than normal but not critical.
Projects
None yet
Development

No branches or pull requests

4 participants