Since i need the aggregation and compression of css files and the module not working when this option was enabled, i wrote a little patch, that will add an extra checkbox to choose if you want to see the compressed/aggregated css in the editor.
Reason:
Client wanted a custom css loaded on every page, which they could change on production without a new release process. To fix minor css issues if there are any but we wanted the other css in production compressed/aggregated.
| Comment | File | Size | Author |
|---|---|---|---|
| live_css_final.patch | 2.26 KB | k-mo |
Comments
Comment #1
guybedford commentedThanks for submitting. Would I be right in thinking that this only modifies the minified versions?
So if a change was made to the underlying stylesheet the changes to the compressed stylesheets would be reverted?
If so, that isn't really an acceptable way of handling this unfortunately.
Comment #2
deryck.henson commentedIronic this is coming up just after we talked about it.
Just brainstorming here but what about a bypass just for the Live CSS user to avoid it and all other users would receive the cache. I believe there's a hook in core that would allow us to do direct file requests.
What you think
Comment #3
k-mo commentedHey,
Sorry for the late reply.
@guybedford
Actually the aggegraded css files should always be hidden, the designers arent using them, no point. But just incase someone wanted it, i implemented it, hence its default set to hide the aggregated css files. I add a css file with preprocess => false, they wont get aggregated, they can be edited and have use.
@deryck
What do you actually mean? Serve the edited css files only to the Live css users? and the cached to the rest? Cant we actually just always show the un- minified/aggrated files in the editor and on save, do the aggregation and clean cache etc.. to serve the new files.
So instead of reading the the loaded css files off the current page, show show all the .css files (not aggregated ones).
I also got a request to add SASS compatibility, amazing module btw :)
Comment #4
deryck.henson commentedI recently updated the source to include a cache clear function upon save by default (that can be enabled/disabled in the Live CSS options). So yes, that was the idea lol.
Great minds think alike.
Comment #5
deryck.henson commentedComment #6
deryck.henson commentedI'm going to look more into this. If anyone has found anything since, let me know. The patch is a nice starter skeleton but it doesn't actually affect the file open/list/save/display actions.
I should have time this weekend or throughout the week to test some stuff out.
Comment #7
deryck.henson commentedComment #8
k-mo commentedHey Deryck whatr do you mean with "but it doesn't actually affect the file open/list/save/display actions", basicly what it does is: show all files by default even if aggregated, but there is a checkbox that will hide the aggregated files if wanted. so right now i have a drupal_add_css with preprocess on false. This allows me to use drupal css aggregation but still use the file added with drupal_add_css.
The post title might be a bit wrong. My use case was:
Use the drupal css aggregation (right now if css aggregation was enabled live css wasn't working) and add a custom css file which is loaded on each page that the client can do css hotfixes with.
Comment #9
guybedford commentedI can really see no way to implement this without doing something incredibly buggy that will lead to more problems than solutions.
Would actually strongly advise against pursuing these paths, unless you have a really solid proposal.
Comment #10
deryck.henson commented@guybedford is right, there's way too many things to account for to make this a reality at this point. If aggregation changes in the meantime we can always come back to re-visit but I don't think it's worth the extra potential hours of troubleshooting.
But by all means if your patch helps you with your particular case @mojo4444, patch away!
Closing due to cost-benefit being too high of cost.