I apologize if this is a repeat but I don't see anything on this. Since I have been playing with the CDN module and getting used to how it deals with things in conjunction with AdvAgg, I have had quite the crash course in the best configurations for CDNs.

But I have a stupid question because I keep seeing this in the stats:

Files not served from the CDN:
sites/default/files/

I am not sure what this is indicating. After this entry in the stats for the page, the rest of the files I would expect to be served from the CDN are listed.

Any ideas where I may have gone wrong with my config?

Comments

Wim Leers’s picture

Wim Leers
Location Ghent 🇧🇪🇪🇺
CreditAttribution: Wim Leers at Acquia commented
Status: Active » Postponed (maintainer needs more info)

Is that the only one listed as not being served from the CDN?

If so, you have a file URL somewhere that links to http://yoursite.com/sites/default/files/ — i.e. it points to the files directory, and doesn't point to an actual file. In all likelihood, this is a bug in one of your modules or themes :)

The CDN module cannot serve a file URL that doesn't point to a file but to a directory from the CDN, so … I don't think there's anything wrong here, nor anything harmful, other than a module/theme doing something wrong :) Perhaps this even points you to a bug!

I'd say, on the page where this is happening, view the source, and search for the string sites/default/files" — that should find the HTML that's creating this silly link, and will hopefully point you to the culprit.

Shane Birley’s picture

Shane Birley CreditAttribution: Shane Birley commented

This is interesting. The only URL (non-CDN) is the favicon.ico set to the TLD root.

http://www.example.com/sites/default/files/favicon.ico

This is a little weird, as I set in the CDN config that .ico should be served from the CDN. To rule out my being a dork, I decided to delete the favicon and upload a new one. I did this in the typical Drupal fashion by uploading the new icon within the theme system, nothing fancy.

Then it got a little weirder.

The CDN started reporting that the favicon was served from the CDN (and it rewrote the URL properly for the new .ico) but the files not served is still present.

There are a couple of other files that are being pulled in from other CDN locations (CC icon, etc). Is it possible that the CDN module is complaining about not being able to re-write those URLs?

Shane Birley’s picture

Shane Birley CreditAttribution: Shane Birley commented

I will also point out that the Files served from CDN do say that 100% are served. This is like a list of files that failed for whatever reason but the write to the screen doesn't realize the list is empty? Just a thought.

Wim Leers’s picture

Wim Leers
Location Ghent 🇧🇪🇪🇺
CreditAttribution: Wim Leers at Acquia commented

but the files not served is still present.

And what did it say? Still this: sites/default/files/?

I think the easiest way to get the bottom of this is to use a debugger and break when the sites/default/files/ case occurs. You probably want to do that in cdn_file_url_alter(). If you can't use a debugger, then do something like this:

if ($url_in_question === 'sites/default/files/') {
  var_dump(debug_backtrace(DEBUG_BACKTRACE_IGNORE_ARGS, 15));
  exit;
}

I suspect that some code is generating a faulty file URL (sites/default/files/) but then is not printing it anywhere in the HTML.

Shane Birley’s picture

Shane Birley CreditAttribution: Shane Birley commented

I am just getting back to this and something is different. The message has changed to:

Files not served from the CDN:
public://

I am looking to see what config I changed but I haven't been on the test site for a few hours. Brain... imploding.

Wim Leers’s picture

Wim Leers
Location Ghent 🇧🇪🇪🇺
CreditAttribution: Wim Leers at Acquia commented

Aha! public:// is translated to sites/default/files/! (i.e. public://llama.png is Drupal's server-independent representation for sites/default/files/llama.png).

So, something is trying to link to public://. But that doesn't make any sense. So you'll want to debug for that instead then.

Shane Birley’s picture

Shane Birley CreditAttribution: Shane Birley commented

It is crazy, it switched back to /sites/default/files again.

What I think I will do is clean up the setup and start over just to make sure I haven't gone over soething and screwed the config up. I will document and debug once I've done that.

We shall prevail...

Wim Leers’s picture

Wim Leers
Location Ghent 🇧🇪🇪🇺
CreditAttribution: Wim Leers at Acquia commented

Any news?

Wim Leers’s picture

Wim Leers
Location Ghent 🇧🇪🇪🇺
CreditAttribution: Wim Leers as a volunteer commented
Status: Postponed (maintainer needs more info) » Closed (cannot reproduce)

No replies in just under 5 months. Closing. Feel free to reopen if you have more information.

Shane Birley’s picture

Shane Birley CreditAttribution: Shane Birley commented

I was able to determine that CDN wasn't loading some of the root files properly. I suspect the issue was caching related but I wasn't able to determine that since I changed the CDN configuration slightly and started forcing "www" on the Drupal installation. I then did a CNAME for "www" and targeted those responses to be served entirely from the CDN (if not updated).

However, I do have other sites that are serving HTTPS based content and the module is serving those awesomely. This requires additional work, I think, but since I changed how the non-HTTPS serving is setup, I can't test it the way I was five months ago.