Bowst Team
Drupal 8 – Get behind the wheel of the theming process
Let’s get one thing straight, while there are number of great pre-built Drupal themes out there, working with them can be difficult or even downright infuriating. Using a Drupal theme without comprehensive knowledge about the way it was built and how it is intended to be used can result in hours of frustration, even when trying to adjust something as simple as a meta tag or compiling the theme’s LESS files. While I have nothing against theme developers (some do excellent work), in my opinion there is a lot of room for improvement in documenting a theme’s functionality and patterns. Very few pre-built themes come with any kind of documentation at all. This fact, coupled with the flexibility of Drupal (which means little-to-no convention in how themes are built), can make it difficult for the developer to implement even minor changes.
Like the rest much of the rest of Drupal, Drupal 8 contained a completely overhauled theming system that makes it a breeze to get up and running with a custom theme. I recently developed a Drupal 8 site for some friends who just opened a restaurant in Ogunquit, Maine (incidentally, for those of you in the area, I highly recommend it – the tapas are out of this world) and was extremely impressed with how easy it was to spin up my own theme. Today, I’ll be sharing my experiences and (very strong) opinions on why building your theme from scratch will make your life a whole lot easier.
1 – Excellent documentation
Check out: https://www.drupal.org/theme-guide/8. Seriously, go there now and poke around a bit. It provides a step-by-step guide to go from scratch to theme awesomeness with power levels over 9,000! It provides a complete breakdown of the folder structure, file configuration, and even details on individual fields within YML files (which D8 uses for configuration). Huge props to the drupal.org users who took the time to write such a thorough guide.
2 – Benjamin Franklin would be proud – Libraries are totally awesome
Ok – so the devs working on the D8 theme system came up with idea which I think is 100% pure unfettered brilliance. CSS and JS files are not referenced directly by the theme; instead they are grouped into “libraries”. This lets you create reusable encapsulations of front-end assets. For example, I created different libraries for Bootstrap, Font Awesome, and non-project specific utilities. Libraries can even have dependencies – in the example below, the bootstrap library is depended on the core jQuery library. BTW – jQuery is no longer included on every page by default in Drupal 8. Instead you either load in a library as a dependency or reference it directly in the libraries associated with your theme.
All of this means that it’s super easy to start building a fresh and delicious new theme without having to manually set up all your standard vendor files. Just drop in the libraries you’ve developed and reference them in your theme. Or, even better, you could create a bare bones theme that includes all of your vendor libraries. In this case, your project-specific theme is simply a sub-theme of that bare bones theme thus inheriting all of it’s libraries and resources. The customization fun doesn’t stop at CSS and JS though, it extends into templates as well. For example, I like to override many of the drupal core templates to remove unnecessary elements and classes, which generates much cleaner markup.
3 – Twig rules and overriding templates is a cinch
So as you’ve probably heard by now, Drupal 8 uses Twig as its templating engine. Twig offers a TON of advantages over PHPTemplate, and (in my opinion) provides a much better developer experience. I feel much more at home templating in Twig, particularly given a more application based development background (using Ruby on Rails, Microsoft MVC, etc.). Twig templates provide much easier access to the “raw” data (i.e. field text, numbers, values, etc.) and thus much greater control over the surrounding markup.
The override system is basically the same as Drupal 7 – files in the theme templates folder are used based on specific naming conventions. However, when Drupal 8 is in develop mode the html output generated includes detailed information about which template is being rendered and override naming suggestions (see image below). Be sure to install the devel module to ensure that theme templates are rebuilt on each request. This will greatly decrease site performance during development but eliminates the need to aggressively clear caches during development. Don’t forget to disable this feature before going live!
Last word on templates – Drupal will look recursively through the templates folder to find files matching template naming conventions. This means that you can create whatever folder structure you like within your theme’s templates folder – which helps maintain organization even if you’re overriding many of Drupal’s core template files.
4 – Don’t be a passenger
When you use a pre-built theme, you’re basically back seat driving the development process. When you want something done, you have go through the user interface and politely ask the template to do what you want. Maybe it will listen to you or maybe it won’t – who knows? Unless you spend valuable time digging through the code files figuring out the inner workings of the theme, you have no clue how it’s supposed to work.
Don’t be a passenger; get behind the wheel and drive. When the designer comes back and needs you to add a hero region on some pages but not others, you know exactly how to define the region and set up all the necessary configuration. While it may take slightly more time to create the theme at the beginning of the development time, in the long run I’ve found that it saves countless hours fighting square-shaped pre-built themes into the round-shaped holes you need for your project.
