Drupal 8 is almost here, and it’s bringing big front-end improvements, including new methods to display data on mobile devices using breakpoints, build flexible templates in Twig and better management for tools and libraries.
Most importantly, changes to the display layer mean that Drupal has become much more agile and extendable for Front-end Developers.
The journey so far
Up till now, Front-end Developers have been working with a display layer that was originally introduced in Drupal 4.5, here’s how it worked...
PHPtemplate engine - Drupal 7 and its predecessors
The first real concept of abstracting and refactoring a theme layer was introduced in Drupal 4.5. It was written by Drupal community contributor Adrian Rossouw, known at the time as ‘Vertice’, who went on to build the PHPtemplate engine, starting with this post. You can also read a number of deeper discussions where other systems were evaluated.
The architecture of PHPtemplate was eventually introduced in D5 and retained through D7 and replaced by the Twig template system in D8. The components were built around the idea of something.tpl.php and theme_something(). Although this system was an appropriate choice at the time, significant improvements in front-end technologies have become standard, and the role of front-end developers have become defined, presenting a need for a more modern approach. Some examples for transitioning to a new system in d8 are:
- There is no "core" knowledge of mobile (e.g. breakpoints), requiring lots of CSS writing / template overriding to get to modern front-end practices.
- jQuery was required on every page, because there was no easy way to declare library dependencies.
- Front-End Developers are fluent in HTML, CSS, and JS -- and not always PHP. In D7 Theme Developers were required to have strong knowledge in PHP to get around the template system, forcing many non-PHP theme developers to use “snippets” of code they found to achieve tasks that could be parsed out in a simplified syntax as they are in Twig.
- Traditional PHP in the template system opens itself up to unnecessary security risks. For example, print methods without check_plain escaping the variable open the site up to XSS/CSRF vulnerabilities. In D8 and Twig, all variables are automatically escaped, enabling the Front-End Developer to spend time on design, not worrying about security issues.
The Drupal 8 engine: Twig and YML
If you’ve already had a look at D8, you’ll know that a lot has changed. Thankfully, from the point of view of Front-end Developers, most of it is for the better.
One area where these changes really shine is converting themes. Let’s look at what’s been carried through from past versions, what’s has been refactored and what’s completely different.
What’s similar or straight port
themeName.info becomes themeName.info.yml
The themeName.info.yml file utilizes the YML markup, which replaces the old .info file, but the intent is very similar. As in past versions of Drupal, this is where the theme meta and version information is stored, parsing references to CSS files (note that JS dependencies have moved to libraries.yml), as well as region definition.
template.php becomes theme_Name.theme
There have been some minor cosmetic improvements to this tool, but the purpose of themeName.theme has not changed from the former template.php.
something.tpl.php becomes something.html.twig
The only major change to the template system and suggestion engine in D8 is the replacement of traditional PHP with Twig markup. This makes it easier to read templates syntax and inherent underlying security measures that are built into Twig and ends the poor use of native PHP, such as non-escaped inputs.
What’s new
theme.libraries.yml
One of the stated aims of D8 is to become agnostic in the way it deals with different vendor libraries, so it no longer specifies jQuery, which was baked into the core and part of the theme layer by default in previous versions. This change introduces a new yml file to the theme layer, allowing the author to determine what libraries should be added in the presentation layer. For example, if your theme provides a custom script "scripts.js" which requires jQuery, here is what your custom_theme.libraries.yml file would contain:
theme-corescripts:
version: VERSION
js:
js/scripts.js: {}
dependencies:
- core/jquery
themeName.breakpoints.yml
One of the more useful changes to the presentation layer is the introduction of breakpoints for responsive theme (and module) development. So now you can use themeName.breakpoints.yml to define whatever media query make sense for your case. There are many other advanced uses cases that you can apply too, but adding flexibility and clarity to build breakpoints into templates is the big news here for Front-end Developers.
for example, your theme.breakpoints.yml may look like this:
mobile: '(min-width: 0px)'
narrow: 'all and (min-width: 560px) and (max-width: 850px)'
wide: 'all and (min-width: 851px)'
Where mobile, narrow, and wide could be used as variables in your template (or modules) to define different layouts.
Theme suggestion hooks
In previous versions of Drupal, the theme suggestion engine was handled by preprocessed functions to add the new template override.
D8 now has its own dedicated hooks for naming: function hook_theme_suggestions_HOOK
hook_theme_suggestions_alter(array &$suggestions, array $variables, $hook))
This means that naming is decoupled and you no longer have it hidden and attached to a preprocess function like it was in D7:
function MYTHEME_preprocess_node(&$variables) {
$variables['theme_hook_suggestion'] = 'node__' . 'my_suggestion';
}
Here is what the new function looks like in d8:
function MYTHEME_theme_suggestions_node_alter(array &$suggestions, array $variables) { $suggestions[] = 'node__' . 'my_suggestion';
}
Core page elements are abstracted out into blocks
D8 has worked toward an approach where page elements are no longer bound to the template, but available as separate blocks, leaving the templates a collections of regions. elements like primary and secondary menus are now blocks, and title, sitename, logo, tabs, and actions are also working toward being handled like this in the future.
backbone.js and underscore.js
in Drupal 8, backbone and underscore MVC frameworks are available for building AJAX based applications. You can use them by adding libraries with theme.libraries.yml file (See ‘What’s new’ to learn how to do that.)
Re-tooling for Drupal 8
Once you’ve come to grips with the DNA of the D8 theme, the next step is becoming familiar with the new architecture. Here’s how to make Drupal 8 a powerful tool for front-end development…
Learn Twig
It’s vital for Front-end Developers to understand the syntax and semantics of building templates properly using the power of Twig. For me, that starts with getting my development environment properly set-up. There are a variety of bundles and plugins for IDE’s that can help you do this. I’ve found this github project for sublime text to be very useful for highlighting and autocomplete. Drupal 8 Theme Guide is also full of examples of transition outputs from D7 to D8 that are extremely useful.
Setting up YAML files and syntax
The YAML syntax is used extensively throughout D8 for set-up and configuring. Learning to work with the YAML will give a deeper insight into the Drupal 8 core and theme layer.
Understand backbone.js and underscore.js frameworks
Although not a good fit for every project, both of these libraries are extremely powerful and flexible (they are also used throughout Drupal modules, such as Quick Edit and Toolbar). These MVC frameworks are often a good fit when you need to deal with data through models, where the data and associated validations need to be bound to an event, or changed in DOM. For example, If you’re building an application that allows you to select a seat at a stadium and has associated data attached to each seat (such as a unique cost) backbone framework can help make your display layer manage this data much more efficiently.
Utilize Breakpoints
As I mention above, utilizing breakpoints will simplify your CSS code and make it easier to manage different devices.
Remember, you’re a Front-end Developer - don’t get trapped in Drupal-land!
A healthy reminder not to get stuck and confined to the tools that are provided by the CMS, but solve these problems with tools and libraries that make sense for the job. D7 was simply not structured to give Front-end Developers all the options we need to build specific applications efficiently. D8 does a lot to change that by giving users the freedom to decide how to develop and output their code into a working Drupal theme. For example, now you can use a RESTful API and JSON output and display it with backbone.js or angular.js app.
You can also now organize your code with a Grunt tasks to manage your SASS and Lint setup or use distributions like Singularity for managing your grid system and media queries. Adding in these libraries is also easier thanks to the theme.libraries.yml file that allows you to package everything in on install. So, with the open-ended agnostic approach Drupal 8 takes with the front-end, Developers now have a much more powerful tool.
Transitioning to d8
As you can see, the transition to D8 for most Front-End Developers will be no small task, and for many, it will take a fair amount of ramp-up time before one is ready to develop a production site. A task that has helped me become prepared was to convert a easy existing d7 theme to d8. This allowed me to take a step back and and walk through each component of my theme one-by-one and map the changes. I would also recommend getting involved in the (still changing!) discussion and guide on drupal.org to get more examples and details what to expect. All-in-all the theme layer will ultimately give the the flexibility, simplicity, and structure to develop beautiful presentation layers!
