- Status changed to Needs work
almost 2 years ago 2:43am 27 January 2023 - πΊπΈ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.
- πΊπΈ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?
- πΊπΈUnited States mlncn Minneapolis, MN, USA
Everything gcb said certainly makes sense dropping in without a lot of context. We are getting "Data too long for column 'menu_name'" (for insert into menu_tree) on pressing "Manage Layout" which⦠no idea how a menu could be getting involved in the preview? Maybe there's something hooking on entity create and trying to create it and it has nothing to do with layout builder? Except the result is a white screen of death from layout builder.
- πΊπΈUnited States MegaKeegMan
@mlncn I was able to resolve that issue via a patch on https://www.drupal.org/project/drupal/issues/3087632 π MenuLinkContent menu_name max length is too long Needs work
However, I believe that we are running into this issue as well - πΊπΈUnited States MegaKeegMan
Well I am actually now a little unsure if this is the same issue, but I think it is. I am having this issue only on one of my content types, and it seems to only be breaking while generating sample content for a tag reference field. It is very strange because this same field is on several other content types, but only this one content type breaks. Additionally, it doesn't matter which display I am using. Default breaks just the same as Full, which is too bad because finding this issue had my hopes up that I could just avoid using Default. And lastly, whenever I hit my exception (invalid value) a new tag actually persists, despite the problem being that the value was invalid. Every time layout builder fails to render the preview, I get a new sample tag (taxonomy term).
- πΊπ¦Ukraine tibezh
I have the same issue, but on the Commerce.
On a clear (without any products) Drupal website the Layout Builder module tries to$entity = $entity_storage->createWithSampleValues($bundle_id);
The code should create a Product Variation, then generate a related product, again variation etc...