Hi all, in the past we've talked about caching busting. Especially
those that try to follow SVN with lots of customers it's quite
difficult to communicate to customers that they need to force reload.
Looking at the code it's pretty easy to add a ?v=XXXX for javascript
includes, but CSS is more difficult as it's hardcoded in the
templates. Has anyone thought about doing CSS cache busting yet? What
would be the easiest way to fix? Maybe add a roundcube object after
all template css includes that can be filled by a php function?
Also, an idea that was floated around before was to include a ?
v=a.b.c.d where a.b.d is the current version (0.2.2 for instance), and
d is default 0, but can be set in config.inc.php, to allow more recent
modifications of JS/CSS. Where would we put the a.b.c ? In preferences
as well? Maybe just the whole string in preferences?
Co _______________________________________________ List info: http://lists.roundcube.net/dev/
Why not doing something like ...
<link rel="stylesheet" type="text/css" href="/common.css?v=<roundcube:var name="config:version" />" />
... in the template files?
On Wed, 3 Jun 2009 14:56:07 +0200, Cor Bosman cor@xs4all.nl wrote:
Hi all, in the past we've talked about caching busting. Especially
those that try to follow SVN with lots of customers it's quite
difficult to communicate to customers that they need to force reload.
Looking at the code it's pretty easy to add a ?v=XXXX for javascript
includes, but CSS is more difficult as it's hardcoded in the
templates. Has anyone thought about doing CSS cache busting yet? What
would be the easiest way to fix? Maybe add a roundcube object after
all template css includes that can be filled by a php function?Also, an idea that was floated around before was to include a ? v=a.b.c.d where a.b.d is the current version (0.2.2 for instance), and
d is default 0, but can be set in config.inc.php, to allow more recent
modifications of JS/CSS. Where would we put the a.b.c ? In preferences
as well? Maybe just the whole string in preferences?Co _______________________________________________ List info: http://lists.roundcube.net/dev/
List info: http://lists.roundcube.net/dev/
Roland Liebl wrote:
Why not doing something like ...
<link rel="stylesheet" type="text/css" href="/common.css?v=<roundcube:var name="config:version" />" />
... in the template files?
This will prevent caching completely.
It is better to have something like
href="/css/<roundcubeversion>/common.css"
and rewrite rules.
Best regards,
Michael _______________________________________________ List info: http://lists.roundcube.net/dev/
On Jun 3, 2009, at 3:10 PM, Roland Liebl wrote:
Why not doing something like ...
<link rel="stylesheet" type="text/css" href="/common.css? v=<roundcube:var name="config:version" />" />
... in the template files?
Of course, much easier. Forgot you could do that. So if we just create
a config
setting named version, and RC keeps that up to date as versions
progress,
people that follow SVN can just update the version to something more
specific.
Then, in PHP we need to fix include_script() in both
rcube_html_page.php and
rcube_plugin_api.php right?
Cor _______________________________________________ List info: http://lists.roundcube.net/dev/
On Jun 3, 2009, at 3:16 PM, Michael Baierl wrote:
Roland Liebl wrote:
Why not doing something like ...
<link rel="stylesheet" type="text/css" href="/common.css? v=<roundcube:var name="config:version" />" />
... in the template files?
This will prevent caching completely.
Why does that prevent caching completely? Im already doing this with
my own
plugins, and it seems to be caching just fine. This will create HTML
like:
<script type="text/javascript" src="program/js/common.js?v=0.2.2"></ script> <script type="text/javascript" src="program/js/app.js?v=0.2.2"></script>
<script type="text/javascript" src="program/js/list.js?v=0.2.2"></ script> And as long as you dont change the config:version, things remain cached right? Cor _______________________________________________ List info: http://lists.roundcube.net/dev/
Does this prevent href="/common.css?v=2590" at all or only if the version number changes f.e. to /common.css?v=2591
On Wed, 03 Jun 2009 15:16:44 +0200, Michael Baierl mail@mbaierl.com wrote:
Roland Liebl wrote:
Why not doing something like ...
<link rel="stylesheet" type="text/css"
href="/common.css?v=<roundcube:var
name="config:version" />" />
... in the template files?
This will prevent caching completely.
It is better to have something like
href="/css/<roundcubeversion>/common.css"
and rewrite rules.
Best regards,
Michael _______________________________________________ List info: http://lists.roundcube.net/dev/
List info: http://lists.roundcube.net/dev/
Why to change the classes? If you adjust the css links in the templates as suggested and you put in your ./config/main.inc.php f.e. version 20090603 it is up to you when you want to force cache busting ... So, I can't follow what you to change in the page classes. I think it is enough to patch app.js, main.inc.php.dist and the default skin.
On Wed, 3 Jun 2009 15:19:55 +0200, Cor Bosman cor@xs4all.nl wrote:
On Jun 3, 2009, at 3:10 PM, Roland Liebl wrote:
Why not doing something like ...
<link rel="stylesheet" type="text/css" href="/common.css? v=<roundcube:var name="config:version" />" />
... in the template files?
Of course, much easier. Forgot you could do that. So if we just create
a config setting named version, and RC keeps that up to date as versions
progress, people that follow SVN can just update the version to something more specific.Then, in PHP we need to fix include_script() in both
rcube_html_page.php and rcube_plugin_api.php right?Cor
List info: http://lists.roundcube.net/dev/
On Jun 3, 2009, at 3:27 PM, Roland Liebl wrote:
Why to change the classes? If you adjust the css links in the templates as suggested and you put in your ./config/main.inc.php f.e. version 20090603 it is up to you when you want to force cache busting ... So, I can't follow what you to change in the page classes. I think it is enough to patch app.js, main.inc.php.dist and the default skin.
Well, you dont just want to change CSS, you also want to change all
JS. The JS includes happen in include_script. I guess the plugin api
include doesnt need to be done, i suppose it should be up to plugin
maintainers to version their includes?
program/include/rcube_template.php: $this-
include_script('app.js');
Cor
List info: http://lists.roundcube.net/dev/
Ah ok, I see ...
On Wed, 3 Jun 2009 15:34:09 +0200, Cor Bosman cor@xs4all.nl wrote:
On Jun 3, 2009, at 3:27 PM, Roland Liebl wrote:
Why to change the classes? If you adjust the css links in the templates as suggested and you put in your ./config/main.inc.php f.e. version 20090603 it is up to you when you want to force cache busting ... So, I can't follow what you to change in the page classes. I think it is enough to patch app.js, main.inc.php.dist and the default skin.
Well, you dont just want to change CSS, you also want to change all
JS. The JS includes happen in include_script. I guess the plugin api
include doesnt need to be done, i suppose it should be up to plugin
maintainers to version their includes?program/include/rcube_template.php: $this-
include_script('app.js');
Cor
List info: http://lists.roundcube.net/dev/
How about something like this, see attachment.
Cor
--- 8< --- detachments --- 8< --- The following attachments have been detached and are available for viewing. http://detached.gigo.com/rc/1N/VJ6jSghM/version.txt Only click these links if you trust the sender, as well as this message. --- 8< --- detachments --- 8< ---
List info: http://lists.roundcube.net/dev/
FWIW, where I work...
We always use static js/css files, with ,$version appended. We set Expires. The files, once cached, simply aren't asked for again until the user clears their cache.
You might review http://developer.yahoo.com/performance/rules.html for other ideas; you might also appreciate http://developer.yahoo.com/yslow/ . yslow usually spits out a few good ideas; and a few I ignore because (for what I do) are inapplicable.
Disclaimer: Yes, I work for Yahoo. I'm not intentionally trying to schill my company; I think the information is actually useful, and also came up high on a search for "best practice javascript css cache" using a competitor's search engine. I think I'm inbiased on this post. :-)
List info: http://lists.roundcube.net/dev/
On Jun 3, 2009, at 4:15 PM, Jason Fesler wrote:
FWIW, where I work...
We always use static js/css files, with ,$version appended. We set
Expires. The files, once cached, simply aren't asked for again
until the user clears their cache.
Thats exactly what we're suggesting we do. Expires is already set, but
the problem is that we currently dont add a version. My minor patch,
and the idea of adding the config:version to all the templates solves
that.
Cor
List info: http://lists.roundcube.net/dev/
Cor Bosman wrote:
Well, you dont just want to change CSS, you also want to change all JS. The JS includes happen in include_script. I guess the plugin api include doesnt need to be done, i suppose it should be up to plugin maintainers to version their includes?
program/include/rcube_template.php: $this->include_script('app.js');
In practice using the filesize as cache busting parameter turned out to work well: $this->script_files[$position][] = $file . '?v=' . filesize(pathtofile);
Since php caches queries to the file system this shouldn't significantly reduce performance.
~Thomas _______________________________________________ List info: http://lists.roundcube.net/dev/
In practice using the filesize as cache busting parameter turned out to work well: $this->script_files[$position][] = $file . '?v=' . filesize(pathtofile);
Since php caches queries to the file system this shouldn't significantly reduce performance.
Great idea. What about the css tags in the templates?
Cor _______________________________________________ List info: http://lists.roundcube.net/dev/
Cor Bosman wrote:
In practice using the filesize as cache busting parameter turned out to work well: $this->script_files[$position][] = $file . '?v=' . filesize(pathtofile);
Since php caches queries to the file system this shouldn't significantly reduce performance.
Great idea. What about the css tags in the templates?
We could actuall do the same here. It's possible to add this at the end of the template parsing function and just search for linked .css and .js files.
~Thomas
List info: http://lists.roundcube.net/dev/
On Fri, 05 Jun 2009 10:52:47 +0200, Thomas Bruederli roundcube@gmail.com OK, so you will submit it soon to SVN trunk? It is important for me too, because I follow SVN trunk with a demo version for the mail4us community. My testers should get rid of these caching issues when updating the test environment as soon as this might be available.
Thanks, Roland
wrote:
Cor Bosman wrote:
In practice using the filesize as cache busting parameter turned out to work well: $this->script_files[$position][] = $file . '?v=' . filesize(pathtofile);
Since php caches queries to the file system this shouldn't
significantly
reduce performance.
Great idea. What about the css tags in the templates?
We could actuall do the same here. It's possible to add this at the end
of
the template parsing function and just search for linked .css and .js files.
~Thomas
List info: http://lists.roundcube.net/dev/
List info: http://lists.roundcube.net/dev/
Same here, i follow SVN pretty closely on our production servers for
potentially 1 million+ accounts. Luckily for now only a few thousand
are actually using it (the rest is using squirrelmail), and they know
it's alpha/experimental. Im still porting some of our internal
functionality to RC. Ive already implemented the previous cache
busting ideas cause I was going crazy answering questions about weird
UI issues. All related to cached JS or CSS. But id much rather see
this in core RC.
I want to say again though, its very cool to see how easy it is to
implement extra functionality through the API. It's been very well
implemented. Currently working on a data migration plugin from
squirrelmail->rc and its a breeze.
Cor
On Jun 5, 2009, at 11:15 AM, Roland Liebl wrote:
On Fri, 05 Jun 2009 10:52:47 +0200, Thomas Bruederli <roundcube@gmail.com
OK, so you will submit it soon to SVN trunk? It is important for me too, because I follow SVN trunk with a demo version for the mail4us community. My testers should get rid of these caching issues when updating the test environment as soon as this might be available.
List info: http://lists.roundcube.net/dev/
I'll commit it until tomorrow... Sorry for the deley, I was absent over the weekend.
~Thomas
On Fri, Jun 5, 2009 at 11:23, Cor Bosmancor@xs4all.nl wrote:
Same here, i follow SVN pretty closely on our production servers for potentially 1 million+ accounts. Luckily for now only a few thousand are actually using it (the rest is using squirrelmail), and they know it's alpha/experimental. Im still porting some of our internal functionality to RC. Ive already implemented the previous cache busting ideas cause I was going crazy answering questions about weird UI issues. All related to cached JS or CSS. But id much rather see this in core RC.
I want to say again though, its very cool to see how easy it is to implement extra functionality through the API. It's been very well implemented. Currently working on a data migration plugin from squirrelmail->rc and its a breeze.
Cor
On Jun 5, 2009, at 11:15 AM, Roland Liebl wrote:
On Fri, 05 Jun 2009 10:52:47 +0200, Thomas Bruederli roundcube@gmail.com OK, so you will submit it soon to SVN trunk? It is important for me too, because I follow SVN trunk with a demo version for the mail4us community. My testers should get rid of these caching issues when updating the test environment as soon as this might be available.
List info: http://lists.roundcube.net/dev/
Thanks Thomas for implementing it into core!
----- Original Message ----- From: "Thomas Bruederli" roundcube@gmail.com To: "Cor Bosman" cor@xs4all.nl Cc: roland@roland-liebl.de; "RoundCube Dev" dev@lists.roundcube.net Sent: Monday, June 08, 2009 7:22 PM Subject: Re: [RCD] cache busting
I'll commit it until tomorrow... Sorry for the deley, I was absent over the weekend.
~Thomas
On Fri, Jun 5, 2009 at 11:23, Cor Bosmancor@xs4all.nl wrote:
Same here, i follow SVN pretty closely on our production servers for potentially 1 million+ accounts. Luckily for now only a few thousand are actually using it (the rest is using squirrelmail), and they know it's alpha/experimental. Im still porting some of our internal functionality to RC. Ive already implemented the previous cache busting ideas cause I was going crazy answering questions about weird UI issues. All related to cached JS or CSS. But id much rather see this in core RC.
I want to say again though, its very cool to see how easy it is to implement extra functionality through the API. It's been very well implemented. Currently working on a data migration plugin from squirrelmail->rc and its a breeze.
Cor
On Jun 5, 2009, at 11:15 AM, Roland Liebl wrote:
On Fri, 05 Jun 2009 10:52:47 +0200, Thomas Bruederli roundcube@gmail.com OK, so you will submit it soon to SVN trunk? It is important for me too, because I follow SVN trunk with a demo version for the mail4us community. My testers should get rid of these caching issues when updating the test environment as soon as this might be available.
List info: http://lists.roundcube.net/dev/
On Tue, 9 Jun 2009 19:25:01 +0200, "Roland Liebl" roland@roland-liebl.de wrote:
Thanks Thomas for implementing it into core!
----- Original Message ----- From: "Thomas Bruederli" roundcube@gmail.com To: "Cor Bosman" cor@xs4all.nl Cc: roland@roland-liebl.de; "RoundCube Dev" dev@lists.roundcube.net Sent: Monday, June 08, 2009 7:22 PM Subject: Re: [RCD] cache busting
I'll commit it until tomorrow... Sorry for the deley, I was absent over the weekend.
~Thomas
Hey all,
I just wanted to clarify if this fix should have covered alleviating cache issues with everything, or only CSS files, etc?
I run a staging copy of my webmail that I update from SVN every few days and just noticed that when I went to send an attachment to someone, the 'Delete attachment' icon was not loaded and the alt tag was being displayed. So I did a ctrl-refresh and that fixed the problem and the icon is now showing up.
So I am not sure if this is a bug or not and figured I should email the list for feedback?
Cheers, Mark _______________________________________________ List info: http://lists.roundcube.net/dev/
Mark Little wrote:
I run a staging copy of my webmail that I update from SVN every few days and just noticed that when I went to send an attachment to someone, the 'Delete attachment' icon was not loaded and the alt tag was being displayed. So I did a ctrl-refresh and that fixed the problem and the icon is now showing up.
This has been fixed in http://trac.roundcube.net/changeset/2646
Sorry I meant to write/ask this earlier but is there a reason for choosing size vs mtime?
I assume mtime is more likely to change in the case of single character typo's or other changes where the size is constant.
a simple sed -i -e 's/filesize/filemtime/g' program/include/rcube_html_page.php is the change required on roundcube-svn.
I couldn't quite work out the mtime part of the following post either: http://lists.roundcube.net/mail-archive/dev/2009-05/0000095.html
Daniel _______________________________________________ List info: http://lists.roundcube.net/dev/
On Jun 18, 2009, at 4:58 PM, Daniel Black wrote:
Sorry I meant to write/ask this earlier but is there a reason for
choosing size vs mtime?
I guess the main reason is that the filesize() call is cached, and the
stat() call isnt. You do not want to do stat() calls on all included
files for every single page load. I suppose you could cache the stat
info yourself, but as Thomas said, in practice filesize() is good
enough.
List info: http://lists.roundcube.net/dev/
according to http://au.php.net/manual/en/function.filemtime.php it is cached.
maybe its good enough but I don't want to be the one debugging it when its not :-)
Thanks for all the discussion so far.
Daniel Black
Infrastructure System Administrator CAcert _______________________________________________ List info: http://lists.roundcube.net/dev/
On Jun 18, 2009, at 5:32 PM, Daniel Black wrote:
according to http://au.php.net/manual/en/function.filemtime.php it
is cached.maybe its good enough but I don't want to be the one debugging it
when its not :-)
Guess mtime would be just as good then, maybe better indeed. Thomas?
Cor
List info: http://lists.roundcube.net/dev/
-
A.L.E.C -
Cor Bosman -
Daniel Black -
Jason Fesler -
Mark Little -
Michael Baierl -
Roland Liebl -
Thomas Bruederli