I am very new to Drupal and Unlimited CSS works great with everything but I just installed Civicrm and it bypasses unlimited css and it will not display properly in internet explorer.

Any ideas?

Comments

thauk’s picture

Assigned: thauk » Unassigned
jimurl’s picture

I found that this is due to using THREE modules in combination:
CiviCRM
IE Unlimited CSS Loader, and
Date Popup module (part of the Calendar and Date suite)

IE unlimited CSS uses the 'preprocess_page' function, so does Civi.

Civicrm has this within its preprocess page function:


  if ( module_exists('date_popup') && ( in_array( arg(0), array('civicrm', 'user') ) ) ) { 
 // do some stuff, now commented out, for js files

       if ( ! empty( $variables['css'] ) ) {  		     
  			$path = drupal_get_path('module', 'date_popup'); 
  			unset( $variables['css']['all']['module'][$path . '/themes/datepicker.css'] );  			
  			$variables['styles'] = drupal_get_css( $variables['css'] ); 
  	} 

  }

I disabled Date-Popup, and IE Unlimited CSS began working on my pages. I think that civicrm puts this in there so that there won't be conflicts between the civicrm datepicker and the Date Popup Datepicker? But that last line also wrecks Unlimited CSS Loader as well.

donquixote’s picture

Could this be a module weight problem?
I think unlimited_css should get a higher weight than anything else.
Maybe I need to enforce this in the install / update functions.

donquixote’s picture

Status: Active » Closed (duplicate)

I mark this as a duplicate of
#936814: Set module weight in hook_install() and hook_update().
assuming that module weight is really the problem.
If you cannot confirm this, feel free to reopen.

jimurl’s picture

Status: Closed (duplicate) » Closed (works as designed)

Hi Don,

It doesn't appear to be a module weighting issue. But I don't think it's an issue with Unlimited CSS. I think its an issue with CiviCRM.

My testing consisted of:

Enable all three modules.
Adjust module weighting: Unlimited CSS : -10 , and Civi: 0
Clear caches. Visit a url where arg(0) is 'civicrm' or 'user' ( as noted in the code above). View source, and it's all

Other pages, where arg(0) is, say, node, are using @import.
Disable date_popup ( so the above little snippet is not triggered). all is @import , so unlimited CSS is working fine.
Re-enable date_popup, and now switch the module weighting: civi is -10, unlimited css is 0.
Clear caches, and retest. Nope, it's still using

