Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.I got some pretty strange behaviour here.
The latest dev exchanges the domain for the servers ip.
For a logged in user the css is linked like this
<link type="text/css" rel="stylesheet" href="//<domain.com>/sites/default/files/advagg_css/<longstring>.css" media="all" />
but for anonymous users the css is linked like this
<link type="text/css" rel="stylesheet" href="//<serverip>/sites/default/files/advagg_css/<longstring>.css" media="all" />
Why does it exchange the domain name for the ip?
| Comment | File | Size | Author |
|---|---|---|---|
| #22 | advagg-2833643-22-default-no-domain-css.patch | 7.82 KB | mikeytown2 |
| #21 | advagg-2833643-21-default-no-domain-css.patch | 9.03 KB | mikeytown2 |
| #19 | advagg-2833643-19-default-no-domain-css.patch | 885 bytes | mikeytown2 |
Comments
Comment #2
Nchase CreditAttribution: Nchase as a volunteer commentedComment #3
Nchase CreditAttribution: Nchase as a volunteer commentedthe issue is more complicated. it also sometimes uses subdomains to link the css.
<link type="text/css" rel="stylesheet" href="//<subdomain.domain.com>/sites/default/files/advagg_css/<longstring>.css" media="all" />Comment #4
Nchase CreditAttribution: Nchase as a volunteer commentedand the same happens to the js files
Comment #5
mikeytown2 CreditAttribution: mikeytown2 commentedhttps://api.drupal.org/api/drupal/includes%21file.inc/function/file_crea... Is what is being used in order to create the resource link.
Comment #6
Nchase CreditAttribution: Nchase as a volunteer commentedbut that doesn't happen with any other module or drupals core css/js aggregation.
Comment #7
Nchase CreditAttribution: Nchase as a volunteer commentedok, found the cause: wrong server configuration. closed
Comment #8
Niklan@Nchase, how did you fix it. I have same issue on four different servers, with different OS's and web servers. Also, I have same problem on hosting.
This is only happens for CSS. All works fine, but for CSS all url replaced by IP's. FontAwesome is first what fails.
I temporary fix it by set $base_url variable in settings.php. But this is will not work for multidomain sites, but I have same issue on such sites. Why is that happens on both NGINX and Apache web servers?
Comment #9
mikeytown2 CreditAttribution: mikeytown2 commented@Niklan
What value is $GLOBALS['base_url'] on your severs?
https://api.drupal.org/api/drupal/includes%21stream_wrappers.inc/functio...
And more importantly what is $_SERVER['HTTP_HOST'] & $_SERVER['SCRIPT_NAME'] on your servers?
https://api.drupal.org/api/drupal/includes%21bootstrap.inc/function/drup...
Comment #10
Nchase CreditAttribution: Nchase as a volunteer commentedthe problem came with apache, which is able to listen at *:80. If your virtual host configuration is not set to a specific ip but to *:80 the advagg somehow resolves the hostname differently than drupal core does. Basically it finds every domain listed at the :80 port and brings it up.
Comment #11
mikeytown2 CreditAttribution: mikeytown2 commentedComment #12
mikeytown2 CreditAttribution: mikeytown2 commentedAdvagg uses core settings. It doesn't do it's own hostname lookup.
Comment #13
Nchase CreditAttribution: Nchase as a volunteer commentedcan't be. the core doesn't throw that error. I had that error on 5 sites, and with core everything is fine. With advagg I wait for one cache clear cycle and then everything is a mess.
Comment #14
toschl CreditAttribution: toschl at Namics commentedI had the same issue with css aggregation. I had:
url(/font.ttf)
And advagg converted this to:
url(//your-domain.com/sites/default/files/font.ttf)
Now as this is cached and another user visits www.your-domain.com (incl the www) he'll receives a
"Access to Font at 'https://your-domain.com/sites/default/files/font.ttf?5bdyw2' from origin 'https://www.your-domain.com' has been blocked by CORS policy: No 'Access-Control-Allow-Origin' header is present on the requested resource"
So best would be to keep the path relative instead of converting them to absolute ones.
Comment #15
mikeytown2 CreditAttribution: mikeytown2 commentedOn admin/config/development/performance/advagg under Obscure Options check the "Do not run CSS url() values through file_create_url()" box. If you want to keep that setting unchecked you could also check "Convert absolute paths to be self references" as that should take care of this issue as well.
Comment #16
mikeytown2 CreditAttribution: mikeytown2 commentedAnother thing to consider is to make https://your-domain.com redirect to https://www.your-domain.com
Comment #17
toschl CreditAttribution: toschl at Namics commentedThanks. This solved my problem.
Comment #18
NicholasSI had probably the same issue as the original poster @Nchase, I determined, however, the site had multiple Domains registered for it, but only one had the proper SSL setup. So when bots/visitors brought up the site via the other http:// domains, it would generate CSS files with one of those other domains. But when you viewed the same page over the SSL/HTTPS domain you would get mixed content errors.
IMO - This feature of automatically appending the domain should be off by default.
Comment #19
mikeytown2 CreditAttribution: mikeytown2 commentedComment #21
mikeytown2 CreditAttribution: mikeytown2 commentedComment #22
mikeytown2 CreditAttribution: mikeytown2 commentedComment #27
mikeytown2 CreditAttribution: mikeytown2 commentedComment #29
Rafal LukawieckiI am also experiencing this issue but perhaps for a different reason—see my support request #2923732: Host IP address shows up in links—incorrect HTTPRL config?.