Contrib.social

Make building pages with proper data model using layout builder easy

Open on Drupal.org →
Created on 31 January 2019, almost 6 years ago
Updated 13 March 2024, 9 months ago

Problem/Motivation

Layout Builder is so wonderful that site builders are likely to abandon proper data models in favor of inline blocks with Layout Builder (LB).

Anecdotal evidence

This has happened on 3 recent/ongoing projects I've been a part of (2 small, one very large). And they were architected by different people!

Why does this matter?

Traditionally, the editor experience in Drupal has been one of its weaknesses, but the ability to model data properly / render in different views / devices / etc has been its primary(?) strength. My concern is that, by enabling 'inline blocks' in the LB which aren't tied to the data model but are very easy to use, the _majority_ of Drupal projects will be built with 'bad' data architecture.

Proposed resolution

Step 1: Support placing field delta values using LB: ✨ Provide single field values from multivalue fields as layout builder-friendly blocks Needs work
Step 2 (this ticket): Add the ability to create inline blocks which _are_ part of the data model on the fly in LB

Step 2 expanded:
Instead of creating inline blocks on the fly using LB, provide the ability to create inline field delta values on the fly (with the same UX as creating inline blocks).

If a user wants to use block types in the LB, the site builder would need(?) to create reference field(s) on the content type which reference the block type(s). Ideally, they would create semantically meaningful fields to reference specific block types. This would ensure that inline blocks are associated with fields, so we store what we need for Drupal goodness.

This could resolve some of the issues that I (ashrafabed) think webchick and eaton have blogged/tweeted about in the past month or two. Specifically regarding the balance between creating blocks on the fly, placing them 'anywhere' in your layout, and sometimes losing the 'meaning' or relationship of the block(s) relative to the content they are placed on.

So, on our content types, we could create 1 or more semantically meaningful multi-value reference fields which point to block type(s) {or to anything else}. On the LB, we could press 'place block', NOT have the ability to choose 'inline blocks', but rather we see only the fields on our content type. We could select a specific field of type Reference:block, and then create a value (an inline block) for that field within the LB interface, then place it in the LB.

This would necessitate inline blocks being stored in Reference:block fields on content types.

Backwards compatibility: in an update hook, auto-create a Reference:block field named "Inline Blocks" on all content types, and populate it with all inline blocks from that content.

Marked status as 'major' because this setup would change how people use the LB and, if the team decided to implement it, then it would be ideal to get it in ASAP.

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

✨ Feature request
Status

Active

Version

11.0 🔥

Component
Layout builder  →

Last updated 2 days ago

Created by

🇺🇸United States ashrafabed

Live updates comments and jobs are added and updated live.
  • Blocks-Layouts

    Blocks and Layouts Initiative. See the #2811175 Add layouts to Drupal issue.

  • Needs issue summary update

    Issue summaries save everyone time if they are kept up-to-date. See Update issue summary task instructions.

Sign in to follow issues

Comments & Activities

Not all content is available!

It's likely this issue predates Contrib.social: some issue and comment data are missing.

  • Comment 9 months ago →
    🇧🇪Belgium wim leers Ghent 🇧🇪🇪🇺

    #6 still sounds fantastic! It reminds me of what was discussed in the comments at https://wimleers.com/article/drupal-8-structured-content-authoring-exper... which talked about using CKEditor (4 even, so many years ago!) and CKEditor only to create content, including the structured data parts. For example: image uploads automatically could become image/media field values, just embedded automatically and transparently in CKEditor, using an additional filter and something like <drupal-field data-name="field_media" data-delta="1">. This is the Layout Builder equivalent of that AFAICT 😄

    (Today this is in principle possible using the media_embed filter's <drupal-media data-…> tags, see 📌 Ease the transition to Media: save image uploads in CKEditor 5 as media entities when media is enabled? Needs work .)

    #8 then backtracked and points out 3 issues:

    1. #2859995: Add Entity Reference Revisions to core → is flagged as a blocker, it's not clear to me why
    2. "Inline blocks often have multiple fields" → sure, but … often not? The slideshow example would nowadays be using images from the Media Library; media entities would themselves already contain the captions, and so … this seems viable even for that common case? Not for every case perhaps, but that's not necessary; inline blocks still continue to exist for those blobs/one-off things. The purpose of this issue is to make creating structured content the easier default, right?
    3. The difference in experience: relates to the prior point, but: if one (structure content) is simpler than the other (blob aka inline block), then that's fine?
contrib.social Blog FAQ Discussions
Production build 0.71.5 2024