It turns out that when you run this call:

drupal_add_css($css, 'inline');

Nothing happens. This is because the type is converted to an options array in drupal_add_css like this:

    if (!is_array($options)) {
      $options = array('type' => $options);
    }
    $options += array(
      'type' => 'file',
      'group' => CSS_DEFAULT,
      'weight' => 0,
      'every_page' => FALSE,
      'media' => 'all',
      'preprocess' => TRUE,
      'data' => $data,
      'browsers' => array(),
    );

Note that preprocess defaults to TRUE.

As far as I can determine, inline CSS is inherently not preprocessable.

Changing my call to this works:

    drupal_add_css($css, array('type' => 'inline', 'preprocess' => FALSE));

But that's bad DX. Patch to make inline force to preprocess FALSE is forthcoming.

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

merlinofchaos’s picture

Status: Active » Needs review
FileSize
816 bytes

Here is a simple patch

andypost’s picture

Looks reasonable! Could we have a test for this?

Status: Needs review » Needs work

The last submitted patch, 961518-inline-css-no-preprocess.patch, failed testing.

merlinofchaos’s picture

Status: Needs work » Needs review

I am very confused by these test results. I am not going to be able to work on this. It's like the current broken behavior is actually what is being tested for. That makes no sense. :/

andypost’s picture

Current behavior is not documented so should be changed.

effulgentsia’s picture

Subscribe. I'm surprised that allowing the default TRUE makes it not work. Will investigate further when I have a chance.

rfay’s picture

subscribe

effulgentsia’s picture

Status: Needs review » Postponed (maintainer needs more info)

@merlinofchaos: what do you mean by "nothing happens"? When I enable a test module with the following code:

function test_page_alter() {
  drupal_add_css('.breadcrumb a { color: red; } body { margin: 20px; }', 'inline');
}

My HTML includes the following:

<style type="text/css" media="all">.breadcrumb a{color:red;}body{margin:20px;}
</style>

And my breadcrumb links turn red. The margin on the body is ignored, because Seven's reset.css undoes it, since it is a theme css file, and therefore, at higher group weight.

Changing my code to:

function test_page_alter() {
  drupal_add_css('.breadcrumb a { color: red; } body { margin: 20px; }', array('type' => 'inline', 'preprocess' => FALSE));
}

results in this markup:

<style type="text/css" media="all">.breadcrumb a { color: red; } body { margin: 20px; }</style>

in the exact same weight relative to the other STYLE tags as the first example, so no visual difference from the 'preprocess' flag: breadcrumb still red, body margin still reset by Seven.

So the effect of 'preprocess' is whether to strip whitespace, and perhaps do other things, like inline @import statements. I suppose one could argue that this should default to FALSE for the 'inline' type, but to me it's not obvious that it should, and at any rate, seems like a different discussion than "broken" and "nothing happens".

Can you clarify the bug you're experiencing?

merlinofchaos’s picture

In Panels, I do a lot of work with adding CSS inline when necessary, particularly with the flexible layout.

After a cvs up, my flexible layouts started breaking, and I discovered that the 'preprocess' flag was causing the inline CSS to not appear.

Did you try this with both CSS aggregation on and off?

merlinofchaos’s picture

