Contrib.social

Layout builder's use of sample data can cause exceptions during rendering of default entity view displays

Open on Drupal.org →
Created on 19 July 2019, almost 5 years ago
Updated 27 November 2023, 6 months ago

Problem/Motivation

When layout builder renders a layout preview on entity view display defaults (not overrides), it creates an entity from sample data. This sample data can cause problems downstream in code that assumes the entity, or it's entity references, will actually exist and have IDs.

For example, if you have a taxonomy term reference field block configured to use "rendered entity" formatter, then template_preprocess_taxonomy_term will run, which calls $term->toUrl()->toString();, which throws an uncaught EntityMalformedException because you cannot generate URL for an entity without an ID.

This problem was somewhat recognized in #2950892: Exceptions thrown during Layout Builder preview are not caught → . The solution implemented there was to swallow any exception that occurs during the process used to build the render array for the field and just return a placeholder block. This solution does not work if the exception occurs during rendering though.

Proposed resolution

This is a tricky one. I think you'd need to force early rendering of the field block to bubble any exceptions up so that they can be swallowed too. I also think that it may be worth just disabling field block previews entirely when working on entity view display defaults? I'm going to try and write a patch for that so I can get past this blocker for my project.

Remaining tasks

User interface changes

API changes

Data model changes

🐛 Bug report
Status

Needs work

Version

11.0 🔥

Component
Layout builder  →

Last updated about 11 hours ago

Created by

🇺🇸United States bkosborne New Jersey, USA

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

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

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 over 1 year ago →
    🇺🇸United States SocialNicheGuru
  • Status changed to Needs work over 1 year ago
  • Comment over 1 year ago →
    🇺🇸United States tim.plunkett Philadelphia

    There was a suggestion made for 8.9 but that isn't passing tests and may not be the agreed upon solution.

  • Comment about 1 year ago →
    🇩🇪Germany Anybody Porta Westfalica

    I'd still appreciate feedback on my progressive enhancement (examples on top, to not break things and have lightweight labels by default) suggestion in #12 if anyone feels to have a valid opinion ;) :)

  • Comment 6 months ago →
    🇺🇸United States gcb

    I have to agree with @Anybody here. While it certainly sounds reasonable to ask all contrib modules to respond coherently in preview mode, it's not realistic: this is the perfect being the enemy of the good. If Drupal's standards for publishing modules were different, or if the feature sets offered by fully mature modules were more complete, this would be fine. It's not, and this issue has cost our clients a LOT of money, as well as frustration.

    How hard would it be to catch exceptions and put something in the preview like, "preview failed for this field" below the field name in those cases? This would highlight contrib fields that needed attention without showing a whitescreen to users. It would also make it easier for developers to debug!

    I have this whitescreen right now and it appears to be coming from a combination of entity references and the use of Tokens. Token is a pretty well-supported module... but there's a bug reported for it in the queue 🐛 Error: "The 'node' entity cannot have a URI as it does not have an ID" when using [node:url:relative] token Postponed: needs info that points back to this issue, and the maintainer basically saying "sounds like a layout builder problem".

    As a site developer, my options here are to stop using token, to hunt down the bug in token and submit a patch (which the module developer is convinced they don't need, so I may have to maintain it indefinitely), or to apply this funky patch to layout builder that sort of blows up the entire preview behavior anyway.

    I've been through this with a dozen different modules at this point. As a result, my org is very unlikely to ever use layout builder on a new site again -- it just wastes too much time hunting these things down. I like layout builder, and I want to use it! Can't we just be a little bit more accepting of our imperfections and put some safety measures in place?

contrib.social Blog FAQ Discussions
Production build 0.69.0 2024