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

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.

Comments

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.

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

original pull
http://cdn.example.com|.jpg .jpeg .png .gif .css
http://www.example.com
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

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

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);
}

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

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

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

Subscribe.

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

what are public streams and how I can fix them?

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

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?

When this is expected to be fixed?

Status:Active» Needs review
StatusFileSize
new652 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.

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'

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.

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.

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

Subscribing

Subscribe

StatusFileSize
new755 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.

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

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

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.
Thanks!

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.

Same problem here : Subscribe.

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.

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.

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

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?

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

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:

<?php
$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 />
</div>

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?

Thanks!

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

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

Settings are:

http://css.ktc-ua.com|.css
http://js.ktc-ua.com|.js
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.

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/):
"http://static1.site.com/sites/all/modules/interactive_map/js/jquery.maph...",
"http://static1.site.com/sites/all/modules/mollom/mollom.js",
"http://site.com/sites/default/files/jstimer/timer.js"

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

I hope this essential module will be fixed!

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.

Title:D7 problemscdn 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
http://www.site.com

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.

Title:cdn module does not work for most the filesDrupal 7 problems

Setting the topic back.

Title:Drupal 7 problemsCDN 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.

StatusFileSize
new764 bytes

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.

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

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

Status:Needs work» Needs review
StatusFileSize
new2.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.

Subscribing.

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.

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

Status:Needs review» Reviewed & tested by the community

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

Marking this as RTBC :)

Agreed, #43 RTBC.

#43 works

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

@dropbydrop
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

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

@Kars-T,
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! :)

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!

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

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.

+1

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

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…

It should really use a different variable IMHO.

The problem is this line:

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

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().

http://drupalcode.org/project/cdn.git/commit/6441028

Status:Fixed» Needs work

per #59.

Status:Needs work» Fixed

Already fixed in #60 :)

Thanks Wim and other people involved in fixing this :)

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.