Sage 9 main.css 404 on devUrl

sage9
browsersync

#21

While I understand that the docs are still not fully up to date I believe everyone has made an exceptional effort in spreading the knowledge and assisting the others here on Discourse. A little patience goes a long way :slight_smile: Things are changing and while it can be frustrating at times (been there!) it’s for the best, for a much more enjoyable developer experience a far superior products for our clients! :slight_smile:


#22

Im sorry but i really don’t get it. I see styles when i do a build (like visual styles in the browser window) and then when ever i run start all styling disappears (like visually nothing but browser default). I can see that it’s watching for changes and rebuilding when i make changes in my scss, but no styles, nothing.

/ Lost noob


#23

Which address are you pointing your browser to? You should be able to see all changes when pointing to the Browsersync session on localhost:3000


#24

Looked at both the devUrl http://framja.dev and http://localhost:3000, but get no styles.
I can see the styles after a build in the devUrl, but then when i start , nothing.

My config.json:

{

“entry”: {
“main”: [
"./scripts/main.js",
"./styles/main.scss"
],
“customizer”: [
"./scripts/customizer.js"
]
},
“publicPath”: “/wp-content/themes/framja”,
“devUrl”: “http://framja.dev”,
“proxyUrl”: “http://localhost:3000”,
“cacheBusting”: “[name]_[hash:8]”,
“watch”: [
"{app,resources/views}/**/*.php"
]
}


#25

I too was began to experience this issue with the latest Bootstrap 4 Beta release. I ended up downgrading to the latest alpha release which isn’t dependent on popper.js. I downgraded by running yarn remove bootstrap and then yarn add bootstrap@4.0.0-alpha.6.

Obviously, this is merely a short term solution (unless you want to go into production with the Bootstrap alpha) so I’d be grateful if someone were able to demonstrate how to resolve the popper.js dependency issue.


#26

I don’t believe there is still a dependency problem with popper.js. This was resolved in Sage9 with this PR. What problem are you seeing?


#27

Well, for example you’re developing on both mobile and desktop and you want to see changes on both devices. This is one of the core browsersync functionalities. This works for me using Laravel Mix and Browsersync on other projects, I’m not really sure why this does not work with sage.


#28

This does work with Sage. I’ve done this. What problem are you having and what have you tried?


#29

Here are the steps I took:

  1. Install sage through composer from dev-master
  2. cd to sage, yarn, yarn build
  3. Go to wp admin and set the theme to sage
  4. Confirm it works going to example.dev
  5. yarn start
  6. :3000 page opens up, Connected to Browsersync notification
  7. Change background-color of body to blue in .scss, save it
  8. Webpack compiles, browsersync refreshes, background changes
  9. Open the :3000 page on mobile, Connected to Browsersync notification, background is blue, everything as expected so far
  10. Delete the background-color rule, save it.
  11. Webpack compiles, on both devices I get “Rebuilding…” and “webpack bult [some hash] in 4000 ms” notifications, but only on desktop the background changes back to white, on mobile it stays blue.
  12. Refresh the page on mobile, get Connected to Browsersync notification, but this time .css fails to load completely, I get default text styles and colors (should be formatted by bulma)
  13. Stop yarn, run yarn build and yarn watch afterwards, refresh the mobile browser, get the bulma styling, but the described behaviour persists

I also get the brief flash of completely unstyled page when I refresh the browser on desktop. I’m not sure, but I don’t think this is the way Browsersync and Webpack should work. 4+ second compilation time suggests me there might be somehing wrong in the build pipline, I’d suggest giving laravel mix a try.


#30

AAAH thank you!!! This worked for me!
Finally i can start making things pretty.


#31

Same situation.
I have to re-run ‘yarn start’ or ‘yarn run start’ to see changes by main.scss itself or in descendants.
How you solved that?


#32

I was able to temporarily fix it by downgrading to bootstrap 4 alpha-6 from beta as @robertsargent mentioned in a previous comment above.

Not a permanent fix thoug :frowning:


#33

Downgrading bootstrap doesn’t work for me… :frowning:


MIME type ('text/html') not a supported stylesheet MIME type
#34

The problem I experience with this is I have 2 browser tabs open when developing: 1) example.dev/wp-admin for backend WP business, and 2) localhost:3000 for seeing the frontend with my changing styles and content.

It’s lose-lose in the backend. Either I access the backend via localhost:3000 and receive errors such as the customizer not displaying the frontend because it violates a CSP that is expecting all URLs to originate from localhost:3000, or I access the backend via example.dev and am constantly presented with a red banner across the middle of the screen when editing a post/page that warns, “Failed to load content css: https://example.dev/app/themes/example-theme/dist/styles/main.css”.


Consequences of absent main.css with 'yarn start' (Sage 9)
#35

There are a couple of discussions on GitHub about using Laravel Mix in lieu of the resources\build webpack stuff. I am using it, as well as @Log1x, who has some fine configuration examples.

Check out an ongoing issue/discussion for sage-installer #1 Laravel Mix on how to get started using it.

Personally, I am using Bootstrap 4-beta with no problems. BrowserSync with a tunnel. Not trapped into having main.css or main.js for distribution. PostCss. Yada, yada. It is all very configurable without tons of coding for your build.


#36

Hey there.
Still the same issue…

Yarn run start is NOT building the CSS. It process the Scripts and images, but not the styles… Have to run build to get my CSS updated. Crazy !


#37

Unrelated to this topic, which is all over the place and almost a month stale, so I’m locking this :slight_smile:


#38