BrowserSync not using main.css but main-xyz123.css instead


Disclaimer upfront: I am fairly new to roots (bedrock and sage) but love it so far.

I have several installs of bedrock + sage on my mac and do run things with MAMP (yes I know, there are better things but one can only learn so many things at a time). Things are working well except for in one install where I simply cannot get the BrowserSync to work. I have read through all the posts here in the forum regarding the similar issues but simply did not find an answer.

My install is based on sage 8.2.1 and I even reinstalled node and browsersync again, both of them are now on the latest version. My dev-URL is properly set and my MAMP finds the site.

When I run gulp --production I get an updated view with all my scss changes, both on localhost:3000 and my devUrl plotorg.local. As soon as I run gulp watch my browsers all sync up, but my carries a link to main-xyz123.css instead of just main.css which gets updated by browsersync. Another fairly clean install of Bedrock and Sage ist working fine using Brosersync 2.7.1, so I downgraded the „broken“ theme to 2.7.1 from 2.7.3 as well but no luck.

The gulpfile.js is similar in both projects as I could see with Kaleidoscope. Any ideas from anyone where I could have a look? I am a complete noob when it comes to JS and have run out of ideas after 4 hours of looking around.

So maybe someone has an idea how I could get the install up and running. Thanks a lot in advance for your help or any ideas where to look.


Another hour into it and I found a fix. After running gulp styles and gulp clean directly I was able to run gulp watch again and everything is fine again. Hope this helps anyone else running into trouble.

1 Like

Are you running gulp --production when developing rather than just gulp and also running gulp watch?

Hi Jessica,

I usually run gulp watch to work on the theme. When things weren’t updating, I used gulp --production to see any changes. But I had to load my devUrl directly to see the changes (in my case: plotorg.local). When connecting via localhost:3000 I did not see any changes.

Just a few minutes ago I ran into the same problem again and the gulp clean did not help. I figured that it must have happened after adding a broken JS snippet to main.js in the /assets folder. Reinstalled things again and deleted the JS snippet. After that I was able to run gulp and gulp watch again.

Strange behaviour. I did not get an error in the terminal about the JS though. Does that help you? I am left a bit confused again.

I had this issue with my image files once when using gulp watch… murdering my file names! lol.

But, it ended up being such a silly mistake on my part because I was saving the images directly to my dist/ directory rather than the assets/ directory without realizing. And what was even more frustrating is when I then ran $ gulp my images that I had saved had vanished!

This was of course because they weren’t in the assets folder for compiling and so the ones (with the added strings) were deleted. So, I never read the documentation on browsersync (oops!) but I was assuming it was an added tmp marker because they were manually added to the dist/ file.

Have you checked to make sure everything is saving/compiling in the correct places? It’s an easy thing to miss let me tell ya lol. But, I do feel like I have trouble sometimes with images rendering when using gulp watch and will sometimes have to run the grunt command to see those changes take place. This wasn’t always the case, but often enough I’d have two terminal tabs open with gulp watch running and the other building if images weren’t loading.

I am not sure if this helps, but I’d definitely just double check that you’re main.css file is being compiled correctly! Let me know how it goes.

Thanks for sharing your experience Jessica. Unfortunately it is not an issue of having stuff in the wrong place. I only work in the assets folder, actually none of the others are even open in neither Sublime Text nor the Finder. I’ll watch things and have a working setup so far. We’ll see how the other projects are behaving over time. Great to have different versions to work on in terms of finding potential weaknesses I guess.

1 Like

Yes it is! I am interested in knowing how things go with that because I was still having some intermittent issues with browsersync updating my asset files after I corrected my DUH moment. lol

I’ll keep on the lookout too!

1 Like

Did you add:

define('WP_ENV', 'development');

to your wp-config.php?

1 Like

Nope. I am actually using Bedrock, so that takes care of things for me. I have defined my .env though.