I use:
original pull
http://cdn.example.com|.jpg .jpeg .png .gif .css .js

I use it at Drupal 7 for same name subdomain (to increase number of parallel connections and for cookieless subdomain).
Well, for some files of the same type it works, for some it does not, and lets them at www. instead of cdn.
When I aggregate css and js files through D7 core performance settings, then almost no files are under cdn. subdomain.

Members fund testing for the Drupal project. Drupal Association Learn more


Wim Leers’s picture

Assigned: Unassigned » Wim Leers
Category: bug » support
Status: Active » Postponed (maintainer needs more info)

Thanks for the report! :)

For which does it work and for which doesn't it?

Also, try to write more clear English because this is barely understandable.

dropbydrop’s picture

Category: support » bug
Status: Postponed (maintainer needs more info) » Active

original pull
http://cdn.example.com|.jpg .jpeg .png .gif .css
If my syntax above is correct then all images and css files should be served from cdn.example.com and all the rest from www.example.com.

When there is no css files combination, then everything works as expected.

When I set CSS files to be aggregated (the setting from performance options of drupal), then the following happen:
1. The aggregated css files are served from www.example.com, instead of cdn.example.com as they should.
2. Images from /misc and sites/all are server from cdn.example.com, but images from sites/example.com are served from www.example.com

Wim Leers’s picture

That's very odd. I will try to reproduce this.

JMParsons’s picture

Issue tags: +CDN

The problem has to deal with your passed in path's scheme.

In the function cdn_file_url_alter(&$path) if the file $path has a scheme, it is prepended before it. The CSS and Javascript aggregated files are given the scheme "public://" and by doing so require the scheme to be removed for the cdn functions to work that is:

$servers = ($mode == CDN_MODE_BASIC) ? cdn_basic_get_servers($path) : cdn_advanced_get_servers($path).

In it's simplest form this would work:

$path = str_replace('public://', 'sites/all/files/', $path);

Where 'sites/all/files/' with trailing slash is the location of your Public file system path, see your admin/config/media/file-system page for what you set as your default path.

For public I use this:

