CurlyPage partially incompatible with CDN (without blacklisting files)

Wow. Fast response. I didn't think you'd write a patch so quickly. Having a option is definitely better, but I didn't think you'd want to write it. I feel bad, because if I'd known you'd get back with a patch so quickly, I'd have hacked the module just to do a test and see if it worked before you did any work.

I tried it out, but for some reason, even with allowScriptAccess as "always", it's still not working. I've just spent a few hours trying to research and debug it, but I'm not able to find a reason. Based on the Flash documentation, that should allow for the SWF from a different domain to execute JS on the page with the crossdomain.xml policy in place.

Our client is happy with how I have it running now, so I can't justify spending much more time on it. I was just thinking it might be nice for others in the future if those files could be hosted via CDN. I don't expect you to put any time into debugging it either.

Since that doesn't work, I think the best choice is then to use hook_cdn_blacklist(). I think it's good to blacklist by default, since it leaves CurlyPage working with CDN right away without additional configuration.

There's a whitelist available on CDN, so people who didn't want to blacklist the CurlyPage files for some reason could whitelist them. Or you could have a configuration option that would enable/disable blacklisting. The config option would be less efficient performance-wise, but would be a little more user-friendly, since you could explain the reason for the blacklist in the option info, such as "Add CurlyPage files to CDN blacklist." "Disabling this may cause CurlyPages not to load. Due to cross domain security in Flash, when CurlyPage files are served from a different domain or subdomain it can not function." You could use module_exists('cdn') to make the field hidden from users who don't use CDN so as not to confuse them about what it does.

In hook_cdn_blacklist(), you'd have:

curlypage_cdn_blacklist() {
  $blacklist = array();
  //if there's config option, get config value for whether to blacklist file
  //get the file locations used by curlypage
  //add patterns for files to array, such as $blacklist[] = '*curlypage/*';
  return $blacklist; 
}

You could add '*curlypage/*' to the blacklist array, which is how I added them to the blacklist to get it working on the CDN. That takes care of the files within the module directory and those that are uploaded I think, since they appear to always go under a curlypage. I see there's a "Allow media paths" option that lets you add a file from any location. If you want to take care of those, they'd have to be included individually.

You could even leave the ability to turn on allowScriptAccess : 'always' in case that works for other people. It probably won't help anyone though if didn't work in this case. Just throwing out some ideas...

Yep. Patch works fine. Each time I changed between enabled/disable blacklist, I had to clear the site's cache before the changes took effect though.

cache_clear_all(); didn't make a difference when executed after submit. drupal_flush_all_caches(); made the settings take effect when executed after submit.

Details about what I tested:
I put settings back to original configuration: CDN enabled and none of the files blacklisted so it didn't work. After installing the patch, I checked "Enable CDN blacklist". Refreshed page with CurlyPage and saw no change. Cleared site cache and CurlyPage loaded.

I also tested adding a file path or the Unpeeled image using the input box that's enabled from "Allow media paths". I used a file path outside the ~/sites/default/files/curlypage directory. In CurlyPage settings for CDN Blacklist, I entered a pattern to match the new file path. This worked also after clearing the cache.

I enabled and disabled the blacklist multiple times and checked the HTML source with the expected results. With blacklist on, the full URL to the files included the current site's domain. With blacklist off, the it had the CDN domain.

Then I disabled CDN under that module's settings. CurlyPage was still working. Just to cover all bases, I also disabled the CDN module, and CurlyPage was still working.

Yep. Tested it in all the on/off modes again. It works now when changes are made without needing to manually clear the cache.

Thanks.