Developers and organizations alike continue to use Drupal for large-scale projects due to its modular architecture, solid data model, community, security team, stability, and good-fit for many “ambitious” projects. However, historically, Drupal has caught considerable flak for its unintuitive development process - that might finally be changing.
I have been teaching Drupal development at Debug Academy ( https://debugacademy.com ) for over 4 years now. One recent development piqued my interest, especially in regards to teaching newcomers how to build sites using Drupal, and that is the new layout builder in Drupal core. The layout builder was released as an experimental Drupal core module in Drupal 8.6.
Drupal 8.6, and the layout builder (experimental at the time), were released on September 5, 2018, and our summer semester was scheduled to end on September 9th. Due to a combination of excitement and a desire to teach what I firmly believe to be the soon-to-be standard technique for building Drupal websites, we did not wait to use it. We built the entire website except for internal landing pages themselves before September 5th, the day the layout builder was released and 4 days before the conclusion of our semester. We combined custom block types with the new layout builder to finish building the website.
And my, it was easy to understand and to teach. Since then, we’ve integrated the layout builder more deeply into our subsequent semester and the results bode well for Drupal’s future. The client loved the new layout builder functionality, and the students who were newest to programming felt more comfortable than ever when laying out our custom landing pages. But don’t take my word for it, let’s take a look at the data.
How pages are built in Drupal
Common use cases for page creation include:
-
Advanced custom pages
-
Developers can build individual pages (routes) using raw PHP to pass information from various sources (such as internal or external APIs) to the page.
-
-
Standardized pages as content
-
Users create content (“nodes” in Drupal nomenclature) with standard layouts for displaying the content’s data.
-
-
Pages with custom overrides
-
Developers can override pages’ default output and pass additional data to specific pages with PHP.
-
-
Semi-structured content
-
Users can embed standardized “blocks” of content in or around otherwise standardized pages.
-
-
Drag & Drop content placement
-
Content editors can drag & drop specific types of content through UI onto pages.
-
Drupal’s solutions for these use cases
-
Advanced custom pages
-
Custom route built in PHP utilizing Drupal’s API
-
HTML with Twig
-
-
Standardized pages as content
-
Create pages using the UI. Similar to creating a blog post.
-
Without writing any code, site builders can also create pages featuring different types of fields using Drupal’s content type system.
-
-
Pages with custom overrides
-
Create pages using the UI. Similar to creating a blog post.
-
Pass additional variables (such as a newsletter block) to the page with PHP
-
Render variables using Twig
-
Write any markup (HTML) directly in the Twig file
-
-
Semi-structured content:
-
Create “paragraph” types (sets of fields)
-
Embed “paragraph” content within a field on the content type
-
-
Drag & Drop content placement (the new layout builder!)
-
Create pages using the UI. Similar to creating a blog post.
-
Use drag & drop to place / remove layouts, sections, fields, blocks, and more!
-
Can be done per content type and (optionally) overridden per page
-
Comparison of the content creation options in Drupal
Drupal provides an abundance of solutions to problems content editors face. Different tools require different skillsets, so although Drupal has solutions for everything, let’s do a deeper comparison of the Drupal 8 content editing options to see what is available, what it can do, and how accessible it is to you and your team. The new layout builder is highlighted in the rightmost column:
|
Advanced custom pages |
Standardized pages as content |
Pages with custom overrides |
Semi- structured content |
Drag & Drop content placement (new layout builder!) |
|
|---|---|---|---|---|---|
|
How to: initial set up |
|
|
|
|
|
|
How to: add'l pages w/same layout |
Depends on implementation |
Content editing |
Content editing |
Content editing |
Content editing |
|
How to: add'l pages w/custom field layouts |
|
N/A |
|
*Content editing * pre-grouped sets of fields must all be displayed sequentially |
Content editing |
|
How to: add'l pages w/custom layouts, including mixing & matching blocks, fields, & more |
|
N/A |
|
N/A |
Content editing |
|
How to: Component-based design support using Drupal blocks within content area |
Custom code only |
N/A |
Custom code only |
“Pre-grouped” fields can be designed as components, but placement is very restricted |
Fully supported |
|
Uses core/contrib |
Core |
Core |
Core |
Contrib (paragraphs) |
Core (experimental - full release expected in 8.7!) |
In practice: what do the numbers show?
Through our courses we have been able to collect data about how the switch from other approaches (namely PHP / Twig & paragraphs) to the new layout builder has impacted the learning curve, productivity, and ongoing maintenance of projects. Debug Academy’s Jack Garratt ran the numbers for us. For the sake of our analysis, a “task” refers to the smallest unit of work assigned to a developer (Debug Academy student, in this case):
The data: before the layout builder (“Tasks to homepage”)
Let’s take a look at the data following the number and type of task from the start of the project until the completion of the frontpage and set up of internal pages. In the first data set, we’ll look at our projects before use of the layout builder.
We assigned our students to implement PHP pre-process hooks to create Twig variables for Views blocks, blocks provided by contrib modules (e.g. newsletter), as well as extracting other non-block data from the website. Note: There are alternatives in Drupal’s contrib space to using PHP, such as the contributed module Twig Tweak; we do not encourage using Twig Tweak in our projects. The project builds are a success; however, it is also not the most readily grasped by non-web developers and clients.
The breakdown is below:
|
Task Type |
Pre-layout Builder |
|---|---|
|
Up to & including homepage (without layout builder) |
|
|
Twig |
17 (task per section per page) |
|
Site Building |
14 |
|
Configuration in Code/Site installation and setup) |
7 |
|
CSS/SASS |
6 |
|
PHP/Custom Module |
10 |
|
Initial Theme setup |
3 |
|
Set up reusable inner page layouts (4 content types) |
|
|
Twig |
8 |
|
PHP |
4 |
|
CSS/SASS |
4 |
PHP and Twig tasks constitute a significant number of the total amount of work completed by our students. Out of the 17 Twig tasks, we deemed that 10 required using PHP to pass various blocks to the homepage for a variety of use cases, such as embedding Twitter or a Donately form within the page’s content.
On subsequent projects, our students are constructing the pages in the Layout Builder.
The data: using Drupal’s new layout builder (“Tasks to homepage”)
The Layout Builder UI has access to the aforementioned block types. If there is a specific need that cannot be readily replicated with custom block types with the requisite fields, developers can still use Twig to add that functionality. However, we found that creating and styling custom block types in Drupal 8 core as reusable components (see component based design) greatly streamlined our process and eliminated the need for many higher complexity tasks.
What we soon realized was that writing PHP and Twig was less needed in terms of individual page construction, but still rather helpful in crafting custom blocks (components).
|
Task Type |
With layout Builder |
|---|---|
|
Up to & including homepage (with the new layout builder) |
|
|
Twig |
5 (task per component type) |
|
Site Building |
18 |
|
Configuration in Code/Site installation and setup) |
7 |
|
CSS/SASS |
6 |
|
PHP/Custom Module |
0 |
|
Initial Theme setup |
3 |
|
Set up reusable inner page layouts (4 content types) |
|
|
Twig |
1 (we’re reusing component types) |
|
PHP |
1 |
|
CSS/SASS |
1 |
One of the consequences of the de-emphasis on using Twig to create basic pages with custom HTML in favor of the layout builder is allowing a more beneficial division of labor. Teams may create more tasks that involve basic page building to get their newer developers familiar with the Drupal UI. Moreover, companies can train their clients in how to create basic pages with customized blocks (video block, stylized quote block, or a button block to name a few), which minimizes the instructional curve. Essentially, the tasks to create highly customized pages no longer require coding. One consequence of using the layout builder for basic page creation in this manner is that it will free up more experienced developers to focus on other tasks or minimizing oversight of newer developers.
The data: full comparison, beyond the homepage
The above charts compare “time to homepage” and “time to generic inner page”. Where you really start to see the benefits are when you’re creating a website with many pages. Let’s look at the combined charts, calling special attention to the newly added last row(s) “Creating additional pages with custom layouts”:
|
Task Type |
Pre-layout Builder |
With Layout Builder |
|---|---|---|
|
Up to & including homepage |
||
|
Twig |
17 (task per section per page) |
5 (task per component type) |
|
Site Building |
14 |
18 |
|
Configuration in Code/Site installation and setup) |
7 |
7 |
|
CSS/SASS |
6 |
6 |
|
PHP/Custom Module |
3 |
0 |
|
Initial Theme setup |
3 |
3 |
|
Set up reusable inner page layouts (4 content types) |
||
|
Twig |
8 |
1 (reusing component types) |
|
PHP |
4 |
1 |
|
CSS/SASS |
4 |
1 |
|
Creating additional pages with custom layouts |
||
|
Twig |
37 |
2 |
|
PHP |
16 |
4 |
|
Content Editing |
47 |
69 |
|
Site building |
45 |
17 |
Thanks to a combination of component based design and the new layout builder, content editors can create truly custom layouts without writing a line of code. They can, for example, drop a video embed in between the body field and the author field, move the author field to the footer, and arrange other fields in 3 columns without writing a line of code.
Summary & Conclusion:
This specific project built with the layout builder required:
-
88% fewer PHP tasks
-
64% fewer site building tasks
-
87% fewer Twig tasks (thanks to component based design)
-
46% more content editor tasks
The numbers are clear. Drupal’s layout builder has the potential to bring down the cost of ownership of Drupal websites significantly by enabling content editors and less senior developers to build more of the website. Because of which, the new layout builder will make Drupal more accessible to newer developers and smaller organizations with ambitious goals for their web-powered presence.
It’s time to get up to speed in Drupal 8!
Debug Academy's real projects are the source of the above data, and we encourage you to take a look at our programs. There has never been a better time to add Drupal to your skillset.
We will continue to incorporate cutting edge tech in our courses, including the new layout builder, Composer, Drush, Drupal Console, Object Oriented Programming with PHP7, and much more, all applied to a real, unique, team project! At the end of it all we help students continue to the next phase of their careers! Visit https://debugacademy.com to sign up for one of our free info sessions - our next semester begins January 27th!
P.S. thanks to Dries Buytaert for providing feedback on this post!