$scheme = file_uri_scheme($path);
if ($scheme == 'public') {
  $wrapper = file_stream_wrapper_get_instance_by_scheme($scheme);
  $path = $wrapper->getDirectoryPath() . '/' . file_uri_target($path);
timmillwood’s picture

I think I have a similar issue, therefore. Subscribing.

dropbydrop’s picture

If I use http://cdn-a.com (This should serve all files from a single CDN),
then all images are served by cdn, but not css and js.
edit: a clear cache and now jpg are not served by cdn

if I use http://cdn-a.com|.gif .jpg .jpeg .png
then png are served by cdn, but not jpg

i use labjs
at performance settings, i cache and aggregate css and js and compress cached pages

rwohleb’s picture


It does seem like this is an issue with public:// streams.

dropbydrop’s picture

what are public streams and how I can fix them?

rwohleb’s picture

It's not something you can do. It's something in code.

dgastudio’s picture

before activate CDN

<a rel="group" class="modal fl cboxElement" href="/content/images/product/roll/rolling_gate/description/pic_2.jpg"><img class="thumb" src="/content/images/product/roll/rolling_gate/description/pic_2_thumb.jpg"></a>

after activate CDN

<a rel="group" class="modal fl cboxElement" href="/content/images/product/roll/rolling_gate/description/pic_2.jpg"><img class="thumb" src="http://cdn.mydomain.com/content/images/product/roll/rolling_gate/description/pic_2_thumb.jpg"></a>

as u can see, the image location has been changed, but image link still the same.

it's something that i'm doing wrong?

dropbydrop’s picture

When this is expected to be fixed?

rwohleb’s picture

Status: Active » Needs review
652 bytes

Here is a patch of JMParson's solution in #4. It looks like it should be a decent solution until the CDN module has more robust support for streams.

bigsyke’s picture

Unfortunately i'm still having this issue after the #12 patch. All my content is stored at xxx.appspot.com/*folder/ *.file

however /sites/default/files/css/..... is still being requested, on all files. So its not rewriting any urls.

with the patch applied, the URI is '/sites/all/themes/drupal/css/pages.css'

Are we supposed to clone our Drupal folder structure on the CDN'

mrfelton’s picture

I'm having similar problems. The patch at #12 is definite improvement, and with that applied css and images seem to be distribute acros the domains properly. .js files however still from served off the main domain name, dispute having told cdn to sever them from a separate one. The javascript is a problem with or without headjs.

EDIT: My issue with the JavaScript was because all js was blacklisted in the settings page.

bigsyke’s picture

hmmm... Im using google apps' space, and it seems the only way I can get the CDN to work is if I copy the whole drupal installation over, while keeping the folder structure the same.

I can not just copy all .css files into my css folder, because the module still does not catch and reroute the paths.

Docc’s picture

sub. Patch 12 seems to work for me (serving all from 1 cdn)

BenK’s picture


ahwebd’s picture


logii’s picture

755 bytes

Patch 12 works for me too.
However after using theme_image_style() in my theme's template.php the image styles generated by views did not use CDN path.
Here's my patch to fix that.

rjbrown99’s picture

#12 and #19 were very helpful and are working for me. Thanks.

dropbydrop’s picture

Is it possible the patched to be applied to o the module and issue a new version? thanks

dropbydrop’s picture

After latest dev version today, it still does not work for files that are like that: http://domain.com/sites/domain.com/files/styles/70x70/public/images/taxo...
What is going on?
Hope this will be fixed soon.
It's been a few months without a solution for D7.

dstol’s picture

Version: 7.x-2.0-beta1 » 7.x-2.x-dev
Status: Needs review » Needs work

Ditto on #22 and #19 is definitely needs work.

zwoop’s picture

Same problem here : Subscribe.

dropbydrop’s picture

This is essential module for a drupal site like metatags is and it finally as an alpha version.
Maybe we should gather some money so that someone develops it like it happened with metatags.

Wim Leers’s picture

Version: 7.x-2.x-dev » 7.x-2.0-beta1
Priority: Normal » Critical

Sorry for the enormous delays. Unfortunately, neither patch fully and properly addresses the problem, hence I cannot just go and commit either one.

dropbydrop’s picture

thanks for the update.
I hope this issue gets fixed soon.

bjuncosa’s picture

So far, I've noticed that the file field does not work, and parts of the image field don't work (the image itself works, but the wrapping anchor will not). Would it be a good idea to at least mention the limitations of the module somewhere obvious so a unsuspecting developer doesn't get upset?

bjuncosa’s picture

Would it make sense to create / register a "cdn://" stream wrapper, and rewrite the "public://" streams? It seems though, that this would still require rewriting the URI (not sure if that's what you're opposed to).

ataxia’s picture

I'm having a lot of trouble with this, and I really need to get it working before my site can go live.

I've tried all different mods to the cdn.module, using what I've read above. It's a little better, but not perfect.

Right now:

► Images in nodes are working (served from CDN.)

► Fieldfield images uploaded into node fields are working.

► Images in nodes displayed in Views are not working, however, when I display the same node outside the View, they do originate from CDN.

► Images in Blocks are not working.

What I'd like to know is whether there is an easier way to force an image to come from CDN in Blocks and Views than having to do this:

$file_uri = file_create_url('/sites/xxx/files/images/myimage.png');
<div class="test-icons">
	<a href="http://www.facebook.com" target="_blank"> <img alt="Facebook" src="<?php echo $file_uri; ?>" /></a><br />

Note: The block must be set to use PHP as an input format.

This method does work, but it is a lot of overhead for each image that appears in each Block and each View.

Is there any other way to force an image to originate from the CDN server?

I'd love to use something simple like rel="cdn-image"

or possibly a url formatted like this: cdn://sites/xxx/files/images/myimage.png

Do you have any updates on this issue?


jeremyjohnstone’s picture

This problem was reported TEN MONTHS AGO... Had this module been marked as alpha, or dev, or whatever this might be acceptable, but this module is riddled with show stopper bugs which make it completely unusable. "beta" means mostly working but might have some edge cases, not "hey, we threw some characters in a file and /think/ it might work".

vabue’s picture

Same problem with the latest dev-version of CDN module.

Settings are:

http://img.ktc-ua.com|.jpg .jpeg .gif .png .ico

JS are not working at all, CSS — partly:

<link type="text/css" rel="stylesheet" href="http://www.ktc-ua.com/sites/default/files/css/css_P6yHAA0SDurrEnzgBFIzoWvEDFu6vo9GQvOmKudRAvo.css" media="all" />
<link type="text/css" rel="stylesheet" href="http://www.ktc-ua.com/sites/default/files/css/css_UjDxV0XgMs2yOf03yPhHydjobnl4dmSe-nPnlSOpiVQ.css" media="all" />
<link type="text/css" rel="stylesheet" href="http://www.ktc-ua.com/sites/default/files/css/css_XKK5FTyQdu1KkCAT0bEH0zZWllqZhG9y0fJ1B0yqyXQ.css" media="all" />
<link type="text/css" rel="stylesheet" href="http://www.ktc-ua.com/sites/default/files/css/css_25Wxk3Hob6AiJrdhGxf8THl_aVi6B0kzsyUGY-xgpo4.css" media="all" />
<link type="text/css" rel="stylesheet" href="http://css.ktc-ua.com/sites/all/modules/admin_menu/admin_menu_toolbar/admin_menu_toolbar.css?ltma6h" media="all" />
<link type="text/css" rel="stylesheet" href="http://www.ktc-ua.com/sites/default/files/css/css_WP0bBUjC1fRvZCGhTduCqL8E3EsmyihaNAStQCtdKQM.css" media="all" />
<link type="text/css" rel="stylesheet" href="http://www.ktc-ua.com/sites/default/files/css/css_47DEQpj8HBSa-_TImW-5JCeuQeRkm5NMpJWZG3hSuFU.css" media="all" />
<link type="text/css" rel="stylesheet" href="http://www.ktc-ua.com/sites/default/files/css/css_47DEQpj8HBSa-_TImW-5JCeuQeRkm5NMpJWZG3hSuFU.css" media="all" />
<link type="text/css" rel="stylesheet" href="http://www.ktc-ua.com/sites/default/files/css/css_47DEQpj8HBSa-_TImW-5JCeuQeRkm5NMpJWZG3hSuFU.css" media="all" />
<link type="text/css" rel="stylesheet" href="http://www.ktc-ua.com/sites/default/files/css/css_izbERYgpu9HiKM_VQCChNFLtI6ziQCnWT8sdHHPlzgo.css" media="all" />
<link type="text/css" rel="stylesheet" href="http://www.ktc-ua.com/sites/default/files/css/css_HefOFz0zWhCg_UZnLpquNqAyCwxBGPw6gC-JXoJargo.css" media="all" />
<link type="text/css" rel="stylesheet" href="http://www.ktc-ua.com/sites/default/files/css/css_5_EBsvYf_U3gqgv1Idal1sImw7zcXB1kaIR6NOugp8o.css" media="print" />

(you can check it on www.ktc-ua.com).
CSS & JS aggregation are enabled. Caches were flushed.
Interesting, that even display suite based nodes, which has images inside are not transferring to another domain. For example.

Corwin’s picture

It seems like the problem is the CDN module does not work on any files located in sites/default/files/. CSS Aggregation puts the files there and they don't work, and a dozen images on my site that are also located there do not get a CDN subdomain either.

Example (I did /${mydomain}/site/):

Corwin’s picture

vabue: Did you remove *.js from the blacklist?

dropbydrop’s picture

I hope this essential module will be fixed!

greggles’s picture

could someone give this a more descriptive title? I feel like some of the comments are misplaced confusion about how to configure the module and some are accurate bugs. A title like "d7 problems" makes it hard to fix the bugs associated with the specific patches in #12 and #19.

dropbydrop’s picture

Title: D7 problems » cdn module does not work for most the files
Version: 7.x-2.0-beta1 » 7.x-2.x-dev

With the following settings
http://cdn.site.com|.css .jpg .jpeg .png

It works for only few image files that their path was hard coded in the theme.
It does not work for imagecache images
It did not work for css files either.

So for me this module does not work at all, although it is so necessary.
I hope since January 2011 that this will be fixed sometime in the future.

rjbrown99’s picture

Title: cdn module does not work for most the files » Drupal 7 problems

Setting the topic back.

greggles’s picture

Title: Drupal 7 problems » CDN module doesn't work for public:// files

@rjbrown99 - you set it back to a worse title ;)

