reveal.js

Theming with Bundle Classes, Layout builder and Twig

Daniel Veza

PreviousNext

Using Drupal since 2014

https://www.drupal.org/u/danielveza
https://github.com/DanielVeza
DanielVeza in DrupalSlack

Bundle classes

The first thing I wanted to go over is Bundle classes

Out of curiosity, who has used Bundle classes here already?

In my opinion, Bundle classes are one of the best if not the best addition to core in a long time.

Bundle classes let you define a PHP class per entity in your site. So you can have a bundle class for Nodes, Vocabs, Media, Block content and any other entity type like the User Entity.

It means you can keep business logic in one logical place per entity, saving developers from needing to dig around various places in the code to find what they're looking for.

Since they're just standard PHP classes, bundle classes allow you to reuse code across entitys with traits, interfaces, base classes etc

This leads to better code and the big win in my book, much cleaner testabilty, we'll go over this later

Another part of this talk is about Twig, and Bundle classes come with significant twig integration. Any function that starts with get or has can be called directly in your twig files. All of this leads to less preproccesses, since you already have all the functinality you need in your bundle class.

All this leads to less PHP in the theme, which I'm a big fan of.

Bundle classes are also opt-in, so for your existing sites you can slowly move code to bundle classes when new features or change requests come in, it doesn't have to be all done at once.

I highly recommend you look up some more on Bundle classes, sadly there isn't any talks on this conference on them, but I can't imagine going back to not using them.

One of the best new additions to core

Keep business logic in a single place per entity

Code sharing, interfaces and traits

Better testability

Twig integration & less preprocesses

Layout Builder

The next part is Layout builder

Layout builder has been stable for a long time now, so not quite the hot new thing anymore, but it's a really powerful site building tool

With Layout Builder you can set a base layout for your content types, and give editors control over the visual layout on a per node basis.

Editors can add or remove blocks, fields, media all with a pretty simple drag and drop interface.

In earlier versions of Drupal, this was possible with the Panels module but now we have a core maintained API

Something like this has also been done in the past with investing heavily in Paragraphs, but that required a lot of setup, config and code, and didn't give editors the same visual of how the page will look

Like I mentioned, with Layoutbuilder now in core, there is a suite of contributed modules we use to improve this further

One of the drawbacks of Layout builder out of the box is that all block become available to the editors to use

This means the editor can place any fields, which required Drupal knowledge about formatters. Editors shouldn't need to know that. In a recent site we have made a lot of blocks around a Program content type and they would all be visible for the editor to use on Articles, along with pointless blocks like "Made with Drupal."

To fix that we use Layout builder restrictions, which allows you to configure a list of blocks that the editor can see and embed on a per section basis.

And there is also Layout builder lock, which prevents editors from editing or deleting certain sections.

For example these can be configured so that you can't delete a hero section, or place a hero into a 2 column layout.

Common sense says not to do those things, but lets protect against it, just in case.

There is also Layout Builder Claro, which improves this drag and drop and the general feel of using Layout builder in cores claro theme

There is a talk tomorrow at 11 from Joshua Graham which is an overview and introduction to Layout Builder.

Editorial control of layout

Drag and drop interface

Twig

I'm sure everyone here is familar enough with Twig having build Drupal 8/9/10 sites, but for this project we have been using it extensively with a twig based Design system built with KSS.

Our extensive use of Twig allows us to match the components from our design system and have real control over our markup.

This cleaner markup has a lot of benefits including easier styling and performance improvements, since the DOM is less bloated with unnessesery elements.

I've loved and used Display Suite heavily in the past, but it's just not needed anymore with this approach, and not needing to click around all the options in the Manage display tab just to forget to hit save right at the end is something I'm glad to not need to do anymore.

DO NOT READ 6:47

Life Story block

27 lines of HTML, 10 divs for 3 fields

New Requirement is in!

0-5 Minutes - Short

6-10 Minutes - Medium

11+ Minutes - Long

Goodbye Manage Display

block--bundle--life-story.html.twig

umami_override.theme

Lets compare

Where are we now?

We've met the new requirement

Code is in the theme

Testing is difficult

Testing

Advanced

Add a base class per entity

Traits & code sharing

Design systems & Real world examples

When setting up Bundle classes, the cleanest option is to make a Base class per entity type and have all of your custom bundle classes extend that. In this case I've set up an abstract UmamiNodeBase classs that all of our node bundle classes would extend. It means that we can have shared functionality across all Node types on the site, like this get content type label function or a function that gets the publish date in a particular format. Another thing I've found useful is having one module per Bundle class, at least for nodes. That way if you know where to look if you need to find a particular bundle and keeps all of your business logic in a singular place per entity.

Bundle classes can also be easily moved between projects. This NodeBase could easily be moved to other projects.

Base classes per entity

Traits

Design systems & Real world examples

This preprocess is the secret sauce that links the bundle class and template together. It checks if the bundle class implements our Template aware interface, and if it does it attachs all the variables to the template with our getTemplateVariables function.

I know I bagged on preprocesses a bit earlier, but having this glue was the best way to manage this. At first we didn't have it and just used getTemplateVariables straight in the template but we couldn't add the right level of cachability to the block without it

Because this is preprocesses the generic block template, all we need to do when a new block is created is implement our getTemplateVariables function in the bundle class, and all variables are automatically passed to our template with no extra work.

Bundle classes resources:

https://www.drupal.org/node/3191609
https://ten7.com/blog/post/adding-bundle-subclasses-drupal-core-930-part-1

Layout Builder modules used:

Layout Builder claro
Layout Builder restrictions
Layout Builder lock
Layout Builder section classes
Layout Builder default blocks

Questions