I have a question that worries me a little. In your description you are saying:
If you are making changes to your SCSS files and not seeing any change
in your site it could be because of SCSS error or the Client
Dependency Framework cachingd. Try turning on debugging in the
web.config.
You are saying this for a reason, probably you had that couple times maybe? This is kind of a problem for me. Every deployment we do has the value set debug=false in web.config. If changes in the SCSS files aren't visible we have a problem because our content editors cannot change that in the web.config. They could but I don't want them to. Editing stylesheets should just work.
So what I would like to know, how big is this issue? What are the circumstances that this situation may occur?
Thanks for liking the package and welcome to the wonderful world of ClientDependency (CD)! I agree that that the issue you described is not idea, well it stinks and not a long term solution. Everything works great as long as you are running in debug but in a production site this is not recommended. The issue is rooted in the CD part of the implementation and how it caches stuff. CD only updates it's cached copy when the app pool recycles(but not reliably) or when the CD version number in the CD config file is changed. From the reading of the CD doc's, Shannon Deminick suggests running in debug mode until your CSS/JS is stable. When you deploy new versions of your CSS/JS (SCSS in this case) then increment the version number in the CD config file to recompile the files and have the site use the updated stuff.
While this is one way of handling SCSS updates, however it assumes that whoever is editing the SCSS files has access to the CD config file. At best this make updates when not running in debug clunky and at worst impossible if you cannot see your changes in real time. I guess I could argue that none developers should not be making changes to the style of a production site but we all know that stuff happens and things need to get updated by editors that are not admins, so real time updates need to happen.
The long term answer to this issue is to make sure that the CD cache gets updated when one of the SCSS is updated/saved and I am currently working on this functionality. To be honest, I was excited to upload the package and did not want to wait until I finish that functionality. I am also working on an alternatively http handler, adding better SCSS compilation error handling (maybe a preview feature) and a toolbar for adding file imports and inserting SCSS variable.
Just uploaded version .02. Added code that advances the ClientDependency (CD) version number when you save a SCSS file from the backoffice. This will casue the CD cache to be update and changes should render to the the site even if you are not running in debug mode.
Caching question
Hi Jason,
Like this package. Good job!
I have a question that worries me a little. In your description you are saying:
You are saying this for a reason, probably you had that couple times maybe? This is kind of a problem for me. Every deployment we do has the value set debug=false in web.config. If changes in the SCSS files aren't visible we have a problem because our content editors cannot change that in the web.config. They could but I don't want them to. Editing stylesheets should just work.
So what I would like to know, how big is this issue? What are the circumstances that this situation may occur?
Thanks!
Arjan,
Thanks for liking the package and welcome to the wonderful world of ClientDependency (CD)! I agree that that the issue you described is not idea, well it stinks and not a long term solution. Everything works great as long as you are running in debug but in a production site this is not recommended. The issue is rooted in the CD part of the implementation and how it caches stuff. CD only updates it's cached copy when the app pool recycles(but not reliably) or when the CD version number in the CD config file is changed. From the reading of the CD doc's, Shannon Deminick suggests running in debug mode until your CSS/JS is stable. When you deploy new versions of your CSS/JS (SCSS in this case) then increment the version number in the CD config file to recompile the files and have the site use the updated stuff.
While this is one way of handling SCSS updates, however it assumes that whoever is editing the SCSS files has access to the CD config file. At best this make updates when not running in debug clunky and at worst impossible if you cannot see your changes in real time. I guess I could argue that none developers should not be making changes to the style of a production site but we all know that stuff happens and things need to get updated by editors that are not admins, so real time updates need to happen.
The long term answer to this issue is to make sure that the CD cache gets updated when one of the SCSS is updated/saved and I am currently working on this functionality. To be honest, I was excited to upload the package and did not want to wait until I finish that functionality. I am also working on an alternatively http handler, adding better SCSS compilation error handling (maybe a preview feature) and a toolbar for adding file imports and inserting SCSS variable.
Just uploaded version .02. Added code that advances the ClientDependency (CD) version number when you save a SCSS file from the backoffice. This will casue the CD cache to be update and changes should render to the the site even if you are not running in debug mode.
Hi Jason,
Thank you for your extensive reply. Good to see you have good knowledge about CD. I'll definitely will try version 02.
Good work!
Just an FYI. I just uploaded version 1. Finished the toolbar features that I wanted to have in the ediotor.
Sounds good! I'll install and test version 1 somewhere this week. Let you know if/when I have any feedback.
is working on a reply...