http://drupal.org/project/css_emimage could perfectly complement the CDN module. However, if CDN module is enabled, the functionality of CSS Embedded Images module is broken.

How to observe the bug:

  1. Enable CSS Embedded Images module and check that it embeds all (small) images loaded by CSS, lowering the number of images to be served separately (which is a gain with small images)
  2. Enable CDN for images, in origin pull mode, with fake or proper CDN. You will see that the CDN serves all images, even those that should have been embedded.

Not absolutely sure whether it's a bug of CDN or of CSS Embedded Images, so see also #1264582: Does not work with CDN module

Comments

Wim Leers’s picture

Category: bug » feature

It's probably because Drupal doesn't really support altering CSS, so one has to use hacks to be able to do it in the first place. Probably the CDN module's hack overrides the css_emimage module's hack.

See css_emimage_theme_registry_alter() and cdn_element_info_alter().

It's likely that the best/only way to solve this, is by letting the css_emimage module define an API that the CDN module can use. From a quick look, it looks like I can use _css_emimage_process() to make this happen.

Definitely not a bug, but a feature.

This is a low-priority patch to me. I can't give an ETA, so it may be months until I get to this. Please either contribute a patch or sponsor it.

Vacilando’s picture

Thanks for looking into this, Wim.

With respect to the low priority, which I respect, let me document a use case which probably is rather common.

On a page I am optimizing I am loading about 27 images. All of them are on a CDN "img.MYCDN.TLD". However, because of the "connections per hostname" browser limitation, only 6-8 (depending on browser) are loaded in parallel.

The thing is that 18 of the images come from the theme's CSS and they are all very small -- ranging from 100B to 3kB. So embedding these is a natural next step -- it would leave only 9 real images to download from CDN. This situation was the trigger for this issue.

I probably won't be able to dedicate enough time to study both modules in such depth so as to be able to see whose hack of CSS altering overrides what. But perhaps someone else, given the above use case, will.
(My next step will probably be using differnet CDNs for PNG, GIF, JPG and JPEG, etc., so as to bypass the "connection per hostname" problem. But it's suboptimal both in general and in my case, since most of the images I need to load are PNG.)

Wim Leers’s picture

I understand your use case. And it may be a use case that affects many (if not most) sites, but the fact remains that very few people actually use a CDN, and even fewer use the css_emimage module. Hence it's low priority.

Regarding your next step in your personal use case: it's possible to automatically distribute files (of the same type) over multiple CDNs/hostnames. You can do it today with cdn_pick_server() (see the README), but a patch is ready that makes this trivial: #1452092: Automatically distribute certain filetypes over multiple CDNs. If you could review it, I could finally commit it :) It's been ready for more than a month!

Vacilando’s picture

Yes, the usage of the CDN module is surprisingly low considering how much it can improve performance, and how well it is written. This is no flattery but a fact. [Perhaps many people are avoiding it because they think there's an equation between "CDN" and "A LOT OF MONEY". Maybe one thing you could do is to better advertise (on CDN project page, README.txt, ...) the option of fake CDNs which still help a lot and cost nothing (e.g. http://runeforge.net/tutorial/utilizing-an-fake-cdn-to-boost-drupals-pag...)]. This is also why the project Parallel was discontinued in favour of this module.

Thanks for the tip regarding cdn_pic_server() -- I will certainly test that. It's one of the few features I haven't tested/used. I will also test the patch as well; thanks for bringing it to my attention!

Wim Leers’s picture

I guess I should blog about it :) I've been meaning to do that for a long time. 2.4 versus 1.x now has an impressive list of new, useful features, so :)

Wim Leers’s picture

Status: Active » Postponed
Vacilando’s picture

Friendly, silent en innocent... bump? (Could help me and others SO much!)

:-)

Wim Leers’s picture

I really can't do this right now — maybe this weekend.

Wim Leers’s picture

Version: 7.x-2.4 » 7.x-2.5

Anyone else who can look into this?

Wim Leers’s picture

I looked at CSS Embedded Images.

For sites not using the CDN module, it is doing the only way it can do it: it overrides CSS aggregation. However, what it really is doing is just altering the default URLs that point to images and fonts to data URIs. I.e. … a task that really should be performed through hook_file_url_alter()! The problem is that Drupal 7 core does not yet route every URL that is in a CSS file through a file_create_url() so the CDN module has to override CSS aggregation to do just that.

The solution is for the CSS Embedded Images module to depend on the CDN module and then it will simply have to implement hook_file_url_alter().

Wim Leers’s picture

Title: Breaks functionality of CSS Embedded Images module » Integrate with CSS Embedded Images module
Version: 7.x-2.5 » 7.x-2.x-dev

Ideally, we will fix this in one of the next Drupal 7 releases, once that is done, the CSS Embedded Images module only needs to implement hook_file_url_alter() and this will be a problem of the past.

Wim Leers’s picture

mrP’s picture

Nice work Wim.

mikeytown2’s picture

With AdvAgg 7.x-2.x and changes to css_emimage so it uses AdvAgg hooks; CDN and CSS Embedded Images module work fine together. Will be releasing code for this soon.
AdvAgg + CDN: #1942230-6: CDN module AdvAgg 7.x-2.x Integration
AdvAgg + css_emimage: #1968998: Get a 7.x version out that works with Advagg 7.x-2x

Wim Leers’s picture

Issue summary: View changes
Status: Postponed » Closed (won't fix)

Facts:
Considering #1961340: CSS aggregation breaks file URL rewriting because it abuses it got committed to D8 almost 3 years ago, but still hasn't been committed to D7, this is extremely unlikely to ever be committed to D7.
Drupal 8 is out and in Drupal 8, the css_emimage module can in fact do this using hook_file_url_alter().
For Drupal 7, see #14.

Together, that forces me to conclude this is a won't-fix.