Sometimes you just want a file to be served directly from your site, not from a CDN.

This patch adds an $alter parameter to file_create_url() that defaults to TRUE.

Comments

wim leers’s picture

Status: Needs review » Postponed (maintainer needs more info)

I think you should just configure the integration with the CDN to *not* serve the file from the CDN. The module should not decide about this, the developer/end user should.

jbrown’s picture

Title: Altering URIs in file_create_url() should be optional » Don't allow altering of javascript URIs
Category: feature » bug
Status: Postponed (maintainer needs more info) » Needs review
StatusFileSize
new2.46 KB

There are times when the module that is requesting the URL for a file wants to be sure that the URI it is derived from will not be altered by another module.

For example (as you know), javascript can have same origin policy issues.

The attached patch prevents modules from modifying the URI of javascript files.

It is not appropriate to rely on module settings to work around this issue.

c960657’s picture

Same origin policy is not applied when scripts are loaded using <script src="http://elsewhere.example.com/foo.js">, is it?

jbrown’s picture

wim leers’s picture

I understand your concern. It make sense from a usability POV: you don't want to users of your module to ever have to worry about those things.
However, I strongly disagree with your proposal.

I would be fine with "tagging" files to ensure they get served from the same domain (to comply with the same origin policy). But what if I want to aggregate and minify the CSS and then serve it from the local domain? This patch would disallow even that.

In summary: I agree with the concept, I don't agree with the actual implementation. Your implementation works from a usability POV, but it completely prevents performance enhancements and is therefore unacceptable.

wim leers’s picture

Status: Needs review » Needs work

Status: Needs work » Closed (outdated)

Automatically closed because Drupal 7 security and bugfix support has ended as of 5 January 2025. If the issue verifiably applies to later versions, please reopen with details and update the version.