Done : http://trac.apostrophenow.org/ticket/533
<http://trac.apostrophenow.org/ticket/533>Cheers, Before Printing, Think about Your Environmental Responsibility! Avant d'Imprimer, Pensez à Votre Responsabilitée Environnementale! On Wed, Aug 18, 2010 at 3:24 PM, Tom Boutell <[email protected]> wrote: > A specific task would be convenient for those who consider 'symfony > cc' too heavy, and I could still invoke it automatically from a > 'symfony cc' hook. Would you mind opening a ticket on > trac.apostrophenow.org to remind me to look at this? > > On Aug 17, 9:54 am, Stéphane <[email protected]> wrote: > > +1 for the specific task ! > > > > Before Printing, Think about Your Environmental Responsibility! > > Avant d'Imprimer, Pensez à Votre Responsabilitée Environnementale! > > > > On Tue, Aug 17, 2010 at 3:52 PM, Daniel Lohse > > <[email protected]>wrote: > > > > > Mhm, I somehow I knew that this would have been toooo easy. (: > > > > > But okay, so we do need to cache these relations array(bundle => > > > sha1sum.ccsgz) somewhere it gets loaded on every request and I'd guess > the > > > app.yml.php file is a good place. Still, using this approach does not > > > necessitate – or even need for that matter – manual cache invalidation > > > because we could send the far future Expires header everytime. If files > in > > > that bundle change, clear the files (not necessarily with a brute-force > > > symfony cc) and they are rebuilt on the next page refresh. Maybe we > could > > > provide a apostrophe:clear-minified-resources [--js] [--css] [--all] > > > [--env="dev|prod|staging"] task so as to not need the brute-force > symfony cc > > > or go hunting for these minified files manually? > > > > > Cheers, Daniel > > > > > On 17.08.2010, at 15:32, Tom Boutell wrote: > > > > > > Daniel, this almost works and I got pretty excited thinking about > > > > it... but there's a tragic flaw. > > > > > > On the first page access you slurp up all the CSS files, minify them, > > > > md5 that and create a cache file. Fine. > > > > > > On the second page access you... can't point to the cache file > without > > > > first doing all of that again (everything except actually writing the > > > > file) just to figure out what the filename is. (: > > > > > > Opening all of the files, slurping them in and md5'ing them on every > > > > page access is overhead we do not want. So it makes more sense to > have > > > > a cache key. > > > > > > On Aug 16, 9:13 am, Daniel Lohse <[email protected]> > wrote: > > > >> Sorry for being a bit slow today: why would we need cache > invalidation? > > > If the filename of the compacted file(s) is a hash generated from the > > > contents of the file then after one file changes and the > scripts/stylesheets > > > are re-generated the filename changes. The browser then should just > request > > > the file because it doesn't about that file yet (filename is not the > same). > > > > > >> Am I missing something here? > > > > > >> Cheers, Daniel > > > > > >> Sent from my iPad > > > > > >> On Aug 16, 2010, at 2:59 PM, Tom Boutell <[email protected]> wrote: > > > > > >>> You're right, we do need cache invalidation. I just came up with a > > > >>> clean way to do it without tweaking app.yml settings, adding a > table > > > >>> or making glob() calls: just use a file in the asset-cache folder > to > > > >>> hold the current cache key. The OS should cache reads from that > file > > > >>> extremely well. > > > > > >>> It may even be possible to avoid the filesystem hit by writing it > as a > > > >>> PHP file in cache/frontend/prod/config that just calls > > > >>> sfConfig::set(). Then with any luck it would be autoloaded and even > > > >>> cached by APC until its modification date changes just like an > app.yml > > > >>> setting would. But plain old file_get_contents() calls to a simple > > > >>> file with an asset cache version number in it would also get cached > > > >>> nicely by the operating system so it might be overkill to try to > wedge > > > >>> it into Symfony's cache. > > > > > >>> On Aug 15, 11:44 am, pghoratiu <[email protected]> wrote: > > > >>>>> It might be worthwhile to take things a step further by > versioning > > > >>>>> them in the URL so that they can be given an infinite cache > > > expiration > > > >>>>> date, although this requires a database hit or perhaps a glob > call > > > >>>>> when outputting the pages that contain them. The code is a big > step > > > >>>>> forward as-is if you are using unminimized, uncombined CSS and JS > and > > > >>>>> has no negative impact on your existing caching issues, but we'll > > > >>>>> think about next steps. > > > > > >>>> ==== > > > >>>> I think think it's important to add cache invalidation as well. My > > > >>>> suggestion is to append another key > > > >>>> to app.yml to have a cache key that can be updated manually and > append > > > >>>> that key too the minified resource > > > >>>> file: > > > >>>> all: > > > >>>> a: > > > >>>> ver:1 > > > >>>> css/main.css?ver=1 > > > >>>> This way css and js pages can be cached indefinitely on the client > > > >>>> side without having problems when manually > > > >>>> updating the css or js files. > > > > > >>>> gabriel > > > > > >>> -- > > > >>> If you want to report a vulnerability issue on symfony, please send > it > > > to security at symfony-project.com > > > > > >>> You received this message because you are subscribed to the Google > > > >>> Groups "symfony users" group. > > > >>> To post to this group, send email to > [email protected] > > > >>> To unsubscribe from this group, send email to > > > >>> [email protected]<symfony-users%[email protected]> > <symfony-users%[email protected]<symfony-users%[email protected]> > > > > > >>> For more options, visit this group at > > > >>>http://groups.google.com/group/symfony-users?hl=en > > > > > > -- > > > > If you want to report a vulnerability issue on symfony, please send > it to > > > security at symfony-project.com > > > > > > You received this message because you are subscribed to the Google > > > > Groups "symfony users" group. > > > > To post to this group, send email to [email protected] > > > > To unsubscribe from this group, send email to > > > > [email protected]<symfony-users%[email protected]> > <symfony-users%[email protected]<symfony-users%[email protected]> > > > > > > For more options, visit this group at > > > >http://groups.google.com/group/symfony-users?hl=en > > > > > -- > > > If you want to report a vulnerability issue on symfony, please send it > to > > > security at symfony-project.com > > > > > You received this message because you are subscribed to the Google > > > Groups "symfony users" group. > > > To post to this group, send email to [email protected] > > > To unsubscribe from this group, send email to > > > [email protected]<symfony-users%[email protected]> > <symfony-users%[email protected]<symfony-users%[email protected]> > > > > > For more options, visit this group at > > >http://groups.google.com/group/symfony-users?hl=en > > > > > > -- > If you want to report a vulnerability issue on symfony, please send it to > security at symfony-project.com > > You received this message because you are subscribed to the Google > Groups "symfony users" group. > To post to this group, send email to [email protected] > To unsubscribe from this group, send email to > [email protected]<symfony-users%[email protected]> > For more options, visit this group at > http://groups.google.com/group/symfony-users?hl=en > -- If you want to report a vulnerability issue on symfony, please send it to security at symfony-project.com You received this message because you are subscribed to the Google Groups "symfony users" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/symfony-users?hl=en
