Developing an admin theme in Drupal

From the very beginning, I used to wonder if there are any fancier alternatives to the "drupal blue" interface we take for granted in Drupal admin themes. I then discovered the best fit(so far) in Rubik. Since Rubik, not much has happened in admin theme space. I'd rate shiny as a close second.

How much effort goes into creating a fancy looking admin theme from scratch? Is it very straight forward and easy? I first decided what an admin theme would need to have:

  • configurable interface I don't mean the configurable theme settings(which is useful though). I should be able to cook up my own color and font combinations.

  • shouldn't be a subtheme by itself. Rubik has this problem. It needs Tao. Not sure why exactly, but having 2 themes for admin increases my code footprint a lot.

  • Responsive ain't needed. We don't need admin themes to be responsive.They are going to be used by site editors in their desks. So, we can rule out all device support safely for admin themes. Responsive bartik seems to have a different take on this.

  • icons, icons. Visual iconography is sparesely used in most admin themes, excepting rubik. This needs a lot of improvement, given the advent of tools like fontawesome.

With these design goals in mind, I started brewing a simple admin theme for Kalvi. The choice of tools needs a brief mention here.

SASS

No brainer. To have a configurable UI of sorts(goal #1), this was quintessential. SASS is "dev configurable" and meets the goal perfectly. I might switch to a non ruby based setup(like libsass/node) sometime in the future.

FontAwesome

From whatever research I did, no admin theme uses Fontawesome. I believe this could be a great combination instead of using image icons.

Rubik adds icons using the theme_admin_block_content function. I adapated the same code. Font awesome needs a slightly different approach.

Here's the SASS code for adding Fontawesome icons via code:

@mixin icon($icon) {
  @extend %icon;
  content: $icon;
}

@mixin icon-before($icon, $padding: 10px) {
  &:before {
    @include icon($icon);
    padding-right: $padding;
  }
}

%icon {
  font-family: FontAwesome;
font-weight: normal;
  font-style: normal;
  display: inline-block;
  text-decoration: inherit;
  line-height: 1;
}

If I wanted to add an icon to a class, I just needed to call the "icon-before" mixin with the appropriate icon glyph, like

@include icon-before($icon-cubes);

I had to do some dirty hacks too, like add warning, info and error icons by changing the DOM via js. Drupal could use some theming flexibility here. core maintainers, please take note.

iCheck

I was bored of the stock checkboxes and radio buttons. Turns out this guy was too, and he created iCheck. I used it to customize the look and feel of option elements in forms.

Bower

We're just getting started and already 2 3rd party dependencies. Bower was the defacto tool to manage frontend dependencies. Note that these needs to be explicitly checked in, as Drupal.org does not package bower dependencies, though I hope it does some day as Bower is becoming increasingly indispensible for frontend dependency management.

Grunt

Maninly used for grunt watch. Compiles SCSS to CSS and reloads the page if any js/CSS files are modified. There are a lot of tools popping up in this segment, like Gulp.js and Broccoli.

Susy2

Layout and grid systems are misunderstood as only meant for responsive design. I presonally find semantic grids(especially the clean syntax of Susy2) very productive for general HTML layout.

A few git commits and several doses of caffine later, this is what I end up with.

Noule Screenshot

Why .npm?

I spent a couple of frustrating hours with a strange issue where drush crashes silently when I try to enable the theme. This had to do with node_modules directory containing .info files and drush wrongly interpreting it as a module/theme. The solution was to move all node related tools to a .npm directory. Apparently, drush does not traverse directories beginning with a dot. This is documented here and here.

List of common elements

Admin themes don''t need lots of regions, unless you are doing something creepy. But you have to take care to have a checklist of items to be themed:

  1. form elements
  2. breadcrumb
  3. color scheme
  4. pagination elements
  5. warning, error messages

Other cool TODO ideas

  1. convert it to a frontend framework based theme(like bootstrap, semantic UI or Bourbon) for uniformity's sake.

  2. Create a specialized UI for panels/panel based workflow(IPE).

It is not the perfect Drupal theme, but at least I shipped it. Download it from drupal.org. Let me know what you think!