Issues getting app.css to compile correctly, consistently

[adambundy]

Im trying to get up to speed on setting up and working with new Foundationpress setup (src/dist) and am having trouble getting CSS and JS to compile dependably after customizations.

• OS & version: MacOS 10.13 High Sierra
• Node: 6.11.1
• FoundationPress version: 2.10.4
• Foundation version: 6.4.1

I've created a /custom/ directory inside /src/assets/scss/ with a file named _custom.scss for my CSS customizations. In /src/assets/scss/app.scss at the bottom, Ive added: @import "custom/custom"; to include this file in the compiled app.css. This works a time or two, but then it seems changes to this trigger the compilation but fail to actually modify /dist/assets/css/app.css - the folder shows modified, but not the actual file. ?? Modifying even other SCSS files such as _settings.scss causes the same issue.

I tried starting over with a fresh install and re-inserting my customizations, but the same has happened. Any thoughts appreciated!

[dpkonofa]

Did you run npm start first and then make the customizations or did you make the customizations and then run npm start? Just trying to get some of the obvious reasons out of the way...

[adambundy]

@dpkonofa thanks for responding. I made them after. Should it matter? It also seems that the new webpack setup makes caching very difficult to bust. I dont know much about webpack though...

[colin-marshall]

@adambundy are you using the cache busting feature that was added recently? See: https://github.com/olefredrik/FoundationPress#static-asset-hashing--cache-breaker

This doesn't sound like a cache issue though if the file is not changing.

[adambundy]

@colin-marshall - thanks for your help too - I had not tried setting this to true yet. What does the new hashing feature do? Also, is there a breakdown somewhere of what happens on npm start vs. run build vs. run dev?

I realize this type of inquiry isn't really the purpose of these issue discussions, so thanks for your help.

[colin-marshall]

@adambundy the cache-busting feature adds a revision # to the end of the filename. That prevents the browser from pulling a cached version of an asset on reload.

You can see what the different npm commands do in the package.json file:

"scripts": {
    "start": "gulp",
    "dev": "gulp build --dev",
    "build": "gulp build --production",
    "package": "gulp package --production",
    "phpcs": "gulp phpcs",
    "phpcbf": "gulp phpcbf"
  }

The default gulp task, npm start, builds the dist directory, runs a browser-sync server and opens it in a new browser tab/window, and watches files for changes. npm run dev and npm run build just run the build task without the browser-sync server and they also don't watch files. The difference between the two is that npm run dev will build with sourcemaps while npm run build will build without sourcemaps and will minify the code.

As I typed that I realized that npm run build could probably use a more descriptive command name.

[dpkonofa]

@adambundy - I can't say for sure but I've had situation where gulp didn't pick up folders that were created after it did its initial globbing. It picks up new files in folders that were already included when it was started but not in new folders that didn't exist before it was started.

[adambundy]

@dpkonofa OK, thanks. Ill remember to try killing and restarting the process if it occurs again. @colin-marshall thanks much - my typical process for pushing changes up to my prod site was to bust cache by incrementing up the version in the enqueue for the CSS and JS files, but that seems insufficient now or in conflict perhaps with something going on in the the new hashing. I seem to have to delete the asset from the server, up the version, then get the browser to 404 on the missing file, re-upload the asset, and up the version in the enqueue again. What's making this so stubborn? Is it the new webpack component or the fp_asset_path functionality in enqueue-scripts?

Again, thanks for entertaining these how-to questions. This new setup has a bit of a learning curve for us long-time FP users...

Thanks!

[colin-marshall]

@adambundy I'm a little confused now. Are you asking about 2 different problems in this thread? Because I thought the original problem was app.css was not reflecting SCSS changes during development while browser-sync and gulp are running. Is there that problem in addition to the cache problem you described in your last response?

[adambundy]

@colin-marshall I dont blame you :) the issues I've been having have been rather befuddling. The new setup is just a pretty big change. Again, thanks for your help.

