Building a flexible Frontpage has historically been a challenge in Drupal. Often, there is no fixed data model, and editors need the ability to quickly add, remove, or rearrange content. In this article, we compare how Canvas and Display Builder handle this scenario without relying on predefined fields, using only components. After all this will allows us to build all kinds of flexible pages, not just the Frontpage.
We also reveal which of the two projects we used for this very website.
Now this is where Canvas really shines. Canvas brings its own entity type canvas_page.
/canvas Add-Ons: From the Canvas UI we can also set the URL alias, basic SEO settings and even set a canvas page as Frontpage. We can also check different device widths.
Via the left sidebar we can simply add components and blocks:
/admin/appearance/component)Canvas understands some special prop schema (see canvas.json_schema.yml). When declared in your component it allows us to add rich text with basic formatting, upload images and embed videos directly in canvas.
This gives us a pretty nice toolset to build a Frontpage, or even hand over the task to an editor.
Once #3546597 lands, we can create canvas sites in different languages.
The problem is that Drupal's translation system sometimes does unexpected things. E.g. change config translation strings when modules are being installed.
That issue and the way Canvas works (the state of components are mirrored in config and are tagged with an active version) can lead to invalid config on deployment, see #3555538.
Display Builder is not yet as polished for this use case, but with a few workarounds we get there.
Display Builder is not opinionated when it comes to the content model. You can enable Display Builder for any entity type. In a default Drupal installation, you can use the basic page or if you're like us and start from the minimal profile, just create a dedicated content type (let's call it FlexiPage):
/admin/structure/types/manage/hda_flexipage/displayEnable content overrides./admin/structure/types/manage/hda_flexipage/display/node/1/displayNote: If you use the navigation top bar, a link Default Display appears in the context menu (top right). The link label is a bit misleading, because it actually is the Display Override.
Currently we can't place and edit formatted text or images directly in Display Builder. Since we also don't have any fields to place, the only option to add text directly in the display override is via placing a component:
The component prop mapping in Display Builder allows us to enter a string instead of selecting a data source. But that's just 128 characters and plain text. And it feels a bit like a hack. See #3587393.
For a Frontpage we need more: We want to add formatted text and images. Display Builder comes with a Content entityblock, that let's you include any entity. So after we built an entity type, e.g. a block type with a rich text or image field we can place it in Display Builder:
Content entity in category Other (Sidenote: It is not available in page layouts).This means that we need to create our content outside of Display Builder, e.g. a content block and then place it in Display Builder.
In Display Builder we deal with regular Drupal entities, so this limits the multilingual WTF potential to the known Drupal issues. So if we don't use the custom string option in the component prop mapper, content translations should work with Display Builder as well as without.
Symmetric config translations #3555110 seem to be in reach.
For SEO optimization, URL alias and Frontpage setting, we can use the known Drupal toolset.
Canvas performs strong in building feature rich Frontpages and offers a unified interface to get the job done. When used on a mono-lingual site, there is not much to be desired. The limitations e.g. for placing fields in slots, that we pointed out in Part 2 don't apply in this example.
Display Builder currently needs a few workarounds, but we are able to reach our goal. Given that this use case has not been a priority yet, we are happy with the results.
I hope that you now have a good understanding of how Canvas and Display Builder can help you build better Drupal sites. While both do similar things, they do it in very different ways. Canvas is very editor oriented and does not bother users with Drupalisms. Display Builder on the other hand builds on-top of the tightly integrated UI Patterns ecosystem which makes full use of Drupal's data modelling capabilities and design systems.
The goal is to make Canvas and Display Builder work well on the same site. Currently this is not possible, see Display Builder and Canvas issues.
After looking into both projects closely, we decided to build this very site with Display Builder, making full use of the page layout replacement (Part 1), display modes (Part 2) and the workarounds mentioned in this article to make the Frontpage work. If editors without Drupal knowledge would be tasked to update the Frontpage regularly, Canvas might have been the better choice.
Do you have any questions on publishing workflows, streamlining site building or other Drupal issues? Get in touch with us!
Special thanks to pdureau, laurii and penyaskito for reviewing this article.
Andi has a passion to make tech work for people. When he isn't building or debugging websites, he often finds himself digesting and prioritizing customer requirements, writing documentation and designing interfaces. He has a strong drive bringing teams and projects on track quickly and checking in with everybody before things go wrong.
