CSS preprocessor order conflict

I"m having the same issue and I'm not using the LESS module. But when I aggregate the css files, the various resolution-based css files start having issues and the site does not look correct when changing from one size to another.

Im do not use LESS by I test css aggregation.
Without aggregation i have many css files and responsive grid works good.
With aggregation, responsive grid works also good, but i have only 5 aggregated css files.
Im using mobile and desktop browser for test.
So I cannot reproduce this issue.
--
omega 7.x-3.1

I'm also seeing this issue.

Everything loads (and compiles LESS) when not aggregating. When aggregating, everything compiles and loads properly, except any files that are pulled in through the omega responsive css files - i.e. themename-alpha-default-narrow.css.less, themename-alpha-default-wide.css.less etc.

I'm also not sure which module this bug should be attributed to, but weird behaviour indeed...

just about to do some research into it, but this is clearly a duplicate of http://drupal.org/node/1614416

I saw the same problem too. Fortunately the one site I was working on was so simple, I needed to only create a .less file for my global style sheet. I just left the rest as-is and was able to use it that way. But if I use a .less file for the default.css - it doesn't work.

For me, one of the CSS files did not validate. When I fixed it, things worked just perfectly. Not sure if that's anybody else's issue but something to consider.

I also had this issue (without LESS). Seeing Lloyd's comment, I checked my CSS and sure enough there was a syntax error. Fixed that and now it works fine with CSS aggregation.

I am experiencing the same issue. I think this is an actual bug as changes to syntax did not resolve my issue, I just finished digging through about 3000 lines of css.

I even removed all less elements of from every .less file then I wrote a bogus css class and assigned one property within each file (super simple). With css caching on only the global, default, and normal stylesheets are rendered. With css caching off global, default, narrow, normal, and wide are rendered.

I have had to copy out the rendered css files with caching off, disable the less module, then turn on css caching to resolve my issue.

Not fun at all.

I was able to reproduce this error:

When CSS aggregation is enabled Omega appears to prepackage the responsive .css/.less files from the sub-theme by wrapping the contents of the file in its associated media queries.

It does this without passing the list of stylesheets through CSS '#pre_render' entries.

The simplest solution is to not use LESS in the response files for your sub-theme, but instead add your responsive styling to your main .less file for your theme.

Use the classes that are automatically set on the body and change when the window size changes. This does depend on JS, but that is not an unreasonable requirement today:

• responsive-layout-wide
• responsive-layout-mobile
• responsive-layout-narrow
• responsive-layout-mobile

.test {
  font-size: 20px;

  .responsive-layout-mobile & {
    font-size: 12px;
  }
}

The above code will generate:

.test {
  font-size: 20px;
}
.responsive-layout-mobile .test {
  font-size: 12px;
}

This should also work with any custom responsive rules that you create.

So I've had this issue both with LESS and SASSY (really Prepro), and the issue is exactly this:

- Both Alpha and Prepro (and presumably LESS) use HOOK_element_info_alter() to inject their respective '#pre_render' functions.
- They both push use array_unshift() to make their function the first to be run, with Alpha's implementation of HOOK_element_info_alter() coming second and therefor it's #pre_render function coming first.
- During Alpha's #pre_render function it does the aggregation process in such a way that when Prepro's #pre_render function is called it doesn't think it needs to do anything.

The fix is really just to make sure that the order is changed, however I'm not sure in which project this should really be fixed, so I instead opted to make a quick snippet for my theme to have it deal with it itself:

/**
 * Implements hook_element_info_alter().
 */
function THEME_element_info_alter(&$elements) {
  if (variable_get('preprocess_css', FALSE) && (!defined('MAINTENANCE_MODE') || MAINTENANCE_MODE != 'update')) {
    foreach ($elements['styles']['#pre_render'] as $delta => $item) {
      if (in_array($item, array('alpha_css_preprocessor', 'prepro_pre_render'))) {
        unset($elements['styles']['#pre_render'][$delta]);
      }
    }
    array_unshift($elements['styles']['#pre_render'], 'alpha_css_preprocessor');
    array_unshift($elements['styles']['#pre_render'], 'prepro_pre_render');
  }
}

Hope this helps someone else, because I wasted a lot of time debugging this issue, and hopefully someone in the Omega project can have a think about how best to prevent this issue in the future.

