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 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.
Comment | File | Size | Author |
---|---|---|---|
#43 | use_scheme_correctly.patch | 2.86 KB | Berdir |
#40 | cdn-1025762-40-stream-wrappers.patch | 764 bytes | Steven Jones |
#19 | 1025762-d7-problems-18.patch | 755 bytes | logii |
#12 | 1025762-d7-problems-12.patch | 652 bytes | rwohleb |
Comments
Comment #1
Wim LeersThanks 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.
Comment #2
dropbydrop CreditAttribution: dropbydrop commentedoriginal 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
Comment #3
Wim LeersThat's very odd. I will try to reproduce this.
Comment #4
JMParsons CreditAttribution: JMParsons commentedThe 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:
In it's simplest form this would work:
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:
Comment #5
timmillwoodI think I have a similar issue, therefore. Subscribing.
Comment #6
dropbydrop CreditAttribution: dropbydrop commentedIf 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
Comment #7
rwohlebSubscribe.
It does seem like this is an issue with public:// streams.
Comment #8
dropbydrop CreditAttribution: dropbydrop commentedwhat are public streams and how I can fix them?
Comment #9
rwohlebIt's not something you can do. It's something in code.
Comment #10
dgastudio CreditAttribution: dgastudio commentedbefore activate CDN
after activate CDN
as u can see, the image location has been changed, but image link still the same.
it's something that i'm doing wrong?
Comment #11
dropbydrop CreditAttribution: dropbydrop commentedWhen this is expected to be fixed?
Comment #12
rwohlebHere 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.
Comment #13
bigsyke CreditAttribution: bigsyke commentedUnfortunately 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'
Comment #14
mrfelton CreditAttribution: mrfelton commentedI'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.
Comment #15
bigsyke CreditAttribution: bigsyke commentedhmmm... 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.
Comment #16
Docc CreditAttribution: Docc commentedsub. Patch 12 seems to work for me (serving all from 1 cdn)
Comment #17
BenK CreditAttribution: BenK commentedSubscribing
Comment #18
ahwebd CreditAttribution: ahwebd commentedSubscribe
Comment #19
logii CreditAttribution: logii commentedPatch 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.
Comment #20
rjbrown99 CreditAttribution: rjbrown99 commented#12 and #19 were very helpful and are working for me. Thanks.
Comment #21
dropbydrop CreditAttribution: dropbydrop commentedIs it possible the patched to be applied to o the module and issue a new version? thanks
Comment #22
dropbydrop CreditAttribution: dropbydrop commentedAfter 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!
Comment #23
dstolDitto on #22 and #19 is definitely needs work.
Comment #24
zwoop CreditAttribution: zwoop commentedSame problem here : Subscribe.
Comment #25
dropbydrop CreditAttribution: dropbydrop commentedThis 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.
Comment #26
Wim LeersSorry for the enormous delays. Unfortunately, neither patch fully and properly addresses the problem, hence I cannot just go and commit either one.
Comment #27
dropbydrop CreditAttribution: dropbydrop commentedthanks for the update.
I hope this issue gets fixed soon.
Comment #28
bjuncosa CreditAttribution: bjuncosa commentedSo 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?
Comment #29
bjuncosa CreditAttribution: bjuncosa commentedWould 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).
Comment #30
ataxia CreditAttribution: ataxia commentedI'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:
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!
Comment #31
jeremyjohnstone CreditAttribution: jeremyjohnstone commentedThis 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".
Comment #32
vabue CreditAttribution: vabue commentedSame problem with the latest dev-version of CDN module.
Settings are:
JS are not working at all, CSS — partly:
(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.
Comment #33
Corwin CreditAttribution: Corwin commentedIt 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"
Comment #34
Corwin CreditAttribution: Corwin commentedvabue: Did you remove *.js from the blacklist?
Comment #35
dropbydrop CreditAttribution: dropbydrop commentedI hope this essential module will be fixed!
Comment #36
gregglescould 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.
Comment #37
dropbydrop CreditAttribution: dropbydrop commentedWith 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.
Comment #38
rjbrown99 CreditAttribution: rjbrown99 commentedSetting the topic back.
Comment #39
greggles@rjbrown99 - you set it back to a worse title ;)
We need descriptive titles to make progress in issues.
Comment #40
Steven Jones CreditAttribution: Steven Jones commentedSo 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.
Comment #41
dropbydrop CreditAttribution: dropbydrop commentedwhy this patch is not integrated into the module dev version?
Comment #42
greggles@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.
Comment #43
BerdirThe 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.
Comment #44
fboulais CreditAttribution: fboulais commentedSubscribing.
Comment #45
bibo CreditAttribution: bibo commentedI 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.
Comment #46
dropbydrop CreditAttribution: dropbydrop commentedYes, it's almost a year since first posted.
Comment #47
bibo CreditAttribution: bibo commented..and to help this case move forward: #43 works fine for me!
Marking this as RTBC :)
Comment #48
obrienmd CreditAttribution: obrienmd commentedAgreed, #43 RTBC.
Comment #49
conspirolog CreditAttribution: conspirolog commented#43 works
Comment #50
dropbydrop CreditAttribution: dropbydrop commentedwhy this is not published in the module? where is the maintainer? :)
Comment #51
Kars-T CreditAttribution: Kars-T commented@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
Comment #52
BartVB CreditAttribution: BartVB commented#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.
Comment #53
dropbydrop CreditAttribution: dropbydrop commented@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! :)
Comment #54
ywarnier CreditAttribution: ywarnier commentedOn 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!
Comment #55
max84 CreditAttribution: max84 commented#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.
Comment #56
obrienmd CreditAttribution: obrienmd commentedWim 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.
Comment #57
Mohammed J. Razem+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.
Comment #58
Wim LeersI 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 withfile_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…
Comment #59
BerdirIt should really use a different variable IMHO.
The problem is this line:
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.
Comment #60
Wim LeersYou'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
Comment #61
gregglesper #59.
Comment #62
Wim LeersAlready fixed in #60 :)
Comment #63
bibo CreditAttribution: bibo commentedThanks Wim and other people involved in fixing this :)
Comment #64
obrienmd CreditAttribution: obrienmd commentedYes, many thanks! Hopefully we can get a new 7.x stable release now, as this was the last critical.