One note: CSS aggregation is currently OFF on my test site (with a pretty recent cvs up, I'll add).

This works:

   drupal_add_css($css, array('type' => 'inline', 'preprocess' => FALSE));

This does not:

    drupal_add_css($css, 'inline');

However, the plot thickens. I turned CSS aggregation on for my test site, and it is completely broken. Plus I get a bunch of this:

    * Warning: preg_replace(): Compilation failed: unrecognized character after (? at offset 9 in drupal_load_stylesheet_content() (line 3504 of /var/www/d7p3/includes/common.inc).
    * Warning: preg_replace(): Compilation failed: unrecognized character after (? at offset 9 in drupal_load_stylesheet_content() (line 3504 of /var/www/d7p3/includes/common.inc).
    * Warning: preg_replace(): Compilation failed: unrecognized character after (? at offset 9 in drupal_load_stylesheet_content() (line 3504 of /var/www/d7p3/includes/common.inc).
    * Warning: preg_replace(): Compilation failed: unrecognized character after (? at offset 9 in drupal_load_stylesheet_content() (line 3504 of /var/www/d7p3/includes/common.inc).
    * Warning: preg_replace(): Compilation failed: unrecognized character after (? at offset 9 in drupal_load_stylesheet_content() (line 3504 of /var/www/d7p3/includes/common.inc).
    * Warning: preg_replace(): Compilation failed: unrecognized character after (? at offset 9 in drupal_load_stylesheet_content() (line 3504 of /var/www/d7p3/includes/common.inc).
    * Warning: preg_replace(): Compilation failed: unrecognized character after (? at offset 9 in drupal_load_stylesheet_content() (line 3504 of /var/www/d7p3/includes/common.inc).
    * Warning: preg_replace(): Compilation failed: unrecognized character after (? at offset 9 in drupal_load_stylesheet_content() (line 3504 of /var/www/d7p3/includes/common.inc).
    * Warning: preg_replace(): Compilation failed: unrecognized character after (? at offset 9 in drupal_load_stylesheet_content() (line 3504 of /var/www/d7p3/includes/common.inc).
    * Warning: preg_replace(): Compilation failed: unrecognized character after (? at offset 9 in drupal_load_stylesheet_content() (line 3504 of /var/www/d7p3/includes/common.inc).
    * Warning: preg_replace(): Compilation failed: unrecognized character after (? at offset 9 in drupal_load_stylesheet_content() (line 3504 of /var/www/d7p3/includes/common.inc).
    * Warning: preg_replace(): Compilation failed: unrecognized character after (? at offset 9 in drupal_load_stylesheet_content() (line 3504 of /var/www/d7p3/includes/common.inc).
    * Warning: preg_replace(): Compilation failed: unrecognized character after (? at offset 9 in drupal_load_stylesheet_content() (line 3504 of /var/www/d7p3/includes/common.inc).
    * Warning: preg_replace(): Compilation failed: unrecognized character after (? at offset 9 in drupal_load_stylesheet_content() (line 3504 of /var/www/d7p3/includes/common.inc).
    * Warning: preg_replace(): Compilation failed: unrecognized character after (? at offset 9 in drupal_load_stylesheet_content() (line 3504 of /var/www/d7p3/includes/common.inc).
    * Warning: preg_replace(): Compilation failed: unrecognized character after (? at offset 9 in drupal_load_stylesheet_content() (line 3504 of /var/www/d7p3/includes/common.inc).
    * Warning: preg_replace(): Compilation failed: unrecognized character after (? at offset 9 in drupal_load_stylesheet_content() (line 3504 of /var/www/d7p3/includes/common.inc).
    * Warning: preg_replace(): Compilation failed: unrecognized character after (? at offset 9 in drupal_load_stylesheet_content() (line 3504 of /var/www/d7p3/includes/common.inc).

Maybe I've been looking at this all wrong. Maybe that preg_replace() is the real culprit here.

merlinofchaos’s picture

Status: Postponed (maintainer needs more info) » Active

Okay, playing with this leads me to believe that the real problem is that CSS preprocess is completely broken for me, because that regex is failing.

So it looks to me like there are two problems:

One is #962318: Require PCRE Version >= 7.2 -- the regex is failing causing preprocess to fail.

Two is: It's trying to preprocess inline CSS when preprocessing is not on.

Turning back to active for two. That behavior sounds wrong to me.

effulgentsia’s picture

Title: drupal_add_css() currently broken when using 'inline' option » drupal_add_css() preprocesses inline CSS even when the site-wide aggregation setting is off
Status: Active » Needs review
FileSize
7.62 KB

The remainder of this issue (#11.2) seems like it could be demoted to normal, but leaving it at major, because it's unclear how #11.1 will be resolved in the other issue. Hopefully, we don't have to debate the priority though, since I think this is the right fix for this issue, and as an extra enticement to commit it, it strengthens our test coverage.

catch’s picture

Version: 7.x-dev » 8.x-dev
Priority: Major » Normal
Status: Needs review » Reviewed & tested by the community
Issue tags: +Needs backport to D7

The patch and tests look good to me, the other issue was fixed though, so I'm downgrading to normal and generally fixing status here.

catch’s picture

Issue tags: -Needs backport to D7

Status: Reviewed & tested by the community » Needs work

The last submitted patch, 961518-inline-css-preprocess-12.patch, failed testing.

sun’s picture

Status: Needs work » Needs review

Status: Needs review » Needs work
Issue tags: +Needs backport to D7

The last submitted patch, 961518-inline-css-preprocess-12.patch, failed testing.

Wim Leers’s picture

Status: Needs work » Closed (fixed)

#352951: Make JS & CSS Preprocessing Pluggable fixed this in D8: when the side-wide "aggregate CSS files" setting on the "performance" admin page is unchecked, then it is guaranteed zero preprocessing will happen. This was indeed extremely confusing.

I doubt this will be fixed in Drupal 7 since this has been open for 2.5 years already. So, just closing.