After doing a few and simple css edits on a Big Commerce site, the search and cart icons suddenly disappeared. They are now displayed as strange characters.
I went into the Big Commerce design backend and did not find anything strange into the code. When inspect the html and css code in the browser the icons are called properly:
<i class="fa fa-search"></i>
What could be wrong? Url to the site is Url
template demo url is enter link description here
Any help is much appreciated, new to Big Commerce.
This can happen when you edit CSS files for the first time. If you download all the theme files and reupload the font-awesome or font folder to WebDAV, that should resolve.
This is what I got from console.
Font from origin 'http://cdn4.bigcommerce.com' has been blocked from
loading by Cross-Origin Resource Sharing policy: No
'Access-Control-Allow-Origin' header is present on the requested
resource. Origin 'http://hearneseed.com' is therefore not allowed
access. The response had HTTP status code 404.
You're linking to a file that does not exist on the server. Also you may want to read up on the Same-Origin Policy!
Here's the official link to the Font-Awesome library. (Don't hyperlink! Download it, host it on your server and link to it that way!)
http://fontawesome.io/
http://fontawesome.io/assets/font-awesome/css/font-awesome.css
Related
Im grabbing image src from url and the image doesnt show on the page. If I go to the inspector and click on the img url it shows up on the new tab just fine. Also if I right click the "img not there" img, and open image in new tab it also shows just fine. It says in the network tab that there is a 404 but im just confused why it says that cause if I click the url for the src it shows up. I learned a little about CORs and nothing ive tried for that has worked so far. Made a free account for webhosting here thinking maybe something more real would work but same thing. https://funkocollector.x10.mx/ You can try searching for like Luke and see the other images dont load as well.
inspector showing src is correct
Network tab showing 404
Image showing up not on http
Image not showing on localhost
You are correct; this is most likely a CORS block. Just to be sure, check for a CORS protocol error message in the Inspect screen.
The CORS (cross-origin resource sharing) protocol limits what you can link to from your http server for network security reasons. Your link may or may not be blocked depending on the type of file and the settings of the server you are linking to. You have 2 solutions, both relatively simple:
Quick fix: since you can open the image source, simply download the file to your computer and upload onto your server. Change the href to your own site.
Long-term solution: get an ssl on your server. If you’re registered with dns, get cloudflare for your server. You’ll then be accessible as https, and CORS won’t be a problem.
I am unable to load a font file for my WordPress website. This happens specifically in Chrome browsers, Safari and others don't seem to share this issue.
The font files are located on the same folder where the rest of the assets and public files are contained. These load without any problem, images, css, javascript etc. Only font files seem to cause this problem.
The console shows the following error:
Access to font at 'https://example.com/wp-content/uploads/2019/08/font-file.otf' from origin 'https://www.example.com' has been blocked by CORS policy: No 'Access-Control-Allow-Origin' header is present on the requested resource.
As stated before, in other browsers, like Safari, the fonts load with no problem. I would like to solve this issue so it works across all browsers.
Check wordPress address and site address in your blog Settings > General settings.
Here whole answer:
https://wordpress.stackexchange.com/questions/278512/access-to-font-not-allowed-by-cors-policy
just noticed on several websites that the font awesome icons aren's showing in Google Chrome. The console shows the following error:
Font from origin 'http://cdn.keywest.life' has been blocked from
loading by Cross-Origin Resource Sharing policy: No
'Access-Control-Allow-Origin' header is present on the requested
resource. Origin 'http://www.keywest.life' is therefore not
allowed access.
I found the exact same issue on several other sites. This can be easily fixed by replacing the own CDN reference with:
//maxcdn.bootstrapcdn.com/font-awesome/4.2.0/css/font-awesome.min.css
-however, this is not the solution, just a workaround. I would love to know the reason and the right solution.
(the cause is this: the website is using it's own CDN, provided by MaxCDN and has the reference to the font awesome fonts and these are not loaded by Chrome, if you are loading the same resource from the Bootstrapcdn resource -mentioned above- it works)
here is a n example of the issue (in the menu and the social icons in footer: http://www.keywestnight.com/fantasy-fest )
Thanks for any help/explanatioon!
Here is the working method to allow access from all domains for webfonts:
# Allow access from all domains for webfonts.
# Alternatively you could only whitelist your
# subdomains like "subdomain.example.com".
<IfModule mod_headers.c>
<FilesMatch "\.(ttf|ttc|otf|eot|woff|font.css|css)$">
Header set Access-Control-Allow-Origin "*"
</FilesMatch>
</IfModule>
The problem isn't with the CSS file, it has to do with how the font file is served. The font-awesome.min.css file has lines like
#font-face{font-family:'FontAwesome';
src:url('../fonts/fontawesome-webfont.eot?v=4.2.0');
src:url('../fonts/fontawesome-webfont.eot?#iefix&v=4.2.0')
format('embedded-opentype'),url('../fonts/fontawesome-webfont.woff?v=4.2.0')
format('woff'),url('../fonts/fontawesome-webfont.ttf?v=4.2.0')
format('truetype'),url('../fonts/fontawesome-webfont.svg?v=4.2.0#fontawesomeregular') format('svg');
font-weight:normal;
font-style:normal}
which cause the browser to request an appropriate font file (eot, woff, ttf or svg) from the same server as the CSS file. This is logical and correct.
However, when the browser requests that font file from cdn.keywest.life, it reads the headers for a Access-Control-Allow-Origin header and doesn't find one so it gives that error message. (This seems like a browser bug to me because it's coming from the same server as the CSS file).
Instead, when you use maxcdn.bootstrapcdn.com the response includes the Access-Control-Allow-Origin:* header and the browser accepts this font file. If your cdn server included this header then it would work too.
If you have an Apache server, see this answer: Font-awesome not properly displaying on Firefox / how to vend via CDN?
This issue of accessing font-awesome assets has been a problem for many people without a comprehensive explanation and resolution to the problem.
What is CORS:
Cross-Origin Resource Sharing (CORS) is a mechanism that uses additional HTTP headers to let a user agent gain permission to access selected resources from a server on a different origin (domain) than the site currently in use. A user agent makes a cross-origin HTTP request when it requests a resource from a different domain, protocol, or port than the one from which the current document originated.
https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS
The Problem:
The problem stems from how the font-awesome fonts are loaded.
#font-face{
font-family:'FontAwesome';
src:url('../fonts/fontawesome-webfont.eot?v=4.2.0');
src:url('../fonts/fontawesome-webfont.eot?#iefix&v=4.2.0') format('embedded-opentype'),url('../fonts/fontawesome-webfont.woff?v=4.2.0') format('woff'),url('../fonts/fontawesome-webfont.ttf?v=4.2.0') format('truetype'),url('../fonts/fontawesome-webfont.svg?v=4.2.0#fontawesomeregular') format('svg');
font-weight:normal;
font-style:normal
}
The fonts are loaded via the stylesheet (CSS). The situation we have here is:
The Solution:
While CORS rules have been created on your file storage e.g. S3, and access to the resource has been given to the domain in question, when CDN tries to load the fonts specified in the CSS the origin/domain specified when loading these fonts is that of the CDN but no CORS access has given to the CDN domain.
Create a CORS rule for the CDN domain.
I use a CDN that doesn't allow me to modify its response, so I modified font-awesome.min.css, replacing relative path with absolute path and it worked.
None of the answers worked for me, I had to create an edge rule on maxcnd back office (which change config file on you zone)
More info here
https://www.maxcdn.com/one/tutorial/edge-rules-recipes/
https://www.maxcdn.com/one/tutorial/create-a-rule/
The solution to this is to use another cdn for fontawesome.
https://www.cdnpkg.com/font-awesome/5.11.0
If you're like me and using the official WordPress Font Awesome plugin, you'll want to go into settings and switch from "Use a CDN" to "Use a Kit".
My browser is session authenticated with a website.
I am using their API to pull down images from the site so I can display them on my page.
Visiting that image url displays the image, putting it in an img tag does not:
<img src = "https://files.something.com/123123" />><!-- this doesn't show -->
arse<!-- this works -->
Any ideas on why? and how I might overcome it?
If I put in http for the link, it redirects to https any way.
There's two things worth bearing in mind here:
Your host is automatically redirecting to https. Is this deliberate?
I suspect that you're seeing coming up against cross-domain security, or that your server is actively refusing it.
To trouble-shoot: you'll want to find out what response you're getting from your images.
Open up either the 'NET' tab in Firebug, or 'Network' in Chrome Developer Tools and watch the page-load. I suspect you're going to see those images come through red with an error number. Once you've got that it's very easy to trouble-shoot why the server's refusing to serve the images.
I've switched my Facebook page to pull an iframe as a result of Facebook's recent announcement that they were supporting iframes in pages. Since you need to host the iframe page outside of Facebook, I figured it would be nice to do using Cloudfront to host the files (an HTML page, a CSS stylesheet and a jpg image). Unfortunately, despite setting the permissions on the Cloudfront files to 744, the iframe page loads correctly in a browser, but when called from Facebook, I get this error message.
When I host the same files on my Media Temple server, the iframe on the actual Facebook page also loads correctly.
Is there a reason why Facebook and Cloudfront don't play together? I haven't been able to find one so far.
Unfortunately Facebook loads the iframe page using an HTTP POST, not an HTTP GET and is not compatible since Amazon has a REST interface and properly uses POST to upload/modify content.
Best,
David Bullock
I ran into this problem today and it caused some headscratching. As David Bullock points out the problem is that Facebook loads the HTML page via a POST request but S3 (and thus by extension CloudFront) won't serve resources in response to this (it returns 405 Method Not Allowed).
You can host your CSS, scripts and images on S3 / CloudFront, but the initial HTML page has to be on some other server. If you're concerned about load or latency from across the globe then you could try implementing a tiny redirector that forwards the Facebook POST request to the CloudFront-cached location (you'll have to return 303 See Other to do this redirection so the browser makes a GET request instead: see RFC 2616).
There is a shockingly easy workaround to the fact that AWS rejects POST requests and the fact that Facebook requires page tabs to be hosted via HTTPS: just redirect the request through https://bit.ly/….
Yes, it's really that easy.
Host the HTML page wherever you like. HTTP is fine.
Create a bit.ly-shortened URL to the page.
Use it—substituting https:// for http://—as the "Secure Page Tab
URL" as you create your Facebook Page Tab.
Activate the tab using this highly-undocumented dialog URL: https://www.facebook.com/dialog/pagetab?app_id=app_id&redirect_uri=bitly_url
Boom: done.
OK, it can be done: but you need to host the images on Cloudfront and the rest of the content on S3. Amazon provides a set of clear instructions on how to this. Issue solved.
Use Cloudfront to trap the 405 error and serve your html as the "Custom Error Response" page to the desired index page
Updated:
This was down voted, however I'm going to help lots of Facebook developers with the following. The final Issue that we had with hosting a facebook application on S3 was with CORS. We fixed the 405's by doing a "Custom Error Response" See this link for details:
http://blog.celingest.com/en/2014/10/02/tutorial-using-cors-with-cloudfront-and-s3/