We need descriptive titles to make progress in issues.

Steven Jones’s picture

So we found that the patch in 12 worked for us, except that file URLs weren't escapsed properly, so here's a patch that does that.

dropbydrop’s picture

why this patch is not integrated into the module dev version?

greggles’s picture

@wim leers: can you give more details on how they are insufficient? They seem like they provide some progress so it's worth committing them even given that they are partial fixes.

Berdir’s picture

Status: Needs work » Needs review
2.86 KB

The patch explicitly supports public only, which is wrong and the original code uses parse_url() for something that might or might not be one, which is wrong as well :)

Attaching an alternative patch, that is working well for us with an alternative stream wrapper (hash://).

It's a bit hackish as well, because it generates the external URL and then removes the base url again, but it is workin fine here.

The patch is much longer, but that is only because I use $real_path to not accidently override the path.

fboulais’s picture


bibo’s picture

I would really appreciate this getting fixed. I've kind of boasted about how great and easy this cdn module is.. or has been on Drupal 6 sites. But currently I cant say the same about D7.

dropbydrop’s picture

Yes, it's almost a year since first posted.

bibo’s picture

Status: Needs review » Reviewed & tested by the community

..and to help this case move forward: #43 works fine for me!

Marking this as RTBC :)

obrienmd’s picture

