Compiled CSS doesn't work as it should in production

sage
,
1

Hello!
so, on prod, on my header the css is included on the file main_976c2861.css
but, that css file doesn’t have my custom changes (for example the code I added to global.scss).
My code is compiled into main.css, which is not minified.

So basically, after deploying (I’m doing it the old SFTP way for this project), the site looks broken, and to fix it I rename main.css to main_976c2861.css. But I’m sure this flow is somehow broken.

Any help please?

EDIT: just notices that this also happens with main.js and customizer.js files

2 Likes
2

Hi, it sounds like a caching issue.

Are you running gulp --production prior to deploying your changes?

If not, on your local, try running gulp --production and then upload the dist directory. See if that helps. Be sure to run gulp once more on your local before workign again.

1 Like
3

I’m doing yarn build:production, since I’m working with SAGE 9.
(should I have posted in another thread?)

4

No, no need to post in another thread, same concept.

5

If you delete the /dist directory entirely on production do the styles break as expected? You might need to refresh a few times, or clear cache, to confirm.

If that works, then try uploading the newly regenerated /dist from development.

1 Like
6

that’s correct.
I renamed /dist and the site reflected that.
I just uploaded a fresh copy and everything is fine :slight_smile:

this brought me to two new questions:

  1. I see that the images on /dist are generated with a hash, but my html still use the non-optimized version of the image (without the hash). Am I missing some step?
  2. is it OK to upload the /resources/assets directory? this way my scss files are exposed :confused:

thank you very much for your help!

7

Hi all, I just ran into this same issue. Everything works fine on development. When I run yarn build assets are compiled and things go great. Just tried to run a production version by running yarn build:production and the process went smoothly except that my custom changes were not included in the build.

So to be clear… the css file is built and it enqueues just fine. But when I check the content of that css file it seems to contain only the base Bootstrap styles. (I also noticed the JS file was completely empty.)

Makes me wonder what is the difference between build and production that might cause the compiler to skip over my custom styles? Am I missing a config setting somewhere ?

Has anyone else experienced this issue?

1 Like
8

Is this a Trellis install?

I’ve seen this in Trellis on occasion and have been able to kick it back in gear by renaming my .scss files and then renaming them back. It’s something to do with how the Vagrant box shares your local directories that gets stuck or confused. It might also work to vagrant halt && vagrant up but I didn’t get that far in troubleshooting before finding the renaming fix.

If it’s NOT Trellis, can you tell us more about the environment?

1 Like
9

I’m experiencing exactly the same issue. When running yarn build:production all custom styles get discarded. I notice the hash on the compiled css and js files is the same every time.

What I’ve tried:

  • Deleting the .cache-loader folder.
  • Renaming the scss files and back as you suggested.
  • Deleting node_modules and running yarn again.
  • Running vagrant halt and up again on my Trellis machine
  • Deleting the dist folder

Haven’t had this problem before with the beta of Sage 9.

2 Likes
10

I don’t have a Trellis install and I’m also not using Bedrock. This is my first go with Sage and I am loving it so far, but this is a head scratcher.

I’m using a pretty simple development setup on Codeanywhere with an Ubuntu server. As I mentioned, everything works fine in terms of the file enqueing and being served. It’s just not compiled correctly at build.

Here’s my test (other than just seeing the missing design):

  • Run yarn build and search the main.css file (the file itself and I make sure it’s served in the <head>) for some of my custom selectors. They are there and everything works fine.
  • Run yarn build:production and then search for the same selectors in the same manner and they are not there. So they are not pulled into the production compile. Strangely, the core Bootstrap css is there, so some files are getting pulled and compiled. Just not all.

I have already tried many of the same things mentioned by @kasperientje, but haven’t tried renaming the .scss files so I will try that. Thanks for the response. Let me know if you have any other ideas.

11

I know it can be tough to diagnose the problem if you can’t replicate it. I’ve been trying a few things and thought I would mention a few findings.

First, I did notice that for some reason one of my third-party modules was getting picked up and compiled into main (Fancybox). Thinking that perhaps that module was causing problems I deleted it and re-compiled without it. No change. Same error.

Second, I started hiding components in my custom scss just to see if any of them could be causing a problem. I did notice one thing interesting… if I delete my _variables.scss file then Webpack throws a build error that it can’t find certain variables. So it is grabbing the files and trying to compile them. It’s just that all my custom scss is not making it to the final build for some reason.

And again, running a simple yarn build everything works just fine and all my custom styles are included.

1 Like
12

Same issue here on a site I’m trying to deploy to staging. I’ve tried @MWDelaney’s advice,

• Rename .scss files, and then name them back
• vagrant halt && vagrant up

I haven’t found a solution yet, but meanwhile thought I’d post my deploy logs:

Deploy -vvv log (compile and copy assets)

Deploy -vvv log (compile assets - end)

I created a fresh Sage theme, made a custom style on it, deployed, and experiencing the same issue. So it’s got to be somewhere in Trellis? OP said he isn’t on Trellis/Bedrock, so I’m confused.

Still trying to debug this.

13

How about this: if you run yarn build:production do the styles in question work locally? Or is it only remote where they break?

1 Like
14
4 Likes
15

Thanks @ben. That workaround worked for me. Good to know.

16

@MWDelaney, it works locally, just not on deploys.

@ben’s link solved worked for me as well.

As @QWp6t points out in that thread, here’s how to fix it– add the following:

$navbar-dark-toggler-icon-bg: none;
$navbar-light-toggler-icon-bg: none;

to file: resources/assets/styles/common/_variables.scss

Thanks guys.

7 Likes
17

A ‘Clean’ Workaround

TL;DR

1.
In Your assets/styles/main.scss insert at the top of the file (yes, before @import "common/variables";, we need the functions for str-replace()):

@import "~bootstrap/scss/functions";
@import "~bootstrap/scss/variables";

2.
In Your styles/common/_variables.scss insert:

$navbar-dark-toggler-icon-bg:       url("data:image/svg+xml;charset=utf8,%3Csvg viewBox='0 0 30 30' xmlns='http://www.w3.org/2000/svg'%3E%3Cpath stroke='#{str-replace(str-replace(#{$navbar-dark-color}, "(", "%28"), ")", "%29")}' stroke-width='2' stroke-linecap='round' stroke-miterlimit='10' d='M4 7h22M4 15h22M4 23h22'/%3E%3C/svg%3E");
$navbar-light-toggler-icon-bg:      url("data:image/svg+xml;charset=utf8,%3Csvg viewBox='0 0 30 30' xmlns='http://www.w3.org/2000/svg'%3E%3Cpath stroke='#{str-replace(str-replace(#{$navbar-light-color}, "(", "%28"), ")", "%29")}' stroke-width='2' stroke-linecap='round' stroke-miterlimit='10' d='M4 7h22M4 15h22M4 23h22'/%3E%3C/svg%3E");

Detail

The Problem aren’t the spaces. The brackets from the stroke='#{$navbar-dark-color}' causes the problem. So if we str-replace() the ( with %28 and the ) with %29 you can run yarn run build:production without removing your scss.

2 Likes
18

This fires a stylelint error with the default sage settings:

resources/assets/styles/common/_variables.scss
10:212 :heavy_multiplication_x: Expected whitespace after “)” function-whitespace-after
11:214 :heavy_multiplication_x: Expected whitespace after “)” function-whitespace-after

If I add the whitespaces, it again ignores my custom sass. The other workaround works fine for me.

19

This same issue is also found on bootstrap 4.1 – just if somebody was wondering.

20

This is the solution.

thank you very much.