+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]> > >>> 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]<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
