Classes not being applied with Layout Builder

Confirmed this is an issue. Quite unfortunate since Layout Builder is the ideal tool where modules like this one will really shine. When fixed, this will let you preview the classes you add to your fields as you add them in the builder!

I should clarify that adding the classes in the Layout Builder "Configure Block" UI does appear to work, its just that you cannot see the class applied in the Layout Builder preview. You have to go through rounds of Edit Layout /=> Configure Block /=> Add a class /=> Save changes /=> View node /=> Edit Layout Configure Block /=> Edit incorrect classes.

Whoops! The issue is more convoluted that I thought.

So when I checked my Layout Builder page layout as an anonymous user, the classes added via this module are not there. The classes are only visible when logged in as an authenticated user. I triple checked myself to confirm, cleared all caches, etc.

I'm adding some type treatment classes to a "subhead" field, based on a bootstrap theme, h4 text-muted font-weight-light

This is what I see when logged in (correct styles):

However the same page as anonymous user:

HTML for authenticated user (correct styles):

<!-- THEME DEBUG -->
<!-- THEME HOOK: 'field' -->
<!-- FILE NAME SUGGESTIONS:
   * field--node--field-subhead--article.html.twig
   * field--node--field-subhead.html.twig
   * field--node--article.html.twig
   * field--field-subhead.html.twig
   * field--string-long.html.twig
   x field.html.twig
-->
<!-- BEGIN OUTPUT from 'themes/contrib/radix/templates/field/field.html.twig' -->

            <div class="h4 text-muted font-weight-light article__field-subhead" data-quickedit-field-id="node/68/field_subhead/en/layout_builder-default-0-cc8717c2_04fc_4857_8762_fabd3646d227-68-ff696cd745b3991c6c9f177c468c70c17d6288ccaeacd4ba506a6d515a77371f">Test syntax highlighting on a number of languages</div>
      
<!-- END OUTPUT from 'themes/contrib/radix/templates/field/field.html.twig' -->

HTML for anonymous users (incorrect)

<!-- THEME DEBUG -->
<!-- THEME HOOK: 'field' -->
<!-- FILE NAME SUGGESTIONS:
   * field--node--field-subhead--article.html.twig
   * field--node--field-subhead.html.twig
   * field--node--article.html.twig
   * field--field-subhead.html.twig
   * field--string-long.html.twig
   x field.html.twig
-->
<!-- BEGIN OUTPUT from 'themes/contrib/radix/templates/field/field.html.twig' -->

            <div class="article__field-subhead">Lorem ipsum dolor sit amet, consectetur adipiscing elit. Fusce ex nibh, commodo eget placerat at, laoreet sit amet lorem. Ut ut vehicula lorem, vitae aliquet augue.</div>
      
<!-- END OUTPUT from 'themes/contrib/radix/templates/field/field.html.twig' -->

Third party settings for authenticated user:

array(4) {
  ["label"]=>
  string(6) "hidden"
  ["type"]=>
  string(12) "basic_string"
  ["settings"]=>
  array(0) {
  }
  ["third_party_settings"]=>
  array(1) {
    ["field_formatter_class"]=>
    array(1) {
      ["class"]=>
      string(31) "h4 text-muted font-weight-light"
    }
  }
}

Third party settings for anonymous user:

array(6) {
  ["weight"]=>
  int(6)
  ["label"]=>
  string(5) "above"
  ["settings"]=>
  array(0) {
  }
  ["third_party_settings"]=>
  array(0) {
  }
  ["type"]=>
  string(12) "basic_string"
  ["region"]=>
  string(7) "content"
}

I've narrowed this down to what the value for the view_mode is that is being passed into the preprocess function.

When logged in, the view mode is node.article.layout_builder-default-0-cc8717c2_04fc_4857_8762_fabd3646d227-63-ff696cd745b3991c6c9f177c468c70c17d6288ccaeacd4ba506a6d515a77371f, but when unauthenticated the view_mode is just node.article._custom.

I'm currently exploring options to see if there is a way to figure out that layout builder view mode name from some variables somewhere.

I've confirmed that the '_custom' view mode is used by Layout Builder for on-the-fly rendering of fields in isolation from the entity.

I think I've found the upstream issue in Layout Builder

With the patch from #3015152: Support third-party settings for components within a section applied to 8.7.1, I'm still unable to access the third_party_settings from the preprocess_field function.

I've tried doing it both the current way that the module is written:

  $render_display = EntityViewDisplay::collectRenderDisplay($entity, $view_mode);
  $field_display = $render_display->getComponent($field_name);
  $field_display['third_party_settings']['field_formatter_class']

But the documentation for EntityViewDisplay::collectRenderDisplay make it sound like this way is going to be deprecated and points to using entity_view_display() which ALSO has a deprecation warning and suggests using:

  $view_display = \Drupal::entityTypeManager()
    ->getStorage('entity_view_display')
    ->load($entity->getEntityType()->id() . '.' . $entity->bundle() . '.' . $view_mode);
 

In fact Drupal 8.8.x introduced EntityDisplayRepositoryInterface::getViewDisplay().

Since I'm working on 8.7.x I cannot use that yet, but neither of the ways above produce the correct config even with the patch applied. Layout Builder's '_custom' view mode seems to still be stripping out third party settings.

It seems like the classes are reliably available in the $variables ($variables['element']['#third_party_settings']['field_formatter_class']['class']) passed to the preprocess function, whether you're rendering with Layout Builder or not.

Is there a reason it's necessary (or best practice) to go through EntityViewDisplay to get them? Getting the classes directly from $variables works in all contexts I've been able to test. I'm on Drupal 8.8.2, and the attached patch seems to work well (I have not patched core #3015152: Support third-party settings for components within a section). I'm curious if it works on 8.7.*

Lots of discussion of this issue in #3029627: FormatterBase should pass along third party settings -- I think you'd need to apply the patch there to get my solution working on 8.7.x.

See also #3018654: Fences seems to be ignored by Layout Builder in the Fences queue, where they landed on something similar.

Re #11: Both issues are now FIXED! So please retry the patch now against the latest version.
Could the maintainer enable automated tests here perhaps? ;)

Tested patch 10 working