CDN module AdvAgg 7.x-2.x Integration

Wow, lots of information, not sure it's entirely clear to me.

1. Are you saying that the CDN module should depend on the AdvAgg module? I don't want to introduce that dependency.
2. Assuming 1, then how can I make sure that the AdvAgg module can take over CSS aggregation from the CDN module when both are installed? Plus, the AdvAgg module will still call file_create_url() on files referenced in CSS (background images etc.), right?
3. The *only* reason I'm overriding CSS aggregation is because Drupal core does not call file_create_url() on files referenced in CSS files. I was thinking that it should be possible to still get that in Drupal, because it would only involve a pretty small change and wouldn't break anything.

mikeytown2 and Wim Leers

It would be great to see a serious integration 'concept' over these two very valid modules.

I have dealt with this same CDN + AdvAgg issue back in the [past] Drupal 6 days.

CDN without the 'help' of AdvAgg has some issues and I solved this via the hooks within AdvAgg.

Wim, worst case you can add a check for AdvAgg 7.x-2.x Integration, and then add the essential code on failing to find the module / hooks avail.

Otherwise, merge the two modules into one unit!

Yes, I'm totally fine with adding checks for AdvAgg to the CDN module, I just don't want them to depend on each other :)

What you said in #7 worries me, mikeytown2. Or rather, the "fix" you committed does this:

Far future is not needed in advagg as each file is unique. Also interferes with generation for some reason.

First: I presume AdvAgg does generate unique file URLs on its own. If so, then that part is indeed not needed.

Second: the way the CDN module *serves* assets when the Far Future setting is enabled is also crucial for it to be effective. Look at the many headers that are being set in cdn_basic_farfuture_download().

1. +++ b/cdn.module
   @@ -506,6 +509,46 @@ function cdn_cdn_blacklist() {
   +  $advagg_hash['variables'][CDN_HTTPS_SUPPORT_VARIABLE] = variable_get(CDN_HTTPS_SUPPORT_VARIABLE, FALSE);
   ...
   +  $advagg_hash['variables']['cdn_check_protocol'] = cdn_check_protocol();
   

   AFAICT the first is not necessary if you're using the second.

2. +++ b/cdn.module
   @@ -506,6 +509,46 @@ function cdn_cdn_blacklist() {
   +  $advagg_hash['variables']['maintenance_mode'] = variable_get('maintenance_mode', FALSE);
   +  $advagg_hash['variables']['cdn_request_is_https'] = cdn_request_is_https();
   

   Why don't you need these in AdvAgg already?

3. +++ b/cdn.module
   @@ -506,6 +509,46 @@ function cdn_cdn_blacklist() {
   +  $advagg_hash['variables']['cdn_serve_from_https'] = cdn_serve_from_https();
   

   More duplication.

Hi, I just tried out this patch and an error popped up. Please see below. Any help would be greatly appreciated.

AdvAgg will issue a request for a file that does not exist inside of the AdvAgg directory. If AdvAgg sends a 404, everything is ok; if something else sends a 404 then that means that AdvAgg will not be able to generate an aggregate if it is missing as something else is handling the 404 before AdvAgg has a chance to do it. If you are reading this, it means that something else is handling the 404 before AdvAgg can. Raw request info:

stdClass Object
(
    [url] => http://www.atheistrepublic.com/sites/default/files/advagg_js/js1377513399.js
    [status] => Done.
    [code] => -10060
    [chunk_size] => 1024
    [data] => 
    [request] => GET /sites/default/files/advagg_js/js1377513399.js HTTP/1.0
User-Agent: Drupal (+http://drupal.org/)
Connection: close
Host: www.atheistrepublic.com


    [options] => Array
        (
            [timeout] => 4.9728312492371
            [headers] => Array
                (
                    [User-Agent] => Drupal (+http://drupal.org/)
                    [Connection] => close
                    [Host] => www.atheistrepublic.com
                )

            [method] => GET
            [data] => 
            [max_redirects] => 3
            [dns_timeout] => 5
            [connect_timeout] => 5
            [ttfb_timeout] => 20
            [context] => 
            [secure_socket_transport] => ssl
            [blocking] => 1
            [version] => 1.0
            [referrer] => 
            [domain_connections] => 2
            [global_connections] => 128
            [global_timeout] => 120
            [chunk_size_read] => 32768
            [chunk_size_write] => 1024
            [async_connect] => 1
            [ping_db] => 20
        )

    [socket] => tcp://www.atheistrepublic.com:80
    [flags] => 6
    [uri] => Array
        (
            [scheme] => http
            [host] => www.atheistrepublic.com
            [path] => /sites/default/files/advagg_js/js1377513399.js
        )

    [running_time] => 5.0271687507629
    [fp] => Resource id #1643
    [error] => Connection timed out. TCP Connect Timeout

Can anyone help me with the issue I'm facing on my last post?

I could apply the patch. However, it seems that background images served in the css is not called correctly when enabling advagg. When disabling all the images display correctly.

Same problem as Isolesen in #15, background images are not served.
The css contains the cdn url twice:

background-image: url('//random123.cloudfront.net//random123.cloudfront.net/path/to/img/background.png')

It seems that this patch works correctly for the background images.

Is this still applicable after the latest stable release? (which is more recent than the latest comments)

Ah, just found out why the adv_agg patch wasn't working. It wrote the new file to my drupal root, not to the module root. I'll keep patching the module until the D8 issue trickles down, I guess. Thanks for the reply. Otherwise I can confirm this patch works lovely.

Can anybody tell me what patch do I have to apply for the 7.x-2.1 version?

19: cdn-1942230-18-advagg-hooks.patch queued for re-testing.

How can I apply this patch manually?

@almamun https://drupal.org/node/1399218

To me the latest patch in #19 didn't apply. I'm using the latest cdn -dev version.

I am using 7.x-2.x-dev version but I can't find the file cdn.advagg.inc to patch it.
Am I missing something?
Thanks in advance
John.

The latest patch does not work with 7.x-2.6 or the current dev release.

Great news, don't forget to update the project page! :)

Very sorry for my long silence — but looks like this got resolved in the mean time by the ever awesome @mikeytown2, yay! :)

I think this is related: the issue is indeed fixed (I have manually checked the aggregates and Content-Encoding is gzip) but there is still a warning in admin/reports/status:

The web servers configuration will need to be adjusted. In most cases make sure that the webroots .htaccess file still contains this section "Rules to correctly serve gzip compressed CSS and JS files". Certain default web server configurations (nginx (link is external)) do not gzip HTTP/1.0 requests. If you are using cloudfront you will have to add metadata (link is external) to the .gz files. There are some other options if using cloudfront (link is external).

I am using cdn module and serving the files through cloudfront. When requesting the css aggregate (directly or in a page) that is mentioned in the warning it is served gzipped through cloudfront, so, I'm not sure what's the problem here.

The only "out of the ordinary" thing in my configuration is that cloudfront uses https to serve the files. Is it possible for https to be creating a "false positive" warning in the error logs?