As part of our work on the Drutopia distribution we've contributed to a bunch of useful Drupal modules. One is Skins, used to offer different presentations of a Drupal site.
In a recent blog post, Drutopia co-lead Rosemary Mann highlighted how to use Skins on a Drutopia site. Here we take a deeper dive, looking under the hood at the requirements the Skins module meets and how to write a new skin.
Why we wrote Skins
When we spin up a new Drutopia site, we often want to customize the look and feel. For example, for the Rake and Radish farm website, we wanted to select fonts, colours, sizes, and other design elements for use sitewide, and also to make design changes to specific elements like the page title.
In Drupal the standard way of doing this is to develop a custom theme, usually by sub-theming an existing theme.
That works, but a new custom theme is a lot of overhead for each new site. Also, when building a site off of a distribution, there are certain technical challenges that come with working with sub-themes. If you want the messy details, see Drupal distributions, blocks, and subthemes.
That's why we wrote the Skins module. Our aim: the functionality of a sub-theme without the technical limitations.
What is a skin?
Skins allows you to define a set of different presentations for your site, all delivered by a single theme. Each look and feel is a “skin”.
We ship Drutopia with a default theme, Octavia. So for Rake and Radish we added a new skin, Radish, to Octavia. By doing so, we ensured anyone using Drutopia can have the new look and feel as an option, without having to switch to a different theme.
For the technically minded, this commit where we added the Radish skin shows what's involved in defining a new skin. Below, we go through each of the parts of a skin step by step.
The base case: customize the CSS
Our Octavia theme is based on the Bulma CSS framework. Since Bulma has a bunch of built-in variables, it's easy to customize your version of Bulma using SCSS to provide a whole different sitewide look.
Which is one of the easiest thing to do with Skins.
We start by adding the fonts the skin design uses and the corresponding SCSS. Then we customize a bunch of Bulma variables to get the design we want. The theme development toolset we're using will automatically compile the SCSS into a new customized radish.cssfile.
When a site administrator selects “Radish” as the current skin, that CSS file will be used instead of the default one the theme ships with. Presto, a new custom look!
Template overrides
But for Rake and Radish the design also called for changes to specific elements. For that, a custom sitewide CSS file isn't enough.
Themes in Drupal 8+ support templating in the Twig template language. So to change these elements, it was time to override some templates.
Drutopia includes a display of “actions”, which are presented with buttons that users can click. For the Radish skin, the design called for tweaking the button colour, size and outline.
Octavia makes extensive use of Bulma components, which are highly configurable. The Bulma button component supports a set of colours, sizes, and more, all of which can be specified using CSS classes.
So to customize the action buttons, we override a template, extending our default button component to add classes for colour, size, and outlining. Done!
Tying it together
The last step: register our skin with the Octavia theme. To do so, we added a section to the octavia.skins.yml file giving the theme a name, description, and screenshot.
With the skin in place, site administrators can select the Skin on the theme's configuration form.