elemental preset: .less editing is not updating, even if cache is disabled

Permalink
Hello,

I work with a concrete5 installation on a local lampp server.
I have disabled all the caching options.
Each time I edit .less files in my theme's preset, based on the Elemental theme, then I try to refresh my browser, but changes are not applied.
I have to go to the customize menu, change the preset to another one and select back to the desired one and changes are finally applied.
This workflow is so terribly slow, I am sure I am doing something wrong and there is a faster way to update my css!
I think I checked all the documentation but couldn't find any clue. I was wondering if I need to compile the css by myself before refreshing the page, maybe just refreshing the browser is not enough?
I think it's a very common problem, what is the fastest workflow when editing the css?

Thanks for any help.
JP

 
johnpaul5 replied on at Permalink Reply
I figured out that some properties are updated well when I refresh the browser (e.g. in the footer), but others (e.g. in the header) aren't and I need to update the preset in concrete5's customize menu. I can't understand why there are differences between these areas, because they seem to be working similarly.
blinkdesign replied on at Permalink Reply
blinkdesign
in concrete5's customize menu you need to switch to the default preset an then switch back to your preset, - then all variables are loaded. maybe someone else may know why.
tabercreative replied on at Permalink Reply
tabercreative
That takes way too time in a development scenario.

I figured turning the "Theme CSS Cache" off would force the theme .less file to recompile, but it definitely does not. I can't tell what it does actually.
tabercreative replied on at Permalink Reply
tabercreative
Did you ever figure this out?
starkart replied on at Permalink Reply
I am having this same issue. What options are there?
lschiffli replied on at Permalink Reply
This is nearly 2 years after the original post and I am also having this same problem. I have searched for a solution, but have come up blank. Editing the preset variables is a very common thing. I have turned off all C5 caching and the browser cache. I have the same problem in Chrome and Firefox.

Is there any other solution besides loading a different preset in the Designer and then reloading my custom preset to get C5 to reload my .less preset variables?
What am I doing wrong here?
stewblack23 replied on at Permalink Reply
stewblack23
I had this issue with a client this morning when I was doing basic .less edits. and it ended up contributing to breaking the site. My fix was to completly ellimate the .less compling in C5. I use sass and gulp. Gulp is much more reliable and is faster in make css edits. Have a CMS doing less or sass complation always seems problematic to me.
lastit replied on at Permalink Reply
lastit
I had just the same problem. My solution:
1. deactivate and deinstall the used theme
2. delete the styles.xml in the theme (themes\elemental\css\styles.xml)
3. reinstall and activate the theme
The problem is, that by installing the theme the variables defined in styles.xml are registered into concrete5 to be served from the "theme manager" instead directly from the manually edited less file.
nkennel replied on at Permalink Reply
nkennel
This has been a frustration for me for a long time. When I update .less files in the presets, the colors never update, unless I visit each page, "customize" the theme, switch to a different preset, and switch back to the preset I have edited. Granted my site has tons of overrides, and I use several themes across the site, so I can't just easily switch themes sitewide.

Today I found that C5 (v. 5.7.5.8 at least) stores these values in a set of tables called StyleCustomizer... The key for me is that there is a table called CollectionVersionThemeCustomStyles that connects those stored values to the version of your page. Please be responsible and make a backup of this table, and check on how this affects your site before you follow my example on a live site. However, for me there are no adverse effects so far. I deleted all entries in the CollectionVersionThemeCustomStyles, which seems to break the connection to the stored values, and allow each page to look directly to the less preset, until the user sets the preset through the UI again.

I'm considering creating an automated job for this so that I can delete all the rows when needed without going directly to the database.