I am trying to use Font Awesome on my website. I am testing that site on a local Apache2 webserver. When I view that site as served by my local Apache webserver, the Font Awesome icons display as little boxes.
However, if I view that same file just by the relevant web page from my file system (I'm using Ubuntu 16.10), they display fine.
Further, I have another web server running NginX, and if I upload my HTML and CSS files there, and view the page, the Font Awesome icons display fine.
In other words, it appears that only Apache can not load the Font Awesome files. If I look at the network response in Firefox's developer options, I see this error:
404 Not Found
The requested URL /icons/fontawesome-webfont.ttf was not found on this server.
Why is Apache2 not finding the Font Awesome files when NginX and my local file system have no problems?
For reference, this is the relevant CSS:
#font-face {
font-family: 'FontAwesome';
src: url('../icons/fontawesome-webfont.eot?v=4.2.0');
src: url('../icons/fontawesome-webfont.eot?#iefix&v=4.2.0') format('embedded-opentype'), url('../icons/fontawesome-webfont.woff?v=4.2.0') format('woff'), url('../icons/fontawesome-webfont.ttf?v=4.2.0') format('truetype'), url('../icons/fontawesome-webfont.svg?v=4.2.0#fontawesomeregular') format('svg');
font-weight: normal;
font-style: normal;
}
Related
I have a web page that contains an iframe, and within the iframe is an object with a src= attribute of an svg file that displays properly when I serve the page from localhost (running apache 2.4 on Windows 10). But when I serve the same page from an Amazon Linux instance, also running apache 2.4, the svg file for the object is rendered as text. I'm quite sure the pages are the same, because the content of the htdocs tree is managed by git, and I make changes on the Windows 10 PC and commit them, then push and pull them onto the Amazon Linux machine.
I've attached two screenshots of what I see in Chrome Developer Tools for the same page on the two systems. As you can see, on the PC, the <object> expands into a #document followed by an <svg>. But on Linux, the <object> expands into a #document followed by <html>, with the source code of the svg file wrapped in a <pre> tag within the <body>. How is this even possible?? I'm using the same Chrome bowser instance, the only difference is which server is serving the page.
I offered Danny '365CSI' Engelman the opportunity to post his comment as an answer, but he didn't take it, so I'll post the answer myself. My problem was that the Apache server I was using had a rather old mime.types file in the etc directory of its configuration (I was using xampp, which has its own etc directory packaged with it). That old version of mime.types did not have an entry for .svg files. Replacing it with a newer version from svn.apache.org, and restarting the server, solved the problem.
I found this quite surprising, since my <object> element had an attribute of type=image/svg+xml, which is the same as the type given in the updated mime.types file. Surprising because the file command on the server recognized the file as having that mime type. And so the lack of an entry for .svg in the mime.types file actually caused apache to ignore the type attribute on the object element, and render the content of the object as text!
What is the problem
I recently gave theme support access to backoffice, but all they did is nothing and messing up my backoffice.
I'm using Prestashop 1.7.6.0 (and for some reasons I can't switch to newer version, so update is not an option). Everything was fine, but now I discovered that some backoffice pages (products, brands, attributes) are totally messed up. Looks like it lacks bootstrap, but I have no idea how to make it work.
As far as I know they were supposed to turn on SSL, but looks like domain still lacks certificate. Maybe because of turning it on, everything is messed up?
I have turned off cache and cache/smarty/ catalogs are clear, except index.php file.
Things I did:
Console showed 4 errors. They were about missing fonts (404 error), included in theme.css (see below).
#import url(//fonts.googleapis.com/css?family=Open+Sans:400,400i,600,700);
#import url(//fonts.googleapis.com/css?family=Ubuntu+Condensed);
#font-face {
font-family: Material Icons;
font-style: normal;
font-weight: 400;
src: url(e79bfd88537def476913f3ed52f4f4b3.eot);
src: local("Material Icons"), local("MaterialIcons-Regular"), url(570eb83859dc23dd0eec423a49e147fe.woff2) format("woff2"), url(012cf6a10129e2275d79d6adac7f3b02.woff) format("woff"), url(a37b0c01c0baf1888ca812cc0508f6e2.ttf) format("truetype")
}
.material-icons {
-moz-osx-font-smoothing: grayscale;
I found all included fonts in admin/themes/default/public and copied them to admin/themes/new-theme/public
Errors disappeared from console. It repaired icons, but problem still occurs:
Where troubleshooting led me
theme.css on broken subpages is incorrect. Even if I don't have any cache and tried using private tab couple times - it does not match real file on FTP.
Here is screenshot of theme.css from sources tab on broken page:
And here is confirmation of same file with different content in FTP:
I don't have any caching on server - nothing!
Also when I copy correct theme.css content into wrong one in sources page (which is supposed to be correct, because it's same file!) - subpage is 100% working in a flash. Unfortunately only local.
I even tried to attach this file via direct URL, as you can see in screenshot below - it didn't helped. (Highlighted line is original link rel, which leads me to good path file, but still with wrong content).
Have you tried to clear the cache after turning it on the SSL? — it can also cause the problem.
At first glance, it looks that have bootstrap loaded, but some other CSS is not loaded correctly.
If you look at the console window(F12), you can see the resources the page could not load. That might help to diagnose the problem.
After founding out that theme.css is different (still curious how it changed itself) and trying to replace it - I finally tried to remove it from FTP. After that I again cleared all cache, visited broken site without any CSS and then uploaded new one.
Maybe it was about some update or other stuff. However I copied theme.css from theme/default/public and placed it in theme/new-theme/public.
Now subpages are working correctly.
I use the Directadmin panel in the Centos 7 infrastructure.
I installed mod_pagespeed plugin for nginx_apache web service.
PHP Software works normally, but I have problems with the <script> and <style> tags embedded in the html code.
When these tags are in the code, the website opens as a white and blank page.
I couldn't find any log on this issue. Could you please help me?
I have a flask app running on an apache HTTP server on ubuntu 14.04. Everything works great, but I'm now trying to make things secure and get HTTPS up and running. The content still renders properly when requesting the HTTP URLs, but static CSS files are not loading when changing the prefix to HTTPS.
Some useful details and previous attempts:
I have the CSS files in the usual static/css location.
This answer was helpful, and got javascript rendering properly, but using AddType for CSS isn't working for some reason.
I tried sudo a2enmod mime to make sure that Apache module was enabled, and it was.
I tried forcing the type for css (similar to what was suggested here, but with css instead of js and javascript), but that didn't work either.
I've tried adding the AddType declaration to my configuration file located in /etc/apache/sites-available/FlaskApp.conf (that's where the successful AddType text/javascript .js declaration is located), and I've also tried putting the AddType declaration in a .htaccess file located in the root directory of my FlaskApp, but both attempts were unsuccessful.
Everything loads fine when accessing the site with the http:// prefix, just not the https:// prefix. I've tried accessing it from Chrome and Firefox.
Chrome Response
Looking at the console when loading the page in Chrome is shows the following for all CSS files:
Resource interpreted as Stylesheet but transferred with MIME type application/x-gzip
Looking at the network tab, everything looks similar between the http request and the https request, except that the https request is completely missing the Response Headers section.
When attempting to load just the /static/css/styles.css file in Chrome, it attempts to download the file instead of displaying it in the browser.
Firefox Response
When attempting to load just the /static/css/styles.css file in Firefox, it loads in the browser. However, it's not ascii text but rather jumbled characters as though it's loading a binary file. Here's the console error message in Firefox:
The character encoding of the plain text document was not declared. The document will render with garbled text in some browser configurations if the document contains characters from outside the US-ASCII range. The character encoding of the file needs to be declared in the transfer protocol or file needs to use a byte order mark as an encoding signature.
So my question is, how do I get my HTTPS/Flask/Apache/Ubuntu setup to properly return static css files so that my pages render properly?
This suggestion and this suggestion look promising, but I'm not sure how to make it so that any request that hits /static/css/*.css returns the proper css file with the "Content Type" or "mimetype" set correctly.
Dear stackoverflow experts,
I've been reading in stackoverflow forum about the issue but didn't find a solution
I'm experiencing a problem with my website https://baliradar.com
since I installed SSL. I changed all the http links by https.
However I cannot resolve the problem of insecure font though, here's the console log error message:
Mixed Content: The page at 'https://baliradar.com/' was loaded over HTTPS, but requested an insecure font 'http://fonts.gstatic.com/s/lato/v11/nj47mAZe0mYUIySgfn0wpQ.ttf'. This request has been blocked; the content must be served over HTTPS.
I have been searching for hours with FileZilla in the files of my theme "winning agent pro" and in other directories of my website but I never found the html code for the font. I tried to search for specific keywords ("fonts", "gstatic") in my File Manager from my CPanel but there's no records found.
I also tried to use the "Developer Tool" of Chrome to find the source of the font without success.
I'm clueless here and was wondering if someone has an idea or a solution?
Thank you for your time.
Xavier
There are several http:// links in your CSS code, which is linked in your header as <link
rel="stylesheet" type="text/css" href="https://baliradar.com/wp-content/cache/minify/000000/e4a39/default.include.08bf2a.css" media="all" />:
.mCSB_buttonRight{background-position:-80px -56px}#font-face{font-family:'Lato';font-style:normal;font-weight:300;src:local('Lato Light'), local('Lato-Light'), url(http://fonts.gstatic.com/s/lato/v11/nj47mAZe0mYUIySgfn0wpQ.ttf) format('truetype')}#font-face{font-family:'Lato';font-style:normal;font-weight:400;src:local('Lato Regular'), local('Lato-Regular'), url(http://fonts.gstatic.com/s/lato/v11/v0SdcGFAl2aezM9Vq_aFTQ.ttf) format('truetype')}#font-face{font-family:'Lato';font-style:normal;font-weight:700;src:local('Lato Bold'), local('Lato-Bold'), url(http://fonts.gstatic.com/s/lato/v11/DvlFBScY1r-FMtZSYIYoYw.ttf) format('truetype')}#font-face{font-family:'Lato';font-style:normal;font-weight:900;src:local('Lato Black'), local('Lato-Black'), url(http://fonts.gstatic.com/s/lato/v11/4cKlrioa77J2iqTqBgkRWg.ttf) format('truetype')}.currencyr{position:fixed;z-index:2147483647}.currencyr .currencyr-container,
As it seems that this is a minified version of your css, search in your current theme's css-files for the http phrase. You can do so using grep for example:
grep 'http://fonts' * -R
In my case, this issue was caused by my caching plugin (W3 Total Cache). Disabling it solved the issue but you may want to keep the plugin and change the font URLs in the CSS file from HTTP to HTTPS.
I came across this issue when the Social Pug plugin stopped showing
icons on the social media buttons. The root cause was the caching
enabled by W3 Total Cache plugin. If you are in a similar situation,
there are three ways to fix the issue:
Disable W3 Total Cache (not recommended because your website’s performance may decrease)
Change the font URLs of Social Pug plugin to HTTPS
In some cases, URL Rewrite rules may cause this issue. Check your .htaccess file
Mixed Content: The page was loaded over HTTPS, but requested an insecure font