XB week 23: PageTemplate

Bálint “balintbrews” Kléri and Jesse Baker fixed a funny bug: the component inputs form was unscrollable, which meant that using Experience Builder (XB) in small viewports (or with complex components that have many inputs), you just couldn’t reach them 😅🙈

Dave “longwave” Long and I simplified the way XB represents Component config entity IDs, a small next step towards supporting multiple component types. It will now feel more familiar for anybody used to dealing with Drupal’s configuration.

Ted “tedbow” Bowman and Dave introduced basic auto-saving (much future work left to be done):

The Drupal Association started defaulting to version 1.6.3 of the GitLab CI template on October 15, as they announced in GitLab CI templates will make Drupal 11 the default version to run back in August. Cool! Except … any contrib module with more complex testing needs will have customized the CI, and that was now automatically broken too, because the 1.6.x CI template changed CI job names 😬
Yay for versioning, because Dave fixed this by simply pinning XB’s CI template to extend the 1.5.x one instead.

Some minor bug fixes by Atul “soaratul” Dubey and Travis Carden also landed.

This week’s big leap forward was led by yours truly 1 (and reviewed by Dave) to pave the path towards XB product requirement 19. Modify the page template (i.e. global sections), which Lauri “lauriiii” Timmanee captured as:

As a builder, I want to modify the page template (i.e. page.html.twig). When I modify the page template, I can place components globally to global regions like navigation, header, footer, etc.

In other words: the ability to not use Drupal core’s existing “Block Layout” (/admin/structure/block) functionality, but to instead use XB to achieve the same.

That will mean not using Drupal’s default page variant (BlockPageVariant), but an XB-provided one.
Fun fact: I helped a decade ago to finalize exactly this infrastructure ahead of Drupal 8’s release,  created the official Drupal 8 render pipeline diagram, and talked about it! The part XB will be using for this functionality is RenderEvents::SELECT_PAGE_DISPLAY_VARIANT 🤓

XB needs to know what component tree to show in each theme region, so those need to be stored somewhere. For that, I introduced the PageTemplate config entity, which:

• exists 1:1 per theme (so: one such config entity per installed theme)
• can store multiple component trees (one per theme region)
• is thoroughly validated:
  • every region must be have a component tree in the config entity (or be null if it’s empty)
  • every of the 3 special blocks must be present exactly once:
    • a block that implements MainContentBlockPluginInterface — to display the result of the matched route’s controller
    • one that implements TitleBlockPluginInterface — to display the title returned by that same controller
    • and finally, a MessagesBlockPluginInterface one — to display messages
  • plus more details 2
• is used by XB’s new PageTemplateDisplayVariant to render the stored component trees.

It leaps ahead of where the rest of the XB codebase is at, because it assumes there’ll be Block-sourced components, whereas currently XB only supports SDC-sourced components! And that’s where the path that we paved last week (and improved this week) already is being trodden! 🥳

That’s how I was able to write a test that proves in <100 LoC that XB’s page variant works as expected, despite a lot of other infrastructure not yet existing. Hence I was confident that the rest of the team could build all the necessary UI pieces and blocks-as-components infrastructure while I’d be out! 😊

Week 23 was October 14–October 20, 2024.

• 1

  I was trying to get ahead of the rest of the team in anticipation of my upcoming paternity leave, little did I know it’d already be next week 😅

• 2

  Full detail in the config schema if you’re interested!