Finally, I just commented out the snippet that I quoted above. I am not clear on what it does, but just above it in the code is:

	// to increase it's flexibility. 
  	if ( module_exists('date_popup') && ( in_array( arg(0), array('civicrm', 'user') ) ) ) { 
...
...

I also posed a question on the civicrm dev forum- "what does this do?" - I don't quite get the $variables['styles'] versus $variables['css'] question.

I changed the status of this issue to "closed (works as designed)"- so that no one ends up thinking its a module weighting issue. I hope that's OK.

donquixote’s picture

Sorry, don't get it.
The module weight of unlimited_css should be something positive and higher than the one for CiviCRM.
What you describe is the other direction.

jimurl’s picture

Sorry, my post apparently got cut off. I also switched the order of the weights of Unlimited CSS and civicrm- making them 0 and -10, respectively. And got the same result.

I also misunderstood your meaning of 'higher weight' - I was thinking in terms of 'Lower weighted items float higher...' that seems to run throughout.

Are module weightings supposed to be only positive? In my database, I find them all over the place, from -1, -5, -10, etc., up to 500.

The upshot of my testing was that the weighting did not seem to affect whether the civicrm code above broke Unlimited css or not. disabling the date popup module solved the issue (but I need it); as did commenting out that snippet in the civicrm module (which leaves the civicrm_preprocess_page function doing nothing at all).

Here is my discussion over on the civicrm forums, for those who find a similar problem:
http://forum.civicrm.org/index.php/topic,22240.0.html

donquixote’s picture

Status: Closed (works as designed) » Needs work

I don't want to see this closed, if the answer is still not found.

One thing I still don't understand is, what exactly happens if these three modules are enabled? How is the CSS put into your html head, and how does this differ from what you would expect to happen?
I assume we are talking about the case where aggregation is disabled, and we have more than 31 (or more than 22) stylesheets, so unlimited_css should use @import to embed them.
Are some of the styles missing? Or is @import not used at all, but it should?
What is the sequence of preprocess page hooks firing? (you could figure out with a bit of dpm() - but you need to refresh the page twice to see the effect)

jimurl’s picture

Yes, I am wondering the same thing- exactly how are the CSS finally put into the html head. Currently, if:
1. all three modules are enabled,
2. requesting a url where arg(0) is civicrm or user,

THEN, the css files are adding using
, even if the weight of unlimited css is greater (heavier, 10) than civicrm (0, lighter).

Civicrm wants to disable date_popup's theme/datepicker.css , so it unsets that $variables['css']['all']['module']['date_popup/themes/datepicker.css'] variable, and uses drupal_get_css to recreate $styles. It's the same way that Unlimited CSS rewrites $styles.

But it appears that civicrm's invoking of drupal_get_css comes after, or overwrites, Unlimited CSS use of it ... even when the weighting is like I said above-Unlimited CSS being heavier(higher weight) than civicrm.

So it sure does look like exact;u what you are saying- a question of module weighting.

Perhaps the different modules drupal_get_css are not necessarily run in the order of weighting?

Bit of a moot question for the site I am working on - it does not use date_popup's datepicker.css , but instead jquery UI's datepicker css.

Like you, though, I am curious why it doesn't work as we would expect it to.

donquixote’s picture

xurizaemon’s picture

Looks like something like this in civicrm.module may be the fix -

@ line 980 of civicrm.module (4.2.x for D6)

    // Similar process for CSS but there are 2 CSS related variables.
    // $variables['css'] and $variables['styles'] are both used.
    if (!empty($variables['css'])) {
      $path = drupal_get_path('module', 'date_popup');
      unset($variables['css']['all']['module'][$path . '/themes/datepicker.css']);
      $variables['styles'] = drupal_get_css($variables['css']);
    }

becomes

    // Similar process for CSS but there are 2 CSS related variables.
    // $variables['css'] and $variables['styles'] are both used.
    if (!empty($variables['css'])) {
      $path = drupal_get_path('module', 'date_popup');
      unset($variables['css']['all']['module'][$path . '/themes/datepicker.css']);
      if (!module_exists('unlimited_css')) {
        $variables['styles'] = drupal_get_css($variables['css']);
      }
    }
 

NB: untested, fix not to be applied here but in civicrm, awaiting feedback from a colleague to see if this works - but thought I might improve on the "here's a fix, but it won't fit in this margin, 404 LOL" of the preceding comment ;)

jonathan_hunt’s picture

The link in #10 404s. CiviCRM alters the registry to ensure it runs the last hook_preprocess_page(), and if date_popup exists, CiviCRM zaps the CSS and reinstates the $styles variable, overriding the @import conversion from Unlimited CSS.

Below is a work-around if you have D6 Unlimited CSS, CiviCRM and Date Popup all running.

    // Similar process for CSS but there are 2 CSS related variables.
    // $variables['css'] and $variables['styles'] are both used.
    if (!empty($variables['css'])) {
      $path = drupal_get_path('module', 'date_popup');
      unset($variables['css']['all']['module'][$path . '/themes/datepicker.css']);
      // Refer http://drupal.org/node/745416 re conflict between CiviCRM and Unlimited CSS.
      if (module_exists('unlimited_css')) {
        unlimited_css_preprocess_page($variables);
      }
      else {
        $variables['styles'] = drupal_get_css($variables['css']);
      }
    }