fromMarch 2013
Column:

The Angry Themer

Removing Module Provided CSS Files
0

In this article, let’s explore the art of removing, once and for all — with a few little magic tricks — the clutter of CSS classes and irritating CSS that you never need.

As a frontend developer, working in Drupal can be a bit of a hassle. One of the things that always shocks a new themer is where all those damn CSS files are coming from and what they’re supposed to do. Even more important: how to remove those that aren't needed.

The way Drupal works is that every module and its grandma brings along its own CSS file, which is intended to make everything work “right out of the box.”

That’s all fine and dandy, but let’s be honest here: we don't want to schlep any CSS around unless it's absolutely necessary for the site. Extra CSS is sloppy, makes the site slower and, let's not forget, you will end up spending days to overwrite CSS that was provided as a default. (Thanks but no thanks, Drupal.)

Drupal provides easy ways to clean up the CSS and make your theme lean, mean, and clean — let's take a look.

For this example we will use the buttermuffin.css file and the evil imaginary module “buttermuffin” that provides horrible CSS (imagine div{border:2px solid #900}) We have at least four options for changing the CSS into something useful:

  1. Overwrite the CSS.
  2. Copy the module's CSS file(s) (buttermuffin.css, etc.) into your own theme and change them there.
  3. Find the CSS Objects And Disable — FOAD!
  4. Show your mad preprocess skills and remove it.

The first option is the usual way an unscrupulous developer would tell you, “Just overwrite the CSS.” That, of course, is not the way an angry themer wants to work. Not only is it tedious, but it doesn't remove the problem.

The second option is more flexible. In the theme's .info file, you can define CSS files that you want to load in your theme. This is also the way to overwrite the module's CSS files.

To do it that way, you will copy the CSS file from its module and place it inside the theme. For example,
copy buttermuffin.css from /modules/buttermuffin/buttermuffin.css to the theme directory sites/SITENAME/THEMENAME/css/buttermuffin.css. After clearing the cache, the theme knows it should load buttermuffin.css from the theme instead of the module.

The contents of your .info file would end up looking something like this:

styles[] = css/style.css
styles[] = css/buttermuffin.css

If you just want to get rid of the CSS files you don't need, then the third option may be easiest. All you need to do is remove them out of the module. Or, as old battle-hardened themers call it: Find Objects And Disable — FOAD.

The trick here is to call the CSS files from your theme .info file as you would do in the previous example, but don't copy the file over. Your theme's .info file ends up looking like:

styles[] = themename.css
styles[] = node.css
styles[] = comment.css
styles[] = buttermuffin.css

Drupal thinks that you have style.css, node.css, comment.css, and buttermuffin.css files in the theme because they are listed in the .info file. However, Drupal won't load the files that don't exist in your theme, so you'll end up skipping the loads for the CSS files you don't want.

This way, it's only themename.css that will be loaded into your site.
Some may consider this a dirty trick, but we professionals call it a Very Useful Feature.

The final option is to preprocess out the unwanted CSS. If you want to impress your developer friends, you could give this a try. Write a css_alter hook to pull out the unwanted CSS files:

function THEMENAME_css_alter(&$css) {
  unset($css[drupal_get_path('module', 'buttermuffin') . '/buttermuffin .css']);
}

See http://api.drupal.org/api/drupal/modules%21system%21system.api.php/funct... for more information on the css_alter hook.

As you can see, there is hope for Drupal after all! There is no reason to put up with unwanted CSS clutter. Don’t get frustrated, don’t get angry; smile and take out the garbage.

Advertisement

From our blog

Entity Storage, the Drupal 8 Way

In Drupal 7 the Field API introduced the concept of swappable field storage.

The Drupal 6 to 8 Upgrade Challenge - Part 2

Having concluded the readiness assessment, we turn next to migrating the content and configuration. In reality, there’s little chance that we would migrate anything but the blogs from our old site. For the sake of giving Migrate in Core a workout with real conditions, however, we’re going to upgrade with core’s Migrate Drupal module rather than rebuilding.

The Drupal 6 to 8 Upgrade Challenge - Part 1

Nathaniel Catchpole , the Drupal 8 release maintainer and Tag1 Senior Performance Engineer, suggested that Drupal shops everywhere could support the

DrupalCon Austin

The entertainment industry is not for the faint of heart.

Drupal Watchdog Joins the Linux New Media Family
Drupal Watchdog 6.01 is the first issue published by Linux New Media.

Drupal Watchdog 6.01 is the first issue published by Linux New Media. Come see the Drupal Watchdog team at DrupalCon 2016!

Drupal Watchdog was founded in 2011 by Tag1 Consulting as a resource for the Drupal community to share news and information. Now in its sixth year, Drupal Watchdog is ready to expand to meet the needs of this growing community.

Drupal Watchdog will now be published by Linux New Media, aptly described as the Pulse of Open Source.

Welcome to DrupalCon Barcelona - The Director's Cut

For all you schedule-challenged CEOs – and ADHD coders – this Abbreviated Official Director’s Cut is just what the doctor ordered.

Welcome to DrupalCon - The Barcelona Edition

Did we have fun in Barcelona?
OMG, yes!

Did we eat all the tapas on the menu and wash them down with pitchers of sangria?
Yes indeed!

Recursive Closures and How to Get Rid of Them

This came up while manipulating taxonomy children and their children recursively, so it’s as not far from Drupal as you’d think.