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

[matt]

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 #660

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

[till]

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]

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.

[willemijns]

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 ;)

[willemijns]

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 ;)

[vipsoft]

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.

[matt]

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]

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.

[matt]

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.

[vipsoft]

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