Responsive Theming for Drupal (2014)
Chapter 2. Responsive, Meet Drupal
So this responsive web design stuff is all fine and good, but isn’t this book supposed to be about Drupal? Well, you want Drupal, and Drupal you shall have. Let’s talk about adding responsiveness to a Drupal 7 theme.
A Bit of A Primer on Drupal Theming
Before we get too deep into the weeds on making Drupal responsive, let’s back up a bit and talk about Drupal theming in general to make sure we’re all on the same page. To start, you should be familiar with the following terms:
Drush
Drupal’s command-line interface. It gives you commands for doing things like clearing cache, updating modules and themes, running arbitrary PHP within the context of a fully bootstrapped Drupal, syncing databases and files between environments, and much much more. It’s basically a must-have for any and all Drupal developers at this point.
Base themes
Used as the basis for subthemes, these provide a lot of commonly used theming functionality to be inherited, extended, and altered for your use.
Subthemes
Custom-built themes that inherit from base themes. For example, if you use the Zen base theme, you could build a subtheme that lists Zen as its base theme, telling Drupal to load everything in Zen first and then load everything in your subtheme, some of which might alter or override the Zen defaults.
Moving on from there, you need to understand the basic anatomy of a Drupal theme. There are a few common files you’ll find in just about any Drupal theme:
THEMENAME.info
This file contains metadata about your theme, such as its human-readable title, its base theme, and a description. It will also contain Drupal.org-generated version info for any themes downloaded from Drupal.org.
template.php
This file is for preprocess functions. This gives your theme a chance to alter variables after Drupal’s backend is done generating them but before they touch the templates. So, for example, if you want to change the way that breadcrumbs are rendered, you would write aTHEMENAME_breadcrumb() in your theme’s template.php that gets passed the raw breadcrumb array as a parameter so that you can have full control over how rendering and markup look.
theme-settings.php
This file is built to handle exactly what the name indicates—custom settings for your theme. This gives us the ability to add custom GUI configuration fields to our theme that we can then use in the theme’s code. Some base themes take this quite far and provide GUI-based options for layouts, colors, fonts, and more.
tpl.php
These files, sometimes lovingly called “tipplefips,” are your templates. Once Drupal sends data to your theme and your theme’s template.php file has had a chance to alter it, it is finally delivered to individual templates to build the markup. There are many different types of templates, such as the top-level html.tpl.php (which contains the <head> tag), the page.tpl.php (which contains the basic page markup including regions and containers), and individual content templates like node.tpl.php or templates for views, panels, or blocks.
With this under our belts, let’s get back to our regularly scheduled responsive design discussion.
Adding the Media Queries
As we discussed in Chapter 1, the heart of coding a responsive design is adding media queries to specify which CSS applies to which screen resolutions. At a basic level, this can be done in Drupal just like it would be done outside of Drupal—just put the media queries into the theme’s CSS file(s). So, for example, if your theme’s main CSS file is at sites/all/themes/turnip/css/style.css, all you’d have to do to add responsive styles is to open up that file and drop in a few media queries.
The location in the file tends not to matter, but remember that CSS rules are evaluated from top to bottom. So if the same selector appears in two different places, the CSS rules in the second instance of it will trump the rules in the first instance. For example, if you set the color of paragraphs in one location in a CSS file, and then set it to a different color later in the CSS file, the second rule will win.
There are more advanced ways to do this, which we will discuss later. But there’s nothing stopping you from doing it the old-fashioned way, and many people do just that.
Adding the Viewport Meta Tag
Remember from Chapter 1 that there are two pieces to the puzzle: the media queries and the viewport meta tag. The media queries set up the device-specific styles, and the viewport tells mobile devices not to zoom out on the page.
In Drupal, this means we’ll have to edit the html.tpl.php file in our theme, since that is the file that contains the <head> tag, which is where the viewport meta tag needs to go.
NOTE
There are modules to make it a bit more user friendly to add things to your <head> tag, such as Add To Head, if you prefer to do it in the GUI. However, be sure to consider whether it’s worth adding the bulk of a new module to your site for something as trivial as this.
If you’re using a base theme, there’s a good chance it already contains an html.tpl.php file that you can override in your subtheme. If not, you’ll need to copy it from modules/system/html.tpl.php and paste it into your custom theme so that you can override it.
Once you have your own copy in your theme, just edit it and paste the following somewhere in the <head> tag:
<meta name="viewport" content="width=device-width, initial-scale=1">
Moving on to Base Themes
Although this basic technique works fine, and many people consider this standard practice, there are smarter and fancier ways to go about it with the help of some more advanced base themes.
But first, let’s talk about the “why” of base themes. Why is it useful to start from someone else’s code when every site has a completely different design? Why not just start your themes from scratch? You can, and you wouldn’t be alone in doing so, but you’d be missing out on a lot of useful stuff that base themes provide. They can bring you things like Sass integration, a responsive grid system, some solid default styles for common Drupal elements, and more. Heck, Omega 3.x is even more or less a GUI layout builder.
Sure, you could do all of this yourself in a 100% custom theme, but if you go that route then you have to think about the giant wheel you’re wasting your time reinventing.
Why wouldn’t you just edit and customize the base theme directly? Why add the extra layer? There are a few reasons:
§ You get a clean slate to code on rather than hacking at a preexisting codebase.
§ You don’t have to fully comprehend any of the base theme’s code in order to use it productively, whereas editing it directly requires a deeper level of understanding.
§ You can easily apply updates to the base theme without losing your customizations.
§ You can have multiple custom themes (whether it’s for a multisite setup with a few similar looking sites or a site with different themes for different sections) and have them share the bulk of the heavy lifting in a base theme.
So how do they work? The basic concept of a base theme is one of inheritance. Typically there is a generalized contributed theme used as a framework (or “parent,” to continue the inheritance analogy) in addition to a fully custom-built subtheme that overrides, customizes, and makes additions as needed (i.e., the “child” theme or more commonly, the subtheme). A subtheme will inherit 100% of its base theme’s code despite not having any of that code within itself, which leaves the themer with a solid starting point and a lot of useful features.
Using a Base Theme
But how does the code look?! It’s quite simple. Each theme (whether it’s a base theme or a custom subtheme) has a .info file that holds metadata about it (name, description, screenshot filename, etc.) and one of the things that you can tell Drupal from within the file is whether or not your custom theme has a base theme, and if so, what it is. A subtheme that inherits from a base theme might sport a .info file that looks like this:
name = Yourtheme
description = Super-duper awesome thematic action.
version = 1.0
core = 7.x
engine = phptemplate
base theme = zen
stylesheets[all][] = style.css
stylesheets[print][] = print.css
See the magic line there? You’re right, it’s the one that starts with base theme. That alone is all you need to tell Drupal that your custom theme inherits from the “Zen” base theme. If you created a subtheme named “yourtheme” with only one file named yourtheme.info, and listed Zen as the base theme in that file, then effectively using “yourtheme” as your site’s theme would be exactly the same as just using Zen, because it inherits all of Zen despite the fact that it has no code of its own.
Therefore, all you need to include in your subtheme are customizations, things you’re overriding, and additions.