I have a hook_advagg_css_alter() implementation that, uses file_create_url to make all CSS definitions that have a url defined

background: url('/sites/all/modules/contributed/views/images/arrow-active.png');

look like

background: url('http://cdn1.mydomain.com/sites/all/modules/contributed/views/images/arrow-active.png');

My implementation looks like:

 * Implementation of hook_advagg_css_alter().
 * @param $data
 * @param $files
 * @param $bundle_md5
function sr12_general_advagg_css_alter(&$data, $files, $bundle_md5) {
  $data = preg_replace_callback('/url\s*\([\'"]?([^\'")]+)[\'"]?\s*\)/i', '_sr12_general_css_url_file_url', $data);

 * @param $matches
 * @return mixed|string
function _sr12_general_css_url_file_url($matches) {
  $uri = ltrim($matches[1], '/');
  if (stripos($uri, 'http') === FALSE) {
    $url = 'url(' . file_create_url($uri) . ')';
//    dpm($url, '$url');
    return $url;
  else {
    return $uri;

I'm not sure if I'm doing something wrong here but, on HTTPS pages this hook is not being called so all the URL definitions in the aggregated CSS files still point to the HTTP version of the file.

The other way around is true as well: after clearing adv agg cache, if I go to a https page, the CSS files get aggregated with the 'https://' schema. Adv Agg then serves these same bundles on non-https pages.

I hope this makes sense.


andreiashu’s picture

I've found this issue in Parallel CSS module which actually states the same problem: #1212184: Create different CSS aggregation files for HTTP and HTTPS

I think the problem comes from how the bundler computes the MD5 bundle hash - ie. it should take into consideration wether the current page is on HTTP or HTTPS.

andreiashu’s picture

Status: Active » Needs review
4.14 KB

The attached patch seems to fix the problem for me. I think it can be improved as we could reuse some file bundles caches on HTTPS pages but I didn't have time to look more into it.

Tested and works with parallel_css module as well.

NB: please enable HTTPS option on your "Other" tab on the CDN module's settings page in order for this to work.

mikeytown2’s picture

Patch in #2 does not apply cleanly. Taking the ideas from your patch I've come up with this.

mikeytown2’s picture

Status: Needs review » Fixed

Patch #3 has been committed.

andreiashu’s picture

Thanks mike. I'll give it a go now.

andreiashu’s picture

Status: Fixed » Needs work

Tested the latest advagg GIT version + CDN + parallel_css and unfortunately this patch doesn't work...
I'm not yet sure why, be this is what I experience:

  1. I go on the HTTPS url, the CSS files get generated correctly (images taken from secure location)
  2. I go on the NON-HTTPS url, I get served CSS files that have https in their URL... (EDIT: the CSS files themselves are served correctly from NON-HTTPS url)
mikeytown2’s picture

Issue is the background images in CSS are getting https, correct? Do you get different filenames on the same page; comparing http to https?

andreiashu’s picture

Issue is the background images in CSS are getting https, correct?

Yes that is correct: basically you don't want CSS files served from HTTS to contain HTTP URLs (and viceversa).

I just checked on a vanilla pressflow install (same mix of versions: latest CDN, AdvAgg and parallel_css) and I can confirm that while I am getting different css filenames the problem still exists. UPDATE: scratch that, I checked the same on one of our sites and I am getting identical CSS file names for both HTTP and HTTPS...

Today I'm going to investigate the issue a bit more and I should be back with updates.

andreiashu’s picture

1.05 KB

The attached patch is against 1.5 version. This fixed the problems for us regarding https pages for the moment.
Sorry I didn't have time to get the latest version of all these modules (advagg, cdn + parallel css) working.

hope this helps

mikeytown2’s picture

Status: Needs work » Fixed
1.4 KB

Committed this patch as well. Bundler needed to be schema aware. Let me know if this doesn't fix it :)

andreiashu’s picture

works now! thanks

Status: Fixed » Closed (fixed)

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

nicksanta’s picture

I am getting this same problem on 7.x-2.0.

mikeytown2’s picture

Can you open up a new issue for the reported problem?