Closed (works as designed)
Project:
Drupal core
Version:
6.x-dev
Component:
system.module
Priority:
Normal
Category:
Feature request
Assigned:
Unassigned
Reporter:
Created:
25 May 2007 at 17:09 UTC
Updated:
31 May 2007 at 00:39 UTC
The attached patch will cause the CSS preprocessor code to automatically detect when one or more of the CSS files it is merging has changed. As a result, a new cache entry is created containing the updated contents.
It essentially looks at the filemtime() of each (existing) CSS file and stores this in the $css array. In this way, when the filename is generated using md5(serialize($css)), a different filename is chosen if any of the files' mtimes have changed.
| Comment | File | Size | Author |
|---|---|---|---|
| css-preprocess-current.patch | 977 bytes | gribnif |
Comments
Comment #1
stevenpatzComment #2
hass commentedi understand why this will be good idea, but many many disk operations like this for every request is no good idea for performance reasons.
Comment #3
wim leers*If* this functionality should be included somewhere, it should not be core, but the devel module IMO. This is something you don't need (or want) on a production site. It's only useful when you're developing.
Comment #4
m3avrck commentedYeah, this can slow down every site with extra unneeded disk access.
While it is annoying that the cache isn't cleared, this exists in Drupal everywhere, from the regular cache, module caches, and so forth.
This could be added to devel module in a creative way IMO.
Comment #5
gribnif commentedI disagree that this would likely cause any noticeable performance degradation to have "always on". Currently, Apache does exactly this when CSS preprocessing is turned off (the client has to do repeated HEAD or If-Modified-Since requests to see if every CSS file on the page has changed).
There may some slight degradation in speed if you compare CSS preprocessing "on" with the current codebase vs. "on" with this patch, but I doubt even that would be very noticeable. File stat operations are extremely cheap, in my experience.
Perhaps someone could come up with a good benchmark to test with?
Comment #6
hass commentedwe'd like to get more speed with aggregation. so every IO we don't need is better. Aside, on my box i've got very often "too many open files" error... vservers are often very limited in IO's...
Comment #7
moshe weitzman commentedi'll add a -1 here. this is a general problem as ted said, and not to be solved here (or at all, really)