The most frustrating overall issue has been that because this is a small 1-page site Im building, I was working on it live on the server, rather than locally, and I was having great trouble getting the browser to show the current version of app.css, or app.js for that matter. My typical flow of incrementing up the version on the enqueue was not working. No combo of clearing cache (server or client-side) or URL hashing was working. I have resorted to a flow of incrementing that up, deleting the file from the server altogether to generate a 404, then incrementing, re-uploading the new file. That seems to cause the server to load the new file.

Oddly, I had been confused additionally because when gulp modifies the app.css file, the modified date doesnt change on the file in the finder (?!?) leading me to believe the file was not changing - but it was.

Turning on the hashing and running build works to create the hashed file, but is there something I need to do with enqueue-scripts.php to make the enqueue use the hashed version? It didnt seem to call the hashed version as-is. ...I just saw the reference to rev-manifest in the enqueue code and see that generated file in the dist subfolders - I'll try uploading those. Maybe the npm run build route is better for this type of dev scenario.

[JPOak]

@adambundy Out of curiosity do you have any serverside cacheing going on? Is this a managed host? Also, if you are using Chrome you may want to check out this post #1113 and use the settings here if you are iterating a lot for browser cacheing.

[adambundy]

@JPOak yes, this is running on WPengine and there is server-side caching which cannot be disabled unfortunately. Previously, the process of revving the version on the enqueue would trip the server to pull in the new version, but this seems to no longer work. It seems perhaps the new Foundationpress setup creates a more stubborn cached copy. I dont know much about webpack or ES6 to know if thats related.

[JPOak]

@adambundy With WPE you can work on the Staging server, which has no server cache. Then just clone it up to production when you are finished. This is what I do. Also, on the production wp dashboard there is the little empty cache button. I use WPE a lot and I don't have the issues you are having. However, I can see your frustration.

[colin-marshall]

@adambundy your best bet is to avoid doing development on a live server, but I bet you already figured that out. If that's not an option, some hosts will allow you to bypass caching based by your IP address. And as @JPOak said make sure browser caching is disabled in Chrome dev tools.

Something else to try would be to add this function to your gulpfile:

function cleanSass(done) {
  rimraf('dist/assets/css', done);
}

Then edit this line towards the end of the gulpfile:

gulp.watch('src/assets/scss/**/*.scss').on('all', sass);

change to:

gulp.watch('src/assets/scss/**/*.scss').on('all', gulp.series(cleanSass, sass));

I haven't tested to see if this would work but the idea is to delete the css folder before building the Sass so you always get a new file.

[JPOak]

@colin-marshall This discussion actually makes me curious about something. With cachebusting turned off the output of how the files are enqueued is the same. Could webpack or the new build system effect cacheing? In my mind, it couldn't. Or could it? To me the file is the file. If the file is on the server and your website is not updating, it seems to me a simple case of server cacheing and nothing to do with anything special in how the file was built.

[colin-marshall]

@JPOak you're probably correct but as I don't have access to his server I can't test for myself.

[colin-marshall]

@JPOak the idea I had behind cleaning before building the Sass is that app.css seems to only get "updated" when watch notices changes in the SCSS files. It's not actually deleted. Cleaning would delete the file and recreate it so the server might see it differently if the date created value is changed. No clue if that is how it works, just was an idea that popped in my head.

[JPOak]

@colin-marshall I would guess no, but I could definitely be wrong! that's why I asked out of curiosity. Also, if the file version is being ignored by server cache my thinking is that it has more to do with a change in their server cacheing than something to do with FPs build method or webpack etc.. It could even have something to do with the how files are being deployed. Again, I could be totally wrong! That is why I asked.

[ash-w2]

@colin-marshall @JPOak @adambundy

Just wanted to chime in with my two pence worth. @JPOak , you helped me with this issue here as mentioned above by disabling the cache in Chrome and leaving DevTools open but I'm still experiencing issues with getting BrowserSync to reload files consistently.