Alpha could do something like this in hook_element_info_alter() in alpha's template.php:

/**
 * Implements hook_element_info_alter().
 */
function alpha_element_info_alter(&$elements) {
  if (variable_get('preprocess_css', FALSE) && (!defined('MAINTENANCE_MODE') || MAINTENANCE_MODE != 'update')) {
    // Ensure alpha_css_preprocessor() is executed immediately before
    // drupal_pre_render_styles(), regardless of other preprocess functions.
    $core_pre_render_pos = array_search('drupal_pre_render_styles', $elements['styles']['#pre_render']);
    array_splice($elements['styles']['#pre_render'], $core_pre_render_pos, 0, 'alpha_css_preprocessor');
  }
}

This ensures that alpha_css_preprocessor() is added to the list immediately before drupal_pre_render_styles() regardless of any other preprocessors in the list.

I have tested this on my own local instance and it works.

That sounds like a great solution, it means that it's not handling things specifically on behalf of Prepro or LESS, but it is still solving the issue.

Care to roll this as an actual patch? Means that in the case it doesn't get rushed in it can still be used via a Drush make file, whereas an inline comment can't, and I'd be happy to review it of course.

Cheers,
Deciphered.

Here is a patch based on #12 from corey.aufang. Works on my test site.

If this gets committed, make sure he gets the credit.

Thanks for throwing that together into a patch. When I tried my system was not being helpful.

Just relabeling as the scope of this issue has broadened and we also now have something to review.

Works a charm, happy to mark this as RTBC.

Drush makefile snippet for anyone in need:

projects[omega][subdir] = contrib
projects[omega][version] = 3.1
; Fix for SASS/SCSS and Alpha preprocess order issue - http://drupal.org/node/1627478#comment-6698812
projects[omega][patch][] = http://drupal.org/files/preprocess-aggregation-1627478-14.patch

Tagging #1614416: Less not being processed in alpha grid when CSS aggregation is enabled as duplicate.

Considering that work on this theme seems to have moved onto 7.x-4.x-dev, can we get this rerolled?

4.x appears to still be using the unfriendly method http://drupalcode.org/project/omega.git/blob/refs/heads/7.x-4.x:/templat...

Yes, will get this in for 4.x ... and commit it to 3.x too tomorrow.

No, the code we are discussing here has nothing to do with either Sass or Less. It just prevents PHP CSS preprocessors from working properly (which usually doesn't matter AND you REALLY should not use PHP CSS preprocessors and instead use the ruby versions anyways but still we can fix this easily so we will).

I've said this a hundred times already and I am saying it again: We don't have Sass "built-in" nor do we have Less "built-in". Sass and Less are independent applications and _no_ theme has them "built-in". What we do is: We strongly _recommend_ you use Sass. If you prefer Less, no problem... Go ahead. There are some utility gadgets in Omega 4.x that make it easier for you to get started with Sass but that's about it. And yes, the .css files that come with Omega 4.x have been written in Sass originally as well.

Sass, just like Less, is an application that you run on your _local development machine_ to compile .scss / .sass files into .css before uploading them to your server. On the server itself, the plain .css files are serverd... As usual. So no, you don't need anything on the server for it to work.

I have to copy this explanation somewhere. I keep repeating it every day after someone apparently coined the phrase that we have "Sass 'built-in'". I hope that wasn't me :P

So, given that this issue is still marked as RTBC and is marked for the 3.x branch, does that mean there is nothing to do? If this is meant to be re-rolled for 4.x and then backported to 3.x I would suggest that someone change the version to 4.x and the status to needs work, otherwise, here's hopping it gets committed to 3.x soon so we can stop relying on a patch.

@Kline: No worries. It's just that for more than a month now I am getting requests on a daily basis from people that ask if I can also build "Less" into Omega 4... Well and bogus questions on that topic in general tbh :).

@Deciphered: Yes, 3.x and 4.x will get that committed.

Fixed for 7.x-4.x.. Going to back 7.x-3.x. Will see if it affects anything if we inject it there.

Commited to 3.x thanks.

This was commited a year ago but it wasn’t released yet since the last 3.x release dates two years ago.

Can you please create a new release to integrate this and other 3.x changes?

(And yes, I know I should update to Omega 4.x, but since this is a major update I’m not sure if I can do it without breaking my current theme.)