Contrib.social

Fences seems to be ignored by Layout Builder

Open on Drupal.org →
Created on 6 December 2018, over 6 years ago
Updated 12 April 2023, almost 2 years ago

When using Layout Builder, if you configure a field, the fences form appears, but settings are ignored when the field is rendered.

Expected Behavior

I would expect the Fences settings configured in Layout Builder to be reflected when viewing a field.

Actual Results

Fences settings are completely ignored when fields are rendered on content using Layout Builder.

To Reproduce

  1. Choose a content type -> Manage Display, under Layout Options, choose "Use Layout Builder" and save.
  2. When the screen reloads, click "Manage layout", the default layout is fine for testing.
  3. Pick a field, hover over it and choose "Configure" from the context menu ( top right of the field ).
  4. In the configuration panel, set some markup options, like change the field tag to an H1, give it a class, doesn't matter.
  5. Click update and save the layout.
  6. Now view your node. All the default markup is still there and none of your settings are displayed.

Not sure where to go from here.

🐛 Bug report
Status

Fixed

Version

2.0

Component

Code (fences)

Created by

🇺🇸United States scottsawyer Atlanta

Live updates comments and jobs are added and updated live.
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 almost 2 years ago →
    🇨🇦Canada m4olivei Grimsby, ON

    Our experience is similar to some other folks here. We were using fences 8.x-2.0-alpha1, but updating to the latest 8.x-2.0 release broke many fields such that they were now showing a label and wrapping markup where they were expected not to. I narrowed it down to this change. Reverting this specific change on top of 8.x-2.0, making adjustments to Drupal core 8.x code deprecation removals in 9.x fixed our issue.

    Here is the patch that I'm testing. I'm using this patch on top of Fences 8.x-2.0 with Drupal core 9.5.7. Leaving this here for others that may find it useful.

  • Comment almost 2 years ago →
    🇩🇪Germany Anybody Porta Westfalica

    Thanks @m4olivei here's the diff:
    https://git.drupalcode.org/project/fences/-/compare/8.x-2.0-alpha1...8.x...

    And this is the commit you're talking about?
    https://git.drupalcode.org/project/fences/-/commit/ed9aed69981bdc2200b26...

    such that they were now showing a label and wrapping markup where they were expected not to.

    Could you give an example and tell what's the bug then? Is the result different from what's configured?

    Maybe you were "using" a bug before? I can't tell without an example or further details. If you're using the latest version and you're correcting / updating the settings, do they work as expected?

  • Comment almost 2 years ago →
    🇨🇦Canada m4olivei Grimsby, ON

    Hey @Anybody

    And this is the commit you're talking about? https://git.drupalcode.org/project/fences/-/commit/ed9aed69981bdc2200b26...

    Yep precisely.

    Could you give an example and tell what's the bug then? Is the result different from what's configured?

    Sure thing. An example is, after the bug, we end up seeing labels start to appear where they shouldn't as well as additional markup appear when it shouldn't:

    This is a result of the following conditions in the field.html.twig template now evaluating to TRUE in 2.0:

    https://git.drupalcode.org/project/fences/-/blob/8.x-2.0/field.html.twig...
    https://git.drupalcode.org/project/fences/-/blob/8.x-2.0/field.html.twig...

    They now evaluate to TRUE, b/c of the commit mentioned, since apparently, we were relying on the display logic that was present in alpha1, specifically the way that it used to fetch the default display mode when the view mode in the render array was not found.

    Maybe you were "using" a bug before? I can't tell without an example or further details. If you're using the latest version and you're correcting / updating the settings, do they work as expected?

    Yeah, this totally does appear to be a case of "using" a bug. While we could potentially update settings to fix the way the latest version expects things to work, reverting the logic is more expedient for us. It gets rid of all the regressions in one foul swoop.

    I don't expect that this would actually be commited to the project, just offering the patch in case it's useful to others who may be in a similar situation needing a pragmatic quick fix.

contrib.social Blog FAQ Discussions
Production build 0.71.5 2024