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.We have a problem with the using advagg and cdn modules together as follows.
Our corporate website site is behind an Akamai CDN which proxies to various webservers, of which Drupal is just one of many. So for example www.myco.com/xxx and www.myco.com/yyy come to Drupal but the rest go elsewhere.
We have also implemented separate CDN 1.cms.myco.com that also served through Akamai for commonly served .js, .css from Drupal. This domain has no cookies and can have longer caching both in Akamia and the browser.
The problem is as we migrate content into Drupal it may reference .js files that are located at www.myco.com/aaa which is not in anyway connected to Drupal. When we add these to a module's libraries.yml file with the following properties
{type: external, preprocess: false}
Drupal does not treat it as external and tries to serve it from
1.cms.myco.com and they are not there.
We do not want to keep duplicate copies to get around this (though we have so far).
I think the issue is from advagg.module and the code that follows this comment
// If type is external and starts with http, https, or // but points to
// this host change to file, but move it to the top of the aggregation
// stack.
Is there any chance we could get a new obscure option that would allow is to disable this chunk of code?
Note I have a set of instructions that can duplicate the problem with a vanilla Drupal 8 install and a simple custom module if you want.
| Comment | File | Size | Author |
|---|---|---|---|
| #11 | advagg-handle-external-same-host-js-file-2845990-11.patch | 3.92 KB | gregj00 |
| |||
| #10 | interdiff-2845990-3-10-orig.txt | 4.31 KB | gregj00 |
| #10 | advagg-handle-external-same-host-js-file-2845990-10.patch | 3.92 KB | gregj00 |
| |||
| #5 | Capture.PNG | 20.69 KB | NickDickinsonWilde |
| #3 | advagg-handle-external-same-host-js-file-2845990.patch | 3.75 KB | gregj00 |
Comments
Comment #2
gregj00 CreditAttribution: gregj00 commentedI am working on a patch for this and will submit shortly.
It adds an obscure option preserve_external and a clause in the if statement to check that before converting the external files to use the cdn.
Comment #3
gregj00 CreditAttribution: gregj00 commentedPlease see the attached patch that adds a feature for this issue.
Comment #5
NickDickinsonWildeDoes disabling these options not fix that for you? (on /admin/config/development/performance/advagg)
Comment #6
gregj00 CreditAttribution: gregj00 commentedHey Nick, Disabling that option does fix a local test, did not try yet on test or prod servers where we have this running. But it should as it would keeps it out of that if statement that changes it from external to file But we do lose the benefit of that what that checkbox provides. At this point we do not have anything that "Fix improperly set type" fixes but we could in the future.
Either way I need to figure out what is not passing on the tests before it.
Comment #7
NickDickinsonWildeYeah that sounds good. However, instead of directly under obscure I'd prefer the option is under the rewrite option and disabled if the rewrite is disabled; make sense?
Comment #8
gregj00 CreditAttribution: gregj00 commentedHey Nick, That does I have it partially complete and will update it here once I finish.
Comment #9
NickDickinsonWildegreat :) thanks
Comment #10
gregj00 CreditAttribution: gregj00 commentedHow about this? In SettingsForm.php I could only disable the js_preserve_external checkbox but not uncheck it if checked. with the "states" functionality. If I tried to uncheck it by adding something like this, then when js_fix_type was checked then js_preserve_external would be automatically checked regardless of the prior state.
Also note I only added this functionality for Javascript, as code for css does not have the external but points to the same file if statement as the js function does.
Comment #11
gregj00 CreditAttribution: gregj00 commentedThere are no differences between patch 11 and patch 10. I am resubmitting same file as 11 because the tests did not run on the previous submission.
Comment #12
mikeytown2 CreditAttribution: mikeytown2 commentedComment #13
NickDickinsonWildeApplied the patch. Thanks :) very much appreciated!
Comment #15
mikeytown2 CreditAttribution: mikeytown2 commented#2864421-17: Fix external JS type option logic has a better way of detecting the base_url