Sage 9 main.css 404 on devUrl

hi
I try use sage [9.0.0-beta.3]
yarn run start
Created new window with browsersync at http://localhost:3000/ (Here everything works fine)

But on the “devUrl”: “http://sage48.dev” I can’t load:
GET http://sage48.dev/wp-content/themes/zelenbud/dist/styles/main.css → 404 Not Found
GET http://sage48.dev/__webpack_hmr → 404 Not Found

Can I have the ability to write a stylesheet or pass it to the main site?

my resources/assets/config.json:

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

Did you run yarn build at least once? If not, try that. start injects the styles into the browser but doesn’t actually create main.css. build will create the file.

2 Likes

@MWDelaney
yes build works good, but it not use --watch
If I add --watch to build
"build": “webpack --progress –watch --config resources/assets/build/webpack.config.js”,
This will start the browsersync

Is it possible to start --watch without browsersync?

-- watch isn’t one of the available build commands in Sage 9.

What is your goal here? Why are you trying to start a watch command without browsersync?

I experience the same thing on a fresh Sage theme with Foundation framework.

Yarn build creates the main.css. But on the next yarn start, the dist folder is deleted and rebuild with only the scripts folder. Not the styles folder.

In the backend at posts and pages I get a wp notification: Failed to load content css: http://mysite.dev/app/themes/mytheme/dist/styles/main.css

1 Like

Yes, this is intended behavior because of the way webpack works. main.css is compiled and injected by webpack during yarn start and you will always get a 404 message for main.css when using yarn start.

If you run yarn build you won’t get this message, but you also won’t get browsersync and live-preview of your changes.

Is something not working? Do the styles not appear? Or is the 404 message the driving concern here? If it’s the 404 message, then this is working as intended --the intended workflow is to use yarn start during development to see your changes in a browser as you save your work. If something else is broken, can you describe what it is?

7 Likes

I see, thanks for the explanation. The constantly reappearing backend notification is slightly annoying, but not really a problem. I’m only recently switching to Sage 9, guess I’m still used to 8’s ways.

Anyway, don’t want to further hijack webspilka’s thread :slight_smile:

When I run yarn run start. I can work only with http://localhost:3000/, my main site “http://sage48.dev” does not load styles.
Ideally, I would like both sites to work simultaneously. But I think this is probably impossible?

So I decided to add another mode
For example
yarn run build:watch
I want to test main site “http://sage48.dev” without proxy (browsersync), but with webpack --watch.

For this I add to package.json

"build:watch": "webpack --progress --watch --config resources/assets/build/webpack.config.js",

but –watch option in webpack start browsersync

In webpack.config.js I find

if (config.enabled.watcher) {
  webpackConfig.entry = require('./util/addHotMiddleware')(webpackConfig.entry);
  webpackConfig = merge(webpackConfig, require('./webpack.config.watch'));
}

I think if I rewrite this code, I will turn off browsersync
I think if I rewrite this code my main site “http://sage48.dev” will work with webpack --watch.

Or is there a simpler solution add webpack --watch for main domain?

I’m not familiar enough with the intricacies of configuring webpack to advise you on adding a command, but may I ask why you need this to work with your sage48.dev URL? I don’t see an advantage, considering both it and localhost (with browsersync running) display the same content.

If use http://localhost:3000/ and Front-end content Editor (For example: WP Quick FrontEnd Editor – WordPress Plugin – WordPress plugin | WordPress.org) I get http://localhost:3000/ based urls in wordpress database

Don’t edit content within a Browsersync session, or do a find and replace

1 Like

If someone also needs a watch without Browsersync
You can just slightly edit
resources/assets/build/webpack.config.js

     new ExtractTextPlugin({
       filename: `styles/${assetsFilenames}.css`,
       allChunks: true,
+      // disable: (config.enabled.watcher)
     }),

...

     new webpack.LoaderOptionsPlugin({
       minimize: config.enabled.optimize,
+      // debug: config.enabled.watcher,
       stats: { colors: true }
     }),

...

// and add comments to :
// if (config.enabled.watcher) {
//  webpackConfig.entry = require('./util/addHotMiddleware')(webpackConfig.entry);
//  webpackConfig = merge(webpackConfig, require('./webpack.config.watch'));
// }

After this watch will work without Browsersync start

I went further
Replaced config.enabled.watcher to my variable config.enabled.bsenable

// watch and Browsersync:
"start": "webpack --env.bsenable=true --hide-modules --watch --config resources/assets/build/webpack.config.js ", 

// only watch
"build:watch": "webpack --watch --config resources/assets/build/webpack.config.js",

"build": "webpack --config resources/assets/build/webpack.config.js",

And I got what I wanted
Thanks to all

4 Likes

Then IMHO we should use a simple console message or a comment in main.css or a section in docs so those of us who’re not coming from frontend background can understand such behavior happening via webpack.

3 Likes

I get this behavior but i’m not seeing any styles in my browser.
I deleted my dist, deleted my node_modules, ran yarn, ran yarn build and the dist appeared styles included, then i ran yarn start and dist is replaced with new dist without the styles. And no css appears in browser.

I get this error in the console:
Uncaught Error: Bootstrap dropdown require Popper.js (https://popper.js.org)
at bootstrap.js:1414
at bootstrap.js:1823
at Object. (bootstrap.js:3831)
at Object.webpack_exports.a.init (bootstrap.js:3831)
at webpack_require (bootstrap 9248746d73a54aa87581:659)
at fn (bootstrap 9248746d73a54aa87581:85)
at Object. (main.js:1)
at Object. (main.js:25)
at webpack_require (bootstrap 9248746d73a54aa87581:659)
at fn (bootstrap 9248746d73a54aa87581:85)

I get this warning in the console:
(index):28 Resource interpreted as Stylesheet but transferred with MIME type text/html: “http://localhost:3000/”.

This i s what the link tag looks like in the header, with a warning triangle:
<link rel='stylesheet' id='sage/main.css-css' href='http://framja.dev/wp-content/themes/framja/dist/styles/main.css' type='text/css' media='all' />

And no errors in the terminal.

Is there any chance you tried to update Sage from an earlier beta to Beta 4? I think we’re seeing a few threads about the same issue over the last few days about how WordPress gets confused when updating Sage in-place.

Nope, not yet. I’m new to Sage and don’t yet know the best way to update.
I am using beta 3.

I can confirm that on beta 4, that main.css is still being requested by the browser.
When running run start the dist folder is trashed, and only scripts are generated. This is “how webpack works” as mentioned as earlier, I get it. But it’s not a great development experience.

Screen capture here

3 Likes

I personally don’t think it’s a bad dev experience in general. It’s just a matter of knowing how to use these tools, which can feel like a lot in the beginning, but it all makes sense once you get into it.
The whole point of working with webpack is to have both js and css server from memory and not local files, until you actually run the build process. If you want to avoid the request for the style.css when it’s not being created, simply change your setup.php to perform a check if the file exists. Hopefully this will be clearer to all users once the docs are all up to date and published :slight_smile:

2 Likes

I’m not sure what the problem is here? Why is it not great?

The documentation doesn’t show that users should ignore webpack hot module loader errors and 404 errors.
It’s in the chrome console in the video I supplied.

1 Like