CSS optimization/aggregation fails on files that use specific variations of @import

When parsing the css file the preg_replace_callback calls _drupal_build_css_path with the following matches:

array(2) {
  [0]=>
  string(318) "url(./display:block;height:206px;width:207px;}#electro_loop{background:url(./display:block;height:207px;margin:15px 0;width:207px;}#electro_loop #flash_content{margin:0;}#patners{}#col_center{padding:1px 20px 15px 40px;width:586px;}#col_center #search-box{display:none;}#col_right{background:url(../images/collage.png)"
  [1]=>
  string(313) "./display:block;height:206px;width:207px;}#electro_loop{background:url(./display:block;height:207px;margin:15px 0;width:207px;}#electro_loop #flash_content{margin:0;}#patners{}#col_center{padding:1px 20px 15px 40px;width:586px;}#col_center #search-box{display:none;}#col_right{background:url(../images/collage.png"
}

Let's see if I can find out what's wrong with the regexp....

When trying the expression in python:

>>> matches = re.findall(r'url\([\'"]?(?![a-z]+:|\/+)([^\'")]+)[\'"]?\)', content, re.IGNORECASE)
>>> print matches
['../images/bg.jpg', '../images/loop_cover.gif', '../images/loop_electro.gif', '../images/collage.png']

it works. So it might be a PHP version issue.

It chokes on the attached file with a stock PHP 5.2.5 and a 5.2.0-8+etch13 (on Debian). So it must be something with the expression. I've attached the file for further inspection.

Actually the css is already botched when

function drupal_load_stylesheet($file, $optimize = NULL) {

is called on the css file

@charset "utf-8";

@import "reset.css";
@import "structure.css";
@import "forms.css";
@import "menu_footer.css";
@import "content.css";

@import "admin.css";

Ok, I'm pretty sure that I've found where it is going wrong.
The style.css is the file described above. When it comes in drupal_load_stylesheet() it encounters:

$contents = preg_replace_callback('/@import\s*(?:url\()?[\'"]?(?![a-z]+:)([^\'"\(\)]+)[\'"]?\)?;/', '_drupal_load_stylesheet', $contents);

Which recursively calls _drupal_load_stylesheet() for the matched elements. If tracked what it the call returns when it was called with 'structure.css' and that css is still valid. But when I check what the preg_replace has returned it is botched.

#electro_cover{margin:15px 0;}#electro_cover a{background:url(../images/loop_cover.gif);display:block;height:206px;width:207px;}

becomes

#electro_cover a{background:url(./display:block;height:206px;width:207px;}

So, there is definately something wrong with the @import replacement css.

Test case:
structure.css:

 #elektro_cover a { background: url(../images/loop_cover.gif); }

style.css:

@charset "utf-8";

@import "structure.css";

Resulting css code:

@charset "utf-8";

 #elektro_cover a{background:url(./}

Sigh, I didn't see the underscore. The culprit is:

function _drupal_load_stylesheet($matches) {
  $filename = $matches[1];
  // Load the imported stylesheet and replace @import commands in there as well.
  $file = drupal_load_stylesheet($filename);
  // Alter all url() paths, but not external.
  return preg_replace('/url\(([\'"]?)(?![a-z]+:)([^\'")]+)[\'"]?\)?;/i', 'url(\1'. dirname($filename) .'/', $file);
}

That last one is incorrect.

I'm pretty sure that last regexp should have a "@import" in there as well because else it replaces all the url() instances that match and not only the @import statements.

I've tested this issue with 7.x dev and it's still there. I've attached a theme that allows testing. Follow these steps to reproduce:

• Download theme and extract in sites/all/themes
• Go to admin/settings/performance and enable CSS optimization
• Go to admin/build/themes and enable/set as default the testtheme
• After submitting look at the source to determine the name of the generated css file
• You'll notice that it generates invalid css, the css ends with #elektro_cover a{background:url(./}

There is probably something wrong with the regexp in _drupal_load_stylesheet($matches).

Damn, I screwed up the testtheme, it has a path outside the theme's dir. Here's a better test theme.

I'm pretty sure that the original code has never worked. The first back reference is whether or not the url starts with a quote. The whole point of the replace is to add the sub-path within the theme directory.

The patch seems to resolve the problem for first and second level @imports.

I've been using it on a couple of sites as well now and I really want this to hit D7 and D6.11 since I'd rather not have to patch core each time I turn on css optimization with a design that uses @import.

Since it works for you and me I'm putting this in reviewed and tested.

It's not really a duplicate, this one is just one more thing that is wrong with the CSS parsing.