Hi.

In order to better understand why sometimes I get JS and CSS aggregate generated, can you please tell me where to grab a starting point so that I can find answers to the following subjects:
- given a list of CSS files, how aggregates are generated?
- given two identical list of CSS files, are the aggregation rules sound and do they thus produce the same set of aggregates?
- considering the same page (same CSS list) being delivered in two languages, how aggregates are generated and do they produce the same set of aggregates?
- considering the same page (same JS list) being delivered in two languages, how aggregates are generated and do they produce the same set of aggregates? Can the option "add licence" produce conflicts?

- considered an anonymous users going to a page (no admin menu for instance) and then an admin going to the same page (with admin menu), we get two set of aggregates. when anonymous go back to this page, can we be sure that the first set of aggregates he generated will still be used? what about another anonymous users?

I know this is quite a lot of questions so if I can at least have some directions about where to investigate, I will be happy to do so.

Thanks

Comments

JulienThomas’s picture

Regarding the second bullet,

given two identical list of CSS files, are the aggregation rules sound and do they thus produce the same set of aggregates?

First suggestions are that we may have two set of aggregates generated https://www.drupal.org/node/2348015

mikeytown2’s picture

This is how core works
http://drupal.stackexchange.com/questions/134621/how-does-css-and-js-agg...
You need to understand that as AdvAgg is built on top of it.

AdvAgg filenames have 3 parts to them; each part of it is documented in the readme http://cgit.drupalcode.org/advagg/tree/README.txt#n267

You can go to admin/config/development/performance/advagg/info and use the advagg filename to lookup details about the aggregate.

JulienThomas’s picture

Okay.

I review that and right now I face maybe two issues.

Let's review the first one first, to reduce number of possibilities

Relative url in CSS are transformed into absolute one (okay for that) but protocol is added, protocol being the one asked by the visitors.

.testimonial {padding: 0 15px; background: url(../images/testimonial_quote_end.png) }
would thus becomes
.testimonial {padding: 0 15px; PROTOCOL://SITENAME/..../images/testimonial_quote_end.png}

Why is protocol mandatory?

I am even afraid that this triggered the second issue:

HTTPS - HTTP - HTTPS seems to generate 3 aggregate for this rules
1. https://SITENAME/..../images/testimonial_quote_end.png
2. http://SITENAME/..../images/testimonial_quote_end.png
3. same as 1

Note that I use CSS Embedded Images so even if this image is not wrapped by "CSS Embedded Images", it may be altered by it.
So please tell me if you believe this is a "CSS Embedded Images" issue.

mikeytown2’s picture

Following what core does in terms of removing the schema/protocol. My guess is they include it because of this issue: http://www.stevesouders.com/blog/2010/02/10/5a-missing-schema-double-dow...

I can make that an option, so the protocol can be removed if desired.

JulienThomas’s picture

I would understand for the CSS URLs. I also heard that this does not prevent files from being generated twice.

But for the images inside the CSS, it is okay. This is quite logic but also confirmed in the URL you mentioned

It turns out this only happens with stylesheets. The Missing schema, double download test page I created contains a stylesheet, an image, and a script that all have protocol relative URLs pointing to 1.cuzillion.com. The stylesheet is downloaded twice, but the image and script are only downloaded once.

So yes, please put this an option and
a) we agree this is for assets inside CSS and CSS files themselves, right?
b) will this prevent CSS from being generated one for HTTP and the other for HTTPS?

Thanks

mikeytown2’s picture

Status: Active » Fixed

This is now an option in the latest dev of advagg. Marking as fixed.

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.