The CDN module now also supports parallel downloading without requiring to use File Conveyor. You can use Origin Pull CDNs or just create new subdomains that point to your existing domain.

There's even more flexibility than what the Parallel module currently offers (see the attached screenshot).

Available in CDN 6.2 beta 6 and later.

What's holding us back from providing a migration path from the Parallel module to the CDN module? The only fundamental difference is that the CDN module requires a core patch (yet has better performance and is cleaner integrated), whereas the Parallel module uses the theme registry to achieve its goals (with worse performance, inevitably uglier code and most importantly: more compatibility issues: #918930: Favicon support patch, #749448: Lightbox compatibility : replace href tags and probably more).
I.e. CDN requires the user to be "experienced" enough to know how to patch core, but is (or at least should be) better, yet Parallel is easier to set up.

Module consolidation would make at least this aspect of Drupal easier. Thoughts? Maybe only merge in Drupal 7, where the CDN module will no longer require a core patch and thus its only drawback becomes moot?

CommentFileSizeAuthor
CDN mapping.png108.28 KBWim Leers
Support from Acquia helps fund testing for Drupal Acquia logo

Comments

mikeytown2’s picture

What if the CDN module had a no patch fallback? If one doesn't have patches enabled then it will fall back to using the theme registry. One other thing to consider is #750788: Make URL Assignment Balanced, rather than based on File Type.

If your willing to have a no hack fallback then I would be happy to migrate parallel into the CDN module. Could the theme trick be implemented in another module (bundled with CDN)?

mikeytown2’s picture

One other thing is Boost is "parallel aware". In short I know what domains the css & js files can be access from.

Wim Leers’s picture

I'd prefer to keep the CDN module as clean as possible, thus without the no patch fallback. But from a pragmatic point of view, it's absolutely necessary to *not* require the patch.
However, without the core patch, it becomes difficult/ugly (and possibly even bad performance-wise) to use the no patch approach, because you have to extend the string replacements to quite a few things: #918930: Favicon support patch, #749448: Lightbox compatibility : replace href tags. But it seems that you think that adding support for everything becomes overkill for the no-patch approach: http://drupal.org/node/749448#comment-2801474.

So maybe a nice middle ground is to use the no patch fallback as it is currently implemented in the Parallel module, and to tell users to apply the core patch if they want to replace 100% of the file URLs. What do you think?

Regarding #750788: Make URL Assignment Balanced, rather than based on File Type: people could achieve that today by writing a cdn_pick_server() function — see the "When using multiple servers: picking a specific one based on some criteria" section in README.txt.
However, if it is believed that this really should be available directly in the module (i.e. through the UI instead of through code), then this could be added in a next major release of the CDN module, since it's also not yet in the Parallel module?

Boost being Parallel aware seems to be the trickier problem to solve. I didn't know there was integration for that. Could you explain how this should work?

mikeytown2’s picture

Degraded functionality for those who do not use patches (what parallel is ATM) is a good compromise. In short, if you want 100% coverage, use pressflow. Despite all of the "issues" with parallel, it's still better then some of the alts (4x faster) out there.

cdn_pick_server function; make an image implementation of it. I would go for a filename to integer transformation $number = hexdec(md5($filename)); & then use modulus to figure out what server it should be served from. I've been spending most of my time with boost; thus parallel has been neglected.

Boost intergeneration is fairly easy; I just need to know the domains that the css/js files can live on.

Overall I give this a green light as long as we both understand that some people want this functionality without using pressflow and without a core patch; thus requiring a preprocess function.

Does CDN handle i18n domains well? I came up with some code that gets the TLD from the domain, although looking at this now I think this could be solved in an easier fashion. This is needed if your serving the same files off of your domain... cdn_pick_server might be able to solve it easier.

Wim Leers’s picture

Fully agreed. Works out of the box, without patching/Pressflow, but it won't serve all files from CDN. Want 100% coverage? Use Pressflow (or apply the core patch, but then you better be an advanced user).
In any case, this is now implemented: #938616: Provide a fallback mechanism that uses the theme layer to rewrite file URLs. It's not 100% the same as in Parallel because I want to apply CDN.module's more flexible rules, instead of providing only a CSS/JS/images domain. That makes sense, because otherwise I'd also have to copy the UI of Parallel, which would make the merging of the modules rather needless.

Example implementation of cdn_pick_server() that balances CDN assignment is now included in the README.txt file: #938638: Balance number of files served by each CDN instead of only looking at file type.

I've also implemented support for Boost integration: #938670: Allow for Boost integration: provide a public API function that returns all CDN domains. I've also created a corresponding Boost patch to take advantage of this: #938674: CDN module integration.

Fully agreed, and executed as per the three aforementioned issues.

CDN does not have any specific code for handling i18n domains. But it's such a seldom, special case that it would indeed be recommended to use cdn_pick_server().

Note: an example of a fairly advanced use case for cdn_pick_server() (back then still called cdn_advanced_pick_server() is the one described here: http://wimleers.com/article/drupal-6-cdn-integration-a-test-case#impleme...).

Now it's up to you again :) Looking forward to the next round of feedback!

mikeytown2’s picture

Quick glance at this.
All I can say is wow!!! awesome!
:)

Wim Leers’s picture

Great! :)

I'd appreciate it if you could give HEAD (i.e. the dev tarball) a quick try. If you can't find any glaring issues with it, I'll tag 2.0 RC2 :)