There doesn't seem to be any pattern to it, but sometimes if i also manually clear the cache, it either pulls in my changes or strips them out completely, sometimes even pulling in the original FoundationPress assets which are not even in my project anymore.

I can work with it but sometimes it's really frustrating. I'm working locally using Local as a dev environment, so I presume the cache-busting feature would have no effect on this my end. I will try adding the cleanSass function to my gulpfile now and see if that helps, but just wanted to make you aware I'm still experiencing issues.

Any help would be greatly appreciated and thanks for all your work!

[ash-w2]

Okay, just tried the cleanSass function but didn't seem to do much different. To clarify, this is when I run npm start

Here is a screenshot of what was loaded when the browser opened:

As i mentioned before, its pulling in the colors and assets from the default template downloaded with FoundationPress. The default navy blue for the top is not present in my _settings.scss anymore and the FP hero image is definitely not in my images folder.

When I make a change and re-save on SASS file, I get my styles pulling in:

Maybe this will help figure out what is going on?

[JPOak]

@ash-w2 Can you check your template files. Do you have any duplicates with the same template name in the header?

[ash-w2]

In page-templates? (apologies, still learning WP & FP). If so, then no, all Template Names are different for front.php, page-full-width.php & page-sidebar-left.php @JPOak

[JPOak]

@ash-w2 I mean at the top of the file where it might say Template Name: Front. Did you happen to copy the "front.php" and then rename it?

[ash-w2]

No, there are no duplicate template names. I did temporarily rename "front.php" to "home.php" but reverted it. I was experiencing this issue before I did that though @JPOak

[JPOak]

@ash-w2 I'll test and see what happens. However, just make sure that is you ever duplicated front.php that in the code itself you change the template name at the top. This sort of looks like a template conflict to me.

[ash-w2]

Great, thanks @JPOak . I have definitely not duplicated front.php only renamed but then reverted, but as I say, this has been happening since install and can't figure out why. Firefox seems okay, but Safari is the same.

Thanks for the help

[colin-marshall]

@ash-w2 that cleanSass function definitely won't make a difference on local development. If you would be willing to share your repo with me I can take a look and see if I can reproduce the behavior. Also try rm -rf node_modules and npm install again and see if that makes a difference. What versions of Node and FoundationPress are you running?

[colin-marshall]

Also @ash-w2 I see a lot of people are having cache issues with Local. Make sure Dev mode is turned on. See this thread for more suggestions: https://local.getflywheel.com/community/t/not-able-to-see-css-changes/2136/41

[adambundy]

@colin-marshall @JPOak Thanks for ongoing assistance. I think the 'clean' sounds like perhaps a solve for this, as it seems fishy to me that the modified date on my dist files dont change for some reason, though the file contents do. ?!? (when I turned on cache-busting, even the newly generated file with the new string in the filename has an old modified date - ??)

Serverside, Im suspicious that caching ignores the updated file because its datestamp has not changed. Im going to try adding the delete/generate.

re: staging/prod on WPengine, yes I normally dev on staging then push to prod but have been having issues with the migration tool lately and this is such a simple site I just thought I'd work it up on prod. I did copy down to staging and test a bit and was still having some odd issues.

[adambundy]

@colin-marshall @JPOak A bit more info: I was able to add the 'cleaning' as part of the npm start process, and it is working to delete all the dist files before re-generating them. However, the datestamp on my app.css is still from a week ago. ??? (same date seen in MacOS finder and in my IDE) Is the 'start' process setting a modified date perhaps? Seems the date its setting is the first time I built the project maybe.

I then tried cracking open the actual compiled dist version of the app.css and making a trivial change - this tripped the modified date to now. The uploaded file was then recognized by the caching on the server as new (after I revved the version number in my enqueue as I usually do) and all was good.

Thanks again all.

[JPOak]

@adambundy I see what you are saying. Hey @colin-marshall check out this https://github.com/zurb/foundation-sites/issues/8544 What do you think of the issue here and the solution?