@mattab opened this issue on May 13th 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 #660

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

@till commented on May 15th 2009

Use a rewrite rule.



... 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 commented on May 15th 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-piwik-user commented on May 15th 2009

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-piwik-user commented on May 15th 2009

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 commented on May 15th 2009

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 commented on May 16th 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 commented on May 16th 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 thehttpd.conf (ornginx.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 commented on May 16th 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 commented on May 28th 2009

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

This issue was closed on August 1st 2009
Powered by GitHub Issue Mirror