mikeytown2’s picture

If you can wait about 8 hours I can give this a run though.

Wim Leers’s picture

8 hours is fine — it's past 1 AM here and about bedtime, so I'll be waking up after that time I guess :)

Wim Leers’s picture

Thanks for the feedback to the respective issues, I've processed all of it. I've also implemented #939086: Allow cdn_pick_server() to be an actual function *or* some eval()'d PHP code, as per your request.

Anything else? :)

I think it's time to start thinking about Parallel's migration path to the CDN module. I propose you do a final stable release, in which users must run update.php. You provide an update function that migrates Parallel's variables to CDN's cdn_basic_mapping variable. You should end up with something like:

$mapping_entries = array();

$css_domain = variable_get('parallel_domain_css', FALSE);
if ($css_domain !== FALSE) {
  $mapping_entries[] = $css_domain . '|.css';
}

$js_domain = variable_get('parallel_domain_js', FALSE);
if ($js_domain !== FALSE) {
  $mapping_entries[] = $js_domain . '|.js';
}

$img_domain = variable_get('parallel_domain_img', FALSE);
if ($img_domain !== FALSE) {
  $mapping_entries[] = $img_domain . '|.jpg .jpeg .gif .png .ico';
}

// Only migrate settings to the CDN module if the Parallel module was actually
// being used.
if (count($mapping_entries)) {
  // Set the CDN module to "Origin Pull mode".
  variable_set('cdn_mode', 'basic');
  // Set the CDN module to "enabled".
  variable_set('cdn_status', 2);
  // Set the CDN module's CDN mapping based on filetype, to mimic the Parallel
  // module's behavior
  variable_set('cdn_basic_mapping', implode("\n", $mapping_entries));
  // Parallel module served *all* .js files from its JS domain, without
  // exceptions, so do the same in the CDN module, to provide an upgrade path
  // that works as expected by Parallel users.
  variable_set('cdn_exception_path_blacklist', '');
}
Wim Leers’s picture

Any news? :)

mikeytown2’s picture

No news is good news?

I hope to go though my modules and clear out and fix some issues so I can put a new release out for almost all of them this weekend. Parallel's migration might not make the cut for this week but I think the CDN module is ready to go if you want to do an RC2.

Wim Leers’s picture

Wim Leers’s picture

Vacilando’s picture

Excellent. Subscribing.

Wim Leers’s picture

Any news? No major issues have been reported with RC2, in fact, only one bug has been reported (#942668: Fallback mechanism despite running Pressflow), but that's related to File Conveyor mode, which very few people use. So the CDN module version 2.0 is almost ready, hence I'd like to see this move forward :)

mikeytown2’s picture

Sadly I'm still nursing a cold I caught this weekend; don't wait for me, I think its ready 2 go.

Wim Leers’s picture

How is your cold?

Currently at RC4, and no bugs have been reported :)

mikeytown2’s picture

cold is almost out... and the kicker is I'm on vacation till the 10th. I really hate it when things like this get delayed. Your call what you want to do. I think its ready 2 go. If not there can always be a 2.1 version of CDN.

Wim Leers’s picture

That's okay. :) And good luck with getting rid of that cold!

The CDN module doesn't need to be changed at all, all that's left to do is to provide the upgrade path inside the Parallel module. At least, that's how I see it. Do you agree?

Wim Leers’s picture

Any news?

mikeytown2’s picture

nope. hope to give the latest RC a spin sometime this week... got about 3 pages of issues I need to at least read & most likely comment on.

Wim Leers’s picture

Ok :)

Wim Leers’s picture

Just FYI, I extended the RC period for quite some more time, just to be sure. A few minor bugs were found & fixed. Some features were added. And the 2.0 final has been released a couple on December 1, a couple of days ago :)

Wim Leers’s picture

Any news? :) The 2.0 release has been out for almost two months now. And it's been doing well: there has been only one minor bugfix (installation failing if installed through an install profile).

mikeytown2’s picture

I can give you commit access to parallel. I've been creating more things... you might find this useful
http://drupal.org/project/imageinfo_cache

Wim Leers’s picture

Are you trying to say that you're EOL'ing this module?

I don't mind committing this patch and saying to people that they should switch to the CDN module for continued support and similar functionality in D7. But I won't continue development of this module. I'm sure you agree that's kind of pointless.

If this sounds okay to you, then sure, give me commit access and I'll commit this patch and reply to existing issues.

mikeytown2’s picture

End of life. With CDN doing everything, spending time here is pointless. Time spent on boost is smarter. You have FULL access, have fun and thanks again.

Wim Leers’s picture

Assigned: Unassigned » Wim Leers
Status: Active » Reviewed & tested by the community

Awesome, thanks! I've cleaned up the issue queue, and I've added a warning to the project page.

This week-end, I will complete the transition by committing this and transferring any information that the Parallel project page/README include that the CDN module doesn't have yet.

srobert72’s picture

Subscribing

Wim Leers’s picture

Status: Reviewed & tested by the community » Fixed

Committed.

http://drupal.org/cvs?commit=496104

1.0 final release will be up soon. Project page has already been updated. 2.1 release for the CDN module will also be up soon. Transition complete! :)

Wim Leers’s picture

Sister issue in the CDN issue queue: #1053540: Merge Parallel and CDN modules: migration path .

Status: Fixed » Closed (fixed)

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