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