Exploring the demo site
Frontend development in Drupal usually starts very late in a project life cycle.
The typical steps are reproduced here:
- The design team has to create mockups, style guides, and the design system.
- The backend team has to set up the stack, initialize the project, and build the content structure.
- Some content needs to be created (manually or with some automatic process).
- Finally, the frontend team works on the frontend.
The main focus of this book is on the last step.
We could try to teach you how the theme layer of Drupal works in an abstract way, without implementing any real theme, or we could start from the first step in the list and make you do a lot of stuff even before you start to understand what a theme is.
We don't think this is the best thing we can do. Instead, we’ll take a little bit of an opinionated approach.
By simulating what happens in a typical project, we have already followed the first three steps for you.
We have implemented a fully configured Drupal 10 website, with a content structure and some example content. We’ve added some other modules that are quite standard in a modern Drupal website, such as Paragraphs (https://www.drupal.org/project/paragraphs).
We have created a design system (https://en.wikipedia.org/wiki/Design_system) and a style guide (https://en.wikipedia.org/wiki/Style_guide).
We’ve also defined how the project should run on your local machine. We’ve chosen for you where the code is hosted, the rules to enforce code quality, and the tools to use.
The demo website has enough features to let us talk about every aspect of the theme layer of Drupal 10, but it’s simple enough to avoid wasting time doing the same thing twice. We have a home page, some listing pages, a detail page, and some forms.
We’ve made a lot of assumptions to allow you to concentrate on the frontend layer only. But don’t worry—we’ll explain every decision we’ve made.
Because of this, the code in the book is not enough to replicate the demo website, so you have to start by cloning the Git repository from GitHub (https://github.com/PacktPublishing/Modernizing-Drupal-10-Theme-Development). We suggest you follow along with the explanations by trying them on your local computer—we’ll guide you step by step.
Let’s start by reviewing how editorial data is managed by Drupal and which concepts we’ll use during the rest of the book.
Fields
All information an editor writes in content using the Drupal admin interface is stored in fields. A field can have different properties, widgets, and formatters. Let’s look at these in a bit more detail:
- Property: Represents the data stored in the database—for example, a text area field has three properties: value, summary, and text format; a geographical field that represents a point on a map probably will have two properties: the latitude and the longitude.
- Widget: An element used by an editor to insert data into the field—for example, a
<textarea>HTML element for a text area, or two text fields for a geographical point (to input the latitude and the longitude). - Formatter: The markup used to show the field value on the frontend so that a user can read it—for example, a formatter for a text area can simply render the text, maybe truncated, whereas a geographical field can be rendered like a marker on a map.
Note
A single field type can have more than one supported widget and more than one supported formatter.
Paragraph types
A paragraph is not a concept that comes from the core of Drupal; it’s contributed by an external module called Paragraphs (https://www.drupal.org/project/paragraphs).
Modern layouts are built by aggregating components, and one possible way to manage such components in Drupal is by using the Paragraphs module.
Paragraphs are a collection of fields that together build a component. For example, a hero paragraph can be made of a background image, a claim, and a CTA button (composed of a label and a URL). A slider paragraph can contain a media field where the editor can insert a list of images to show in a carousel…. and so on.
You can define as many paragraph types as you need to allow editors to compose complex pages.
Content types
Fields and paragraphs are then aggregated into content types. A content type is a collection of fields, such as a paragraph, but with some added features. For example, all content built from a content type has a canonical URL so that it can be added to a menu and navigated by the end user.
Content types are used to represent the different structures an editor can insert into a website, such as a blog post, a landing page, a news page, and so on.
An instance of a content type is called a node.
Vocabulary
Often, it is useful to tag or categorize content, to add information to the end user or for it to be aggregated in some way.
For example, on the demo website, the Trip content type can be tagged by difficulty or by trip duration. To manage this kind of functionality, Drupal provides a taxonomy system, which allows you to manage the vocabulary of terms.
Blocks
Content types (and paragraphs) are not the only way to add editorial content to a website; the block system allows you to put contextual information around the main content—for example, on the header, the footer, or in a sidebar. Blocks are useful because they aren’t related to a specific URL, but they’re shown on a page based on a set of visibility rules. For example, you can place a block on the sidebar of every node of a particular content type, or for every user in a role.
Views
Content is usually aggregated in lists—for example, the latest blog posts or the trips available in a specific season. On a Drupal website, every time you mention a list of something, you’re talking about a view. A view is a collection of elements, extracted from the database using a set of conditions. A view’s output can then be shown at a specific URL or in a block.
Menus
In the end, a website is made of pages that can be navigated by the final user. Pages in Drupal are a mix of nodes, views, and blocks, and the navigation is managed by the menu system. A menu in Drupal is a hierarchical structure that stores a navigation tree. Every element in the tree has a label and a URL, which can be internal or external. A website can have more than one menu—maybe one for the main navigation, one with the user links, one for the footer, and so on.
Before starting to work on the design, we need to do just one more step: disable all the performance optimization that Drupal has out of the box.