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?.