Hi, I just implemented this plugin, which seems very interesting (1.4 compatible also).
However, when i use a_include*, I am collecting js and css which are not in my project, like these one for example: /apostrophePlugin/css/a-reset.css /apostrophePlugin/css/a-utility.css /apostrophePlugin/css/a-forms.css /apostrophePlugin/css/a-buttons.css /apostrophePlugin/css/a-navigation.css /apostrophePlugin/css/a-components.css /apostrophePlugin/css/a-area-slots.css /apostrophePlugin/css/a-engines.css /apostrophePlugin/css/a-admin.css /apostrophePlugin/css/a-colors.css /apostrophePlugin/js/aUI.js /apostrophePlugin/js/aControls.js /apostrophePlugin/js/plugins/jquery.autogrow.js /apostrophePlugin/js/plugins/jquery.keycodes-0.2.js /apostrophePlugin/js/plugins/jquery.timer-1.2.js /apostrophePlugin/js/a.js How do disable the call to thoses files? Thanks by advance, On 18 août, 16:34, Stéphane <[email protected]> wrote: > 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%2bunsubscr...@goog > > > > >>> legroups.com> > > <symfony-users%[email protected]<symfony-users%252Bunsubscribe > > @googlegroups.com> > > > > > >>> 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%2bunsubscr...@goog > > > > > legroups.com> > > <symfony-users%[email protected]<symfony-users%252Bunsubscribe > > @googlegroups.com> > > > > > > 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%2bunsubscr...@goog > > > > legroups.com> > > <symfony-users%[email protected]<symfony-users%252Bunsubscribe > > @googlegroups.com> > > > > > 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%2bunsubscr...@goog > > legroups.com> > > 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