Agreed, #43 RTBC.

conspirolog’s picture

#43 works

dropbydrop’s picture

why this is not published in the module? where is the maintainer? :)

Kars-T’s picture

This is opensource and the work is done on voluntarily basis. So please be kind and respectful. Wim did 4 weeks ago the last commit and will be around for sure I'd say. Otherwise please open up a thread if you want to be co maintainer and work it out. Maybe take a look at this. But I don't think it applies. http://drupal.org/node/251466

BartVB’s picture

#43 works for me, haven't had time to review it yet but this makes the CDN module much more effective.
Also needed it for a hash:// like schema.

dropbydrop’s picture

Of course, I am kind and respectful. That's why I smile since 1 year ago, when I have opened this issue!

I m just wondering why the ready patch is not included in the module. Does it need extra work done?

Thanks for the provided link. I will look at it.

Happy New Year! :)

ywarnier’s picture

On a public:// config with a single CDN (conveyor), patch in #43 made the CDN-managed resources go from 39/62 to 61/62. Don't know for multiple CDNs, but #43 definitely works for me. Thanks!

max84’s picture

#43 works fine for aggregated css and js files.

But included files into body / content (jpeg for example) with relative path don't use CDN.

obrienmd’s picture

Wim responded to my e-mail saying he hopes to get this looked at soon.

max84: Do you mean included in markup, rather than using Drupal methods (imagefield via formatters or views, drupal_add_css, _js, etc)? I think that crawling content and pushing inline assets not added via Drupal methods would be really hard / not performant / not really needed, as CDN is usually used for sites of the size that proper inclusion methods would be used.

Mohammed J. Razem’s picture


#43 worked great for me also.

@max84: I guess included images in body with relative paths are meant to be NOT servered from CDN. Instead, if you use Media module to embed images in body/content it will seamlessly be served from CDN with #43 patch.

Wim Leers’s picture

Status: Reviewed & tested by the community » Fixed

I know I've failed miserably at keeping my Drupal projects up-to-date. I apologize for that.

Patch rerolled. Renamed $path to $uri for consistency with file_create_url(). I don't think $real_path is truly necessary, so I've removed that.

Committed right away with my changes: http://drupalcode.org/project/cdn.git/commit/3fe41d8. It works fine on http://wimleers.com — yes, that implies that CDN integration also didn't work properly on my own site! Please let me know if there are problems with the modified patch I've committed, I promise I'll fix them much faster this time…

Berdir’s picture

It should really use a different variable IMHO.

The problem is this line:

$uri = str_replace($GLOBALS['base_url'] . base_path(), '', $wrapper->getExternalUrl());

This essentially already overrides the $uri and changes it from the something://bla.bla to the absolute bath based on the current base_url. Because $uri is by reference, this already alters it.

If we later on decide to not use the CDN, e.g. based on the file ending, we still changed the $uri and this could possibly mess something up. Because maybe there is another alter hook that jumps in after us and then fails because of our weird rewrite.

Wim Leers’s picture

You're of course right.

I've re-implemented this like in your original patch in #43, but with more sensible variable names ($real_path was ambiguous IMO). I'm also passing the original $uri to _cdn_devel_page_stats().


greggles’s picture

Status: Fixed » Needs work

per #59.

Wim Leers’s picture

Status: Needs work » Fixed

Already fixed in #60 :)

bibo’s picture

Thanks Wim and other people involved in fixing this :)

obrienmd’s picture

Yes, many thanks! Hopefully we can get a new 7.x stable release now, as this was the last critical.

Status: Fixed » Closed (fixed)
Issue tags: -CDN

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