CDN for Joomla!

Issues Only with woff, woff2, and ttf files

4 months 3 days ago #78126

Omar Ramos's Avatar Omar Ramos

So the plugin for the most part appears to work once I activate it, however the only resources that don't seem to be loadable when the plugin is active is the woff, woff2, and ttf files and Chrome provides the following error message:
"Access to Font at '<resource_url>' from origin '<our_website>' has been blocked by CORS policy: "No Access-Control-Allow-Origin' header is present on the requested resource. Origin '<our_website>' is therefore not allowed access."

I've been attempting to troubleshoot it from a few different angles, but haven't been successful just yet.

Initially, since this is using Azure's CDN, the plugin was configured with our azureedge.net hostname (e.g. example.azureedge.net).

I thought that maybe using the custom domain feature would help fix the CORS issue automatically, but after switching things over to use our custom domain the CORS issue has persisted.

Next, I took a look at it from the server side. We have a hybrid setup with Apache+Nginx where Nginx is handling the static files so I've made some changes there, but so far that hasn't seemed to help much either (I had already tried adding your example htaccess code provided elsewhere too, but then I remembered Nginx was probably handling the serving for the files anyway which is why it wasn't having an effect):

location ~* \.(eot|otf|ttf|woff|woff2)$ {
    add_header Access-Control-Allow-Origin *;
}

I've taken a look at some of the options on the Azure CDN side of things, but am not sure yet if there's something I need to adjust on that end that can help with the issue.

Just wondering if you might have any insight on whether the CORS issue is something I have to fix on my end on the server (in the Nginx config) or if it's something that might be an issue on the CDN side of things?

Thank you!

4 months 3 days ago #78127

Peter van Westen's Avatar Peter van Westen Admin

4 months 3 days ago #78129

Omar Ramos's Avatar Omar Ramos

Hi Peter,

I'm not sure if the FAQs completely address this sort of issue (and in particular the font-face suggestion in the FAQ is not easily accomplished if using a template from RocketTheme I believe, or in the case of another font file I'm seeing that's not being served related to our use of DOCman).

On my end I'm seeing if the issue is due to Azure CDN (I was originally using the Standard Plan, but their Premium Plan offers some additional ability to overwrite headers so I'm waiting for it to be fully provisioned and will re-test to see if those changes help out).

If they do I'll report back.

4 months 3 days ago #78130

Omar Ramos's Avatar Omar Ramos

It seems like the additions I made recommended on their CORS page related to the Premium Plan are helpful so far:
docs.microsoft.com/en-us/azure/cdn/cdn-cors

I'm still seeing a couple of CORS errors but at least some of them are being loaded now (in the example below the muli-regular-webfont.woff?5a75d5ff file is loaded but the light ones all show a CORS error but it seems like the rules are redundant so maybe that's why it's only loading one of them. (the issue doesn't occur when the plugin is disabled though).

@font-face{
    font-family:"muli";
    font-style:normal;
    font-weight:400;
    src:url('../fonts/muli/muli-regular/muli-regular-webfont.eot#iefix') format("embedded-opentype"), url('../../fonts/muli/muli-regular/muli-regular-webfont.woff2?5a75d5ff') format("woff2"), url('../../fonts/muli/muli-regular/muli-regular-webfont.woff?5a75d5ff') format("woff"), url('../../fonts/muli/muli-regular/muli-regular-webfont.ttf?5a75d5ff') format("truetype"), url('../../fonts/muli/muli-regular/muli-regular-webfont.svg?5a75d5ff#muli') format("svg");
}
@font-face{
    font-family:"muli";
    font-style:normal;
    font-weight:300;
    src:url('../fonts/muli/muli-light/muli-light-webfont.eot#iefix') format("embedded-opentype"), url('../../fonts/muli/muli-light/muli-light-webfont.woff2?5a75d5ff') format("woff2"), url('../../fonts/muli/muli-light/muli-light-webfont.woff?5a75d5ff') format("woff"), url('../../fonts/muli/muli-light/muli-light-webfont.ttf?5a75d5ff') format("truetype"), url('../../fonts/muli/muli-light/muli-light-webfont.svg?5a75d5ff#muli') format("svg");
}

I'll keep on playing with it to see if I can get the other CORS issues for the light fonts to go away too but it might not be too critical of an issue.

On a related note though, the plugin configuration shows that PDF files should be processed through the CDN, but since the majority of our PDFs are contained within DOCman (and all of the view URLs for DOCman end in "/file" when using SEF URLs) is there a way that those can be potentially cached using the plugin easily?

4 months 3 days ago #78131

Peter van Westen's Avatar Peter van Westen Admin

Whether or not the loading of files from the CDN server work, is outside the control of CDN for Joomla!
That is down to the CDN provider.

CDN for Joomla! simply converts urls to local media files to the CDN equivalent urls.
It cannot handle non-file-type urls like you mention DocMan uses.