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 foundation/foundation-sites#8544 What do you think of the issue here and the solution?

[colin-marshall]

Good find @JPOak. I can confirm that it matches the date modified of the input source (app.scss in our case). I'm not against implementing that solution, but have we proven that the date modified being "off" is actually causing an issue?

[JPOak]

@colin-marshall I actually saw that you labeled that a bug back in 2016. Funny. Anyways, as I mentioned I don't have an issue with this type of stuff. So, not sure. However, I did test this against how we built in FP 2.9.2 and actually the compiled css modified date does change. So something is different from then and now.

[colin-marshall]

@JPOak ya I saw that too. Don't remember it though lol. Was more than likely just doing organization over there and didn't actually test anything out.

Interesting that FP 2.9.2 changes modified date. There actually is a clean:css task in pre 2.10 versions, but that shouldn't have anything to do with it. If I had to guess an update in one of the dependencies is probably the reason for the difference. The sass build task is pretty similar between versions.

[adambundy]

@colin-marshall I can confirm that making a minor mod to the compiled app.css of course updated the modified date to 'now' and when uploaded, my server's cache recognized that as a new version of the file. Implementing clean did not however change the modified date - still matches date of app.scss, even though app.css had been deleted then generated.

It does seem that re-compilation or clean then generation of the app.css file should change the modified date, so I guess I'd vote for the addition of gulp-touch.

[JPOak]

@colin-marshall I'm actually wondering if this is because we are using Gulp 4.0 alpha release. There are a couple threads over there talking about the modified time thing. We could revert.

[colin-marshall]

@adambundy thanks for confirming. For now feel free to add gulp-touch to your own projects while we figure out if we want to implement it. One thing you have to keep in mind is that you are developing in a way that is not recommended (on a remote server with caching enabled). The majority of us are never going to do that. We don't want to add dependencies to FP for uncommon use cases. That being said, if this is causing issues for others and gulp-touch doesn't add a noticeable impact to build time (which I doubt it will) then I'm ok with adding it.

@JPOak Ahhh that's exactly why. I was under the impression we were using Gulp 4.0 for awhile in FP but I was confusing it with Foundation. IMO, it's not worth reverting over this issue. If we revert we have to rewrite every gulp task and we can't take advantage of stuff like gulp.series and gulp.parallel. I'm much more inclined to add gulp-touch rather than reverting gulp.

[JPOak]

@colin-marshall Yeah. I realized that series function is only available in 4.0 .

@adambundy I did a quick test of touch. It works however, it has a deprecation warning in it. However, it doesn't break anything. Feel free to test and see what you think by:

npm install --save-dev gulp-touch

and then add .pipe($.touch())

on line 105 and 108 of the gulp file in the sass function.

This one gulp-touch-cmd may be a better option. No errors...I think. Feel free to try that one as well and let us know what you think.

[adambundy]

@colin-marshall totally understand that and yes, this is a nonstandard dev scenario, but would love to see modified dates match time of modification.

@JPOak thanks for this! Trying to get touch() running in the gulp file, but getting an error on npm start after adding where you suggested.

I installed gulp-touch in the project, and my sass function now looks like this: https://gist.github.com/adambundy/2884ff42150672a756bef95f9a1535aa

I am running node v6.11.1 and npm v3.10.10

Thanks for your help everyone!

[JPOak]

@adambundy You want to put the function after .pipe(gulp.dest(PATHS.dist + '/assets/css')) not after where you have them now

It would also be great if you could test out gulp-touch-cmd and see which you like better. For that one you need to:

npm remove --save-dev gulp-touch

npm install --save-dev gulp-touch-cmd

Add this to the top of the gulp file -

import touch from 'gulp-touch-cmd';

And then add this instead for the functions after the paths -

.pipe(touch())

[adambundy]

@JPOak excellent! That worked great. I ended up on the gulp-touch-cmd technique, which I can confirm worked to refresh the cache on WPengine's prod environment with my old workflow of uploading updated CSS file, revving up the version on the enqueue. It seems I can use touch() anywhere in the Gulp file, like on the JS processing as well.

Id love to see touch() integrated into the project, but understand Im just one user and right now in a non-standard dev workflow.

Thanks JPOak!

[JPOak]

@adambundy Great. Let us know if anything breaks. @ash-w2 Maybe gulp-touch-cmd will work for you. Maybe give it a go and let us know what you think. Nothing like testing!

[AlexPettyfer]

Can someone give me more insight on Static asset hashing / cache breaker? I don't really understand it. I have REVISION set to false. I had a favicon and removed it from the project. But the image is still showing.

[JPOak]

@AlexPettyfer If you have it set to false it is not doing anything for you. You can just ignore it. A favicon gets cached in the browser and can be tricky to get rid of. Do you have any old bookmarks of the website in the browser your are using. If so delete them. Restart.

[AlexPettyfer]

Thanks @JPOak , I thought it was something to do with the REVISION, but you're right.

[ash-w2]

@JPOak @colin-marshall Thanks both for the help. It turns out having dev mode on in Local fixes the issue.

Also for anyone else having trouble, I also found that having DevTools open and the cache disabled sometimes isn't enough. DevTools has to actually be visible on the screen, so undocking to a seperate screen was insufficient, it has to be docked in the browserSync page which seems fairly trivial but definitely affected the refresh.

Thanks again