Less Dynamic CSS Compiler not working correctly when site is cloned(git).
Hi Jeremy,
When I use git to clone my site, my less files which are normally in a tree, flatten out. Changes that I then make to my less files are not handled by the plugin. To make it work, every time I push a clone to staging - I have to delete the less (and the generated css files), and recreate them.
Thanks for looking into this, and let me know if you need any more details!
Hrm, I'm not exactly sure what's going on in your situation. As long as the site is running it bind's file-chance/create handlers to the css folder so individual files being replaced, etc, shouldn't cause any issues. Now if for some reason the entire css folder was removed and re added it might not work as expected.
It also possible that the entire IIS pool is restarting at the same time the css files are updated. IE if there are bin changes and css changes deployed simultaneously the site could shut down the less files update, then the site restart, and have missed the less file updates.
Also be aware that this plugin is specifically operating on *.less.css file's for integration reason's and won't do anything with straight .less files.
So basically, this is my set up. I have a local environment where I do my dev. I have staging and production which are currently on azure. Things work locally of course because that environment is never cloned. When my local dev is ready to go to staging, I create the staging slot, clone the prod DB, push my local to staging using git, I configure staging to use the new database clone, and then use courier to move any necessary content/media to staging before swapping it into production. All of my less files are *.less.css, but like I said their corresponding css files are no longer found by clicking the arrow next to the *.less.css files - the tree is flattened out, so you can see all *.css and *.less.css files directly under "Stylesheets". Making a change to these less files does not effect their corresponding css files.
Less Dynamic CSS Compiler not working correctly when site is cloned(git).
Hi Jeremy,
When I use git to clone my site, my less files which are normally in a tree, flatten out. Changes that I then make to my less files are not handled by the plugin. To make it work, every time I push a clone to staging - I have to delete the less (and the generated css files), and recreate them.
Thanks for looking into this, and let me know if you need any more details!
Mike
Hrm, I'm not exactly sure what's going on in your situation. As long as the site is running it bind's file-chance/create handlers to the css folder so individual files being replaced, etc, shouldn't cause any issues. Now if for some reason the entire css folder was removed and re added it might not work as expected.
It also possible that the entire IIS pool is restarting at the same time the css files are updated. IE if there are bin changes and css changes deployed simultaneously the site could shut down the less files update, then the site restart, and have missed the less file updates.
Also be aware that this plugin is specifically operating on *.less.css file's for integration reason's and won't do anything with straight .less files.
So basically, this is my set up. I have a local environment where I do my dev. I have staging and production which are currently on azure. Things work locally of course because that environment is never cloned. When my local dev is ready to go to staging, I create the staging slot, clone the prod DB, push my local to staging using git, I configure staging to use the new database clone, and then use courier to move any necessary content/media to staging before swapping it into production. All of my less files are *.less.css, but like I said their corresponding css files are no longer found by clicking the arrow next to the *.less.css files - the tree is flattened out, so you can see all *.css and *.less.css files directly under "Stylesheets". Making a change to these less files does not effect their corresponding css files.
is working on a reply...