I am doing what I think is a standard Next.js build. It works fine in development mode but when I try to get a production build, I get:
(node:39333) UnhandledPromiseRejectionWarning: CssSyntaxError: <css input>:17:20: Missed semicolon
at Input.error (/node_modules/next/node_modules/postcss/lib/input.js:129:16)
But here is the strange things: I don’t have any CSS.
Actually, I had some CSS but I deleted it all to figure out what was going wrong. No change.
After an hour or so of frustration, I did what I should have done in the first 10 minutes, and edited the file postcss/lib/input.js to just print out the offending CSS, and got quite a surprise. Let me describe the sequence of events in the order they occurred, not the order I discovered them.
A few days ago, I received from the designer an HTML file with the layout she wanted. In the <head>, there were some <link>s to the fonts she had chosen, including:
<link
href="https://fonts.googleapis.com/css?family=FontAwesome"
rel="stylesheet"
/>
What I didn’t noticed (apparently the designer didn’t either) was that there is no such font-family (FontAwesome is the name of font toolkit), I dutifully copied the line into my React code. Next.js and the browser plowed right through the problem.
PostCSS did not. Instead, when attempting the production build, it tried to parse the error page that Google sent.
Unfortunately, the error page was, you know, just an error page. Nobody at Google had scrutinized it for strict standards-compliance. Sure enough, near the top I found:
body {
background: 100% 5px no-repeat;
margin-top: 0;
max-width: none:
That colon there at the end is supposed to be a semi-colon. Of course, removing the useless link to the nonexistent font solved the problem.
Now I don’t know who to blame:
Google for having a syntax error on an error page
Google for not running a check on their error pages
Google for returning a 400 instead of a 404 when it cannot find a font
PostCSS for trying to parse an error page (I don’t know if the 400/404 thing confused it, but still)
PostCSS for giving such an obscure error message
the designer for giving me a link to a bad font
Because, you know I am not blaming myself...
For people who couldn't still understand the issue or find out where's the mistake, check for any links like
<link
href="https://fonts.googleapis.com/css2?family=Roboto:wght#400;700&display=swap"
rel="stylesheet"
/>
Please make sure your weights are in ascending order or else it will throw 400 error from google and still show the same error from PostCSS
Following code solved my problem.
Pre:
<link
href="https://fonts.googleapis.com/css2?family=Monserat:wght#300;400;500;900&display=swap"
rel="stylesheet"
/>
Post:
<link
href={`https://fonts.googleapis.com/css2?family=Monserat:wght#300;400;500;900&display=swap`}
rel="stylesheet"
/>
Try this in your Next.js app:
<Head>
<link
href="https://fonts.googleapis.com/css2?family=Petrona"
rel="stylesheet"
/>
</Head>
Note that the only difference between your code and mine is: css2
Related
As the title states, I am getting the following three warnings in Chrome (latest version):
1) A preload for 'https://use.fontawesome.com/releases/v5.8.2/css/all.css' is found, but is not used due to an integrity mismatch
2) The resource https://use.fontawesome.com/releases/v5.8.2/css/all.css was preloaded using link preload but not used within a few seconds from the window's load event. Please make sure it has an appropriate as value and it is preloaded intentionally
3) A preload for 'https://use.fontawesome.com/releases/v5.8.2/css/all.css' is found, but is not used because the request credentials mode does not match. Consider taking a look at crossorigin attribute.
While I understand that these are not errors, do they represent a bigger issue or can it be safely ignored? I recently switched to https but to be honest, it might have been showing this in the chrome inspect window before this (I only saw it because I was checking the SSL post installation.
I have Googled parts of these warnings but havn't found anything. I used the "pasted into your head" method of adding Font Awesome, like this:
<link rel="stylesheet" href="https://use.fontawesome.com/releases/v5.8.2/css/all.css" integrity="sha384-oS3vJWv+0UjzBfQzYUhtDYW+Pj2yciDJxpsK1OYPAYjqT085Qq/1cq5FLXAZQ7Ay" crossorigin="anonymous">
Would appreciate a little feedback, thanks in advance!
This is due to your use of crossorigin="anonymous", and you can safely ignore these warnings, but they will be visible to your users, so it is best to correct the problems.
To do so, you'll want to ensure that your font is preloaded with the rel preload (with rel="preload"), and an as attribute declaring it as a font (with as="font").
This would look like:
<link rel="preload" as="font" href="https://use.fontawesome.com/releases/v5.8.2/css/all.css" integrity="sha384-oS3vJWv+0UjzBfQzYUhtDYW+Pj2yciDJxpsK1OYPAYjqT085Qq/1cq5FLXAZQ7Ay" crossorigin="anonymous">
I've decided to add SRI to our CDN scripts, but I want to test if it's working. If I manually change the hash the script still loads. I'd be expecting some kind of error code or something in the console.
So for instance, this is the correct hash:
<script crossorigin="anonymous" integrity="sha256-ZosEbRLbNQzLpnKIkEdrPv7lOy9C27hHQ+Xp8a4MxAQ= sha384-nvAa0+6Qg9clwYCGGPpDQLVpLNn0fRaROjHqs13t4Ggj3Ez50XnGQqc/r8MhnRDZ sha512-jGsMH83oKe9asCpkOVkBnUrDDTp8wl+adkB2D+//JtlxO4SrLoJdhbOysIFQJloQFD+C4Fl1rMsQZF76JjV0eQ=="
src="https://code.jquery.com/jquery-1.12.4.min.js"></script>
If I then change the first characters in each of the sha hashes to:
<script crossorigin="anonymous" integrity="sha256-YosEbRLbNQzLpnKIkEdrPv7lOy9C27hHQ+Xp8a4MxAQ= sha384-mvAa0+6Qg9clwYCGGPpDQLVpLNn0fRaROjHqs13t4Ggj3Ez50XnGQqc/r8MhnRDZ sha512-iGsMH83oKe9asCpkOVkBnUrDDTp8wl+adkB2D+//JtlxO4SrLoJdhbOysIFQJloQFD+C4Fl1rMsQZF76JjV0eQ=="
src="https://code.jquery.com/jquery-1.12.4.min.js"></script>
I would expect it to fail. But it doesn't. Tested in Firefox 58.0.2 and Chrome 64.0.3282.140, both of which support SRI. Caching is turned off and I can see in the developer tools that the script is being re-fetched each time.
Is there anything else I can do to verify that SRI is being used? Have I fundamentally misunderstood something...?
I've tested it with some style sheets and it seems to be working there, including the Console in Firefox reporting:
None of the “sha384” hashes in the integrity attribute match the content of the subresource.
It's also far more obvious the stylesheets haven't loaded. I think there must be a caching issue with scripts.
So the thing is, since I moved my resources (css, images, js) to resources/static folder my stuff started working.
Until I created a new .html page (meant to be dynamic) and pasted in resources/templates. Then all my resources (css, images) stopped working (can't be found) and I can't make it work again.
I'm using SpringBoot + Thymeleaf and the code can be found at GitHub
I couldn't manage to find a solution after 3 hours of searching, that's why I'm here. Thank you, hope you guys can help :/
Edit (some images):
My project structure
The link:
<link href="css/bootstrap.min.css" rel='stylesheet' type='text/css'/>
<link href="css/bootstrap.css" rel='stylesheet' type='text/css'/>
What happens (was working before, I didn't change anything in the code of listed images)
I'm not sure what happened but after starting deleting/commenting some code I wasn't using anymore I started to get errors and managed to track the next file to "fix" (delete or comment) and after that it worked again.
Looks like something in the application wasn't right and it didn't give me any erros so I had to manually try to find it.
I'll keep updating this thread if I find anything useful related.
I am not sure what's going on, but my personal site - built with Jekyll and hosted on Github pages - has been exhibiting odd css styles behavior as of the last few weeks or so.
I originally set it up on Jekyll 1.something-or-other. I am aware that it is at 3.something now and for the longest time, through 2 etc. I have not had a problem with the styles, everthing was fine up until less than a month ago.
I have not made any changes to the styles configuration for a couple years, but now it is only rendering the styles for the pages (Homepage, About Page, list pages for archives, etc.). But on the actual posts, it drops all the styles - looks like raw markdown and images and no layout.
I have updated jekyll to 3.1.2 on my local machine, and what's even stranger is that when I run it locally, it builds fine and all, but the problem is the opposite. That is, all the posts are formatted with the appropriate styles, but the pages (again - Homepage, about page, archive list) are unstyled.
Again, no changes in any configurations. Is there some obvious places I should be looking? I am using the jekyll bootstrap theme that's a little customized. but not much.
Site is http://subtxt.in
I found your repo and poked around. There is a lot going on there, it seems overly complex.
Using Chromes dev tools you can see the problem is with the css loading - on good pages the correct path is: <link href="/assets/themes/the-minimum/css/style.css" rel="stylesheet" media="all">
On posts where it doesn't work it is: <link href="/assets/themes//css/style.css" rel="stylesheet" media="all">
Note the missing theme name - the-minimum.
In your repo I can't quite figure out the logic, but you could simplify it I think. This file - _includes/themes/the-minimum/default.html I believe contains the head section for all pages.
The line <link href='{{ ASSET_PATH }}/css/style.css' rel="stylesheet" media="all"> I think is the problem, `ASSET_PATH seems to come back with different values. Try just hard coding it to be the correct path like:
<link href="/assets/themes/the-minimum/css/style.css" rel="stylesheet" media="all">
I'm not 100% sure this will fix it, but I think it will.
I would add a link to your repo if this doesn't fix it for you so other people can check it.
I have a website hosted by siteground, and my custom 404 page is SOMETIMES missing it's stylesheet. I contacted support but they saw it working fine, assumed I just codded it wrong, and told me to get help form a professional web programmer... (of course I did test before contacting them to be sure it was not my fault)
Anyways, the way that siteground allowes you to create a custom 404 page is to add your html code to a form in your control panel, wich creates a 404.shtml in your main folder. The .shtml contains all your html. I have done the following test to narrow down the problem.
created a not404.html in my main folder with code copy pasted from my 404.shtml that is in the same folder. It loaded with my stylesheet applied no problem.
tried prompting a 404 page with both bad hyperlinks, and by typing pages that do not exist. When I am having the problem with my stylesheet missing, none of thease pages have css, but when I am not having the problem, they all have css applied.
What I think it is: I think that the 404.shtml is not really in my main folder, but just appears to be there, and sometimes that link breaks and the 404.shtml is actualy acessed somewere else on sitegrounds server, therefor the style link would not work properly. This would explain the intermittent css failor. But this is just logic, not understanding.
The only thing I can think of that would be wrong on my end is if there is more than one way to link stylesheets, and my way is a bit unstable. Here is the format I use.
<link type='text/css' rel='stylesheet' href='css/404.css'>
I know this might be a difficult question, but it would be pretty satisfying to figure this out and inform them of the problem with their site.
Change the href for the style tag to be absolute. So this:
<link type='text/css' rel='stylesheet' href='css/404.css'>
Becomes this:
<link type='text/css' rel='stylesheet' href='/path/to/css/404.css'>
css/404.css is a relative path. If the path is something like /path/to/nonextant/page it will try to load the stylesheet from /path/to/nonextant/page/css which does not exist.
Use an absolute path:
/css/404.css