Drupal problem solving: Broken CSS in IE

Submitted by David on 28 May, 2010 - 11:56
tagged with

Every now and then you run into an unforseen problem for no apparent reason. It can be quite a task to unravel what has gone wrong - especially when the answer is nothing... at least not with Drupal. Because a website relies on a number of different technologies all working together in relative harmony in order to properly serve pages, sometimes the fault may lie with the peripheral technologies. This blog will explore broken layout and themes in Internet Explorer and highlights the importance of testing development sites on multiple browsers.

During the normal course of developing a Drupal based website, it is likely that you will build up a repository of contributed modules to enhance the core with additional features and functionality. Each module, once installed and enabled adds its own modifications to the site. For example, it may add tables to the database, it may require additional styling or introduce additional script files.

The standard method for including script or CSS files into a webpage is by referencing them from the <HEAD> section of a webpage. Each module adds whatever it needs to this section and as time goes by you can end up with a large number of included files here. This in itself is not a problem, except for the fact that Internet Explorer has a limitation in terms of the number of included files it can handle. Exceed that number and it simply ignores them - no warnings or errors.

So you might happily develop your website using Firefox or Chrome but when it comes time to test everything out, the site looks mangled and hideous in Internet Explorer. The precise problem is difficult to pinpoint immediately because which stylesheets or scripts are ignored can depend on the order in which they are included, so you might get wildly differing results depending on what you are looking at.

If you've noticed that the site is broken in IE but looks fine in other browsers then there is a solution to the problem. In the Performance section under Site configuration in the administration menu, Drupal provides us with the ability to aggregate CSS and script files for performance purposes. The idea being that a single, aggregated CSS file is much quicker to upload than say twenty individual CSS files. Enabling aggregation should solve the problem...

There is a problem with this solution however - several problems. The first being that aggregation and caching is not your friend while you are still developing your website. It is better to leave these settings until deployment otherwise it can be difficult to observe the effects of any changes made to your stylesheets or scripts if everything is cached and aggregated.

The second problem is actually a Drupal bug - if you will (resolved in Drupal 7 I believe). Drupal is unable to aggregate files if the file download method is set to private. This is only a problem if you really have to have complete control over downloads from your website. If you are happy to allow public downloads then you can happily aggregate CSS and script files 'til the cows come home.

If you have to have private downloads and file aggregation then you'll need to either upgrade Drupal to the latest version - Drupal 7, or set the file download method to public and work on your .htaccess file to try and enforce some sort of security through the server instead. Take a look at the .htaccess file in Drupal 7 to get a feel for how this can be achieved.

People who share are more likely to succeed:
  • del.icio.us
  • Digg
  • Facebook
  • Google
  • Google Buzz
  • LinkedIn
  • MySpace
  • Newsvine
  • Reddit
  • StumbleUpon
  • Technorati
  • Twitter
  • Yahoo