Styling the Header and the Footer

In this chapter, we’ll start to use the components from the design system to style the header and the footer of the demo website.

You will learn more about how regions are used to manage the layout and how blocks are used to provide the content that surrounds the main page content. You will also learn how to provide a custom version of every template used by Drupal and how to suggest a specific template based on the context of a page.

We’ll talk about how menus are used in Drupal and how to style them. Finally, we’ll see how to provide more variables to templates not owned by us by preprocessing them.

By the end of this chapter, our demo website will have a fully styled header and footer and you will have learned how to map a Drupal template to a component from the design system.

The topics covered in this chapter are as follows:

• Regions and blocks
• How to override a template
• Template suggestions
...

Regions and blocks

We mentioned regions in the previous chapter, where we showed the block placement for the Olivero theme.

The regions that are available when a specific theme is enabled are defined by the .info.yml file of the theme itself. For example, for Olivero, that file is core/themes/olivero/olivero.info.yml and contains, among other things, these lines:

regions:
  header: Header
  primary_menu: 'Primary menu'
  secondary_menu: 'Secondary menu'
  hero: 'Hero (full width)'
  highlighted: Highlighted
  breadcrumb: Breadcrumb
  social: Social Bar
  content_above: Content Above
  content: Content
  sidebar: 'Sidebar'
  content_below: 'Content Below'
  footer_top: 'Footer Top'
  footer_bottom: 'Footer Bottom'

Now, check the same file for our custom theme (themes/alps_trips...

How to override a template

The templates provided by modules define a reference implementation of a specific theme hook. In our custom alps_weather module, for example, we’ve defined a couple of theme hooks and their related templates. But if you look at Drupal core, or at other contrib modules, you’ll find that they’re full of such reference templates. Starting from the internal elements, up to page.html.twig and html.html.twig, every portion of a page is built by a theme hook and its Twig template.

We do that to separate where data is built from where data is rendered in HTML, and to allow themes to provide an alternate version of default templates.

Defining theme regions

Our demo website is simple, so we need fewer regions than the default set provided by Drupal core. To define them, we need to add those lines to the alps_trips.info.yml file, inside the themes/custom/alps_trips folder:

regions:
  header: Header
  breadcrumb: Breadcrumb...

Template suggestions

The markup used to render the header region is probably different from that used to render the sidebar region, but both are generated from the same render array.

If we inspect the source of one of the pages of the demo website, we can see that the comments for the region theme hook are slightly different from the ones for the quote theme hook:

<!-- THEME DEBUG -->
<!-- THEME HOOK: 'region' -->
<!-- FILE NAME SUGGESTIONS:
   * region--header.html.twig
   x region.html.twig
-->
<!-- BEGIN OUTPUT from 'themes/custom/alps_trips/templates/layout/region.html.twig' -->
  <div class="region region-header">

There is a new kind of comment: filename suggestions. It says that Drupal is using the region.html.twig file from the alps_trips theme (because there is a cross near the name). However, it also says that Drupal should look for another file in the templates folder...

Styling menus

In Drupal, menus are used to navigate the site and provide you with the perception that the system has pages arranged in a filesystem-like structure. Every menu has a machine name and you can manage it using the Structure | Menu section of the administration (/admin/structure/menu).

Every time a new menu is created, using the administrative interface of Drupal, the System module creates a new block type as well. Then, using the Block layout form, we place an instance of that menu block in a region.

Menus are rendered by the menu theme hook and a suggestion is defined by default to allow us to provide a different template for different menus.

Note

You can use a render array to enforce which suggestion to select by using its name in the #theme key. For example, the block that exposes the main menu uses menu__main for the #theme key. If the suggested file doesn’t exist, Drupal falls back to the base theme hook (menu, in this case).

For the main menu...

Template preprocess

One of the advantages of render arrays is that rendering to HTML happens as late as possible in the final markup generation. Everything is an array until the very last minute.

We then have the opportunity to alter the render array that represents a region before it’s rendered to HTML.

For every theme hook, a preprocess hook exists that can be used to alter the variables sent to the template.

Preprocess hooks can be used to adapt variables to what a frontend needs, so they are usually defined in the theme itself – in our case, in the alps_trips.theme file.

We need to retrieve site_name, copyright, and a set of socials to be added to the list of variables sent to the region template:

function alps_trips_preprocess_region(&$variables): void {
  if ($variables['region'] == 'footer') {
    $variables['site_name'] =
      \Drupal::config('system...

Summary

In this chapter, we saw how we can provide our own version of a template to adapt the markup to provided design system.

We also saw how to find which template is used to render a specific section of a page and how to change it. We saw how the suggestions system works, how to use it, and how to provide a new suggestion for a template, based on some contextual information.

You learned how to extend a Twig block and how to style a menu. Finally, we saw how to preprocess a template to manage its variables.

We’ll style some more blocks in the future, but next, we’ll concentrate on the main page content. Chapter 6, Styling the Content, will provide you with all the information you need to manage editorial data.