Integration with Drupal core's new Layout Builder

Yeah, that would be awesome indeed! :)

You may want to look at #3016277: Add controls to style blocks placed by the Layout Builder. It would allow you to define a plug-in in this module with the form config for any classes that would be applied to the block.

Hi everyone,

Here is the patch, it depends on #2942661: Sections should have third-party settings.

One small fix.

Fixed to work with all sections types not only inline blocks.

Thank you @jidrone this will be great integration.

Just a note. This patch require https://www.drupal.org/project/drupal/issues/2942661 (this is related to 8.7.x-dev)

so this will work from 8.7.x Drupal core versions

Isn't this the right patch, that is required: #3015152: Support third-party settings for components within a section ?

The one, that was already committed to core only handles the sections themselves. Or do I miss something here?

Edit: It seems the issues has been splitted just recently.

With 8.7.0 and LB being out of experimental, I'd say this is even more important now.

Just tested the patch at #6 which needs the core patch #3015152: Support third-party settings for components within a section
However, there are a few issues after the patch.

1. Can't remove class once added
2. Removes the required classes in layout builder UI for drag and drop.

I totally agree with @Morbus Iff it's a crucial feature for block class to be compatible with the core Layout builder.

Also needs work:

3. On edit, the form field is below the "Update" button.

Here's a revised patch that:

* Allows you to remove a class entirely after it's been defined (#10.1)
* Retains the required classes for the Layout Builder UI (#10.2)
* Places the new form element above the Update button (#12).
** I really really hate how this is done with #weights though.

Just tested #13 patch above in conjunction with the required patch at #3015152: Support third-party settings for components within a section with Drupal core 8.7.1 and can verify that it is working.

I was able to add, change, and remove a class on the block in layout builder and the class appeared as expected on the top level block div.

Thank you.

Here is a new version of the patch, also all issues resolved with a better coding approach to remove classes and placement for the form element.

Initially the patch required was #2942661: Sections should have third-party settings, but on the following comment they decided to split the patch again https://www.drupal.org/project/drupal/issues/2942661#comment-12960039.

That is the reason why the needed patch now is #3015152: Support third-party settings for components within a section.

@jidrone: This appears to undo some of the things I fixed, such as:

* Inconsistent use of $section_component vs. $section_comp.
* Inconsistent whitespace in the new _alter (compare with the _alter below it; you'll see that there's starting/ending whitespace).
* Non-standard naming of the submit handler function.
* Submit handler function is far away from the form alter where it's used.
* The form element is back to being below the submit button on my installation.
** I agree: the #weight thing is utter crap; we should actually fix that instead of just ignoring it.

unsetThirdPartySetting is a good add though, I think. ;)

#13 with the #3015152 patch works for me as well

Uhh, not sure what just happened. I added a comment and it's saying I deleted files. Did not mean to do that if I did.

Hi @Morbus Iff,

Regarding the things mentioned in comment #16:

1. Yes, we can change all $section_comp to $section_component.
2. This is not an standard related issue.
3. Yes, we can set another name for the function, but this is not related to standard, just for consistency because this is related to all layout builder blocks.
4. The custom submit function is at last because the standard is the hooks should be the first on the .module file.
5. I don't know why in my case the form elements are wrapped in a settings element, I think it is because I'm also have field_layout module enabled.

Here is a new version of the patch:

• All references to section component named $section_component.
• More generic name for submit handler, there is no standard for custom submits.
• After some research in Drupal core code I found the settings wrapper for the form elements is there from the beginning, so this approach to place the textfield should work and is the right one.

> More generic name for submit handler, there is no standard for custom submits.

Here's how I infer a best practice on this.
I heartily agree it's not a _written_ standard.
I'd like to suggest it's an _implied_ standard.

1. First, we know that when we _create_ our own form, we get FORM_ID_submit and FORM_ID_validate for free.
2. We also know that when we alter a form, we must use hook_form_FORM_ID_alter.
3. From an IDE listing, completion, and bikeshed perspective, neither of the following examples are "pretty".

   Here, you can't infer that either of the functions are related:

   1. block_class_form_layout_builder_configure_block_alter
   2. block_class_inline_block_submit

   And here (which is the current patch), you're sOOo close that it gives me the heebee jeebees:

   1. block_class_form_layout_builder_configure_block_alter
   2. block_class_layout_builder_config_block_submit

   Why does one function use "form" and not the other? Why does one function use "configure" and the other uses "config"? The answer to both questions is: one function MUST to work properly. The other doesn't need to at all, but if you're going to make an attempt, make things look the same. In my head, you get better-organized code by standardizing (not "written code standard" but "agreeing on a single, unspoken, format in your own code, and being consistent about it everywhere") the function names, becoming:

   1. block_class_form_layout_builder_configure_block_alter
   2. block_class_form_layout_builder_configure_block_submit

It's the small difference between functional code and beautiful code.

The current function name smells.

Patch in #20 is working for me, and the move to 'settings' fixes the form element placement problem I was seeing.

+1.

I applied patch #20 and tested today. The block class form appears in the block settings sidebar in LB and the classes seem to be applied fine. I am getting the following error message printed on all LB applied node pages though:

Warning: Invalid argument supplied for foreach() in block_class_preprocess_layout() (line 68 of modules/contrib/block_class/block_class.module).
block_class_preprocess_layout(Array, 'layout__fourcol_section', Array) (Line: 287)
Drupal\Core\Theme\ThemeManager->render('layout__fourcol_section', Array) (Line: 437)
Drupal\Core\Render\Renderer->doRender(Array) (Line: 450)
Drupal\Core\Render\Renderer->doRender(Array) (Line: 450)
Drupal\Core\Render\Renderer->doRender(Array, ) (Line: 195)
Drupal\Core\Render\Renderer->render(Array) (Line: 501)
Drupal\Core\Template\TwigExtension->escapeFilter(Object, Array, 'html', NULL, 1) (Line: 126)
__TwigTemplate_f3b3c76cf68247a1118ae032451d9b30e64ae7b69af9a3c5b4d408dbfbec6f1e->doDisplay(Array, Array) (Line: 443)
Twig\Template->displayWithErrorHandling(Array, Array) (Line: 414)
Twig\Template->display(Array) (Line: 422)
Twig\Template->render(Array) (Line: 64)
twig_render_template('core/themes/bartik/templates/node.html.twig', Array) (Line: 384)
Drupal\Core\Theme\ThemeManager->render('node', Array) (Line: 437)
Drupal\Core\Render\Renderer->doRender(Array, ) (Line: 195)
Drupal\Core\Render\Renderer->render(Array, ) (Line: 226)
Drupal\Core\Render\MainContent\HtmlRenderer->Drupal\Core\Render\MainContent\{closure}() (Line: 582)
Drupal\Core\Render\Renderer->executeInRenderContext(Object, Object) (Line: 227)
Drupal\Core\Render\MainContent\HtmlRenderer->prepare(Array, Object, Object) (Line: 117)
Drupal\Core\Render\MainContent\HtmlRenderer->renderResponse(Array, Object, Object) (Line: 90)
Drupal\Core\EventSubscriber\MainContentViewSubscriber->onViewRenderArray(Object, 'kernel.view', Object)
call_user_func(Array, Object, 'kernel.view', Object) (Line: 111)
Drupal\Component\EventDispatcher\ContainerAwareEventDispatcher->dispatch('kernel.view', Object) (Line: 156)
Symfony\Component\HttpKernel\HttpKernel->handleRaw(Object, 1) (Line: 68)
Symfony\Component\HttpKernel\HttpKernel->handle(Object, 1, 1) (Line: 57)
Drupal\Core\StackMiddleware\Session->handle(Object, 1, 1) (Line: 47)
Drupal\Core\StackMiddleware\KernelPreHandle->handle(Object, 1, 1) (Line: 106)
Drupal\page_cache\StackMiddleware\PageCache->pass(Object, 1, 1) (Line: 85)
Drupal\page_cache\StackMiddleware\PageCache->handle(Object, 1, 1) (Line: 47)
Drupal\Core\StackMiddleware\ReverseProxyMiddleware->handle(Object, 1, 1) (Line: 52)
Drupal\Core\StackMiddleware\NegotiationMiddleware->handle(Object, 1, 1) (Line: 23)
Stack\StackedHttpKernel->handle(Object, 1, 1) (Line: 693)
Drupal\Core\DrupalKernel->handle(Object) (Line: 19)

The same error message is printed for each layout section used.

Also, I agree with @morbus-iff that the block_class_form_layout_builder_configure_block_alter
and block_class_form_layout_builder_configure_block_submit functions name seem more consistent.

Update: Forgot to mention, I applied the patch with Drupal 8.7.2. Not sure if something changed in that release to cause the error.

After applying patch on Drupal 8.7.x I got the error on cache rebuild:

The website encountered an unexpected error. Please try again later.
Error: Call to undefined method Drupal\layout_builder\SectionComponent::getThirdPartySettings() in Drupal\block_class\EventSubscriber\SectionComponentRender->onBuildRender() (line 39 of modules/contrib/block_class/src/EventSubscriber/SectionComponentRender.php). 

Same problem on Drupal 8.6.14 version.
@PCate, which version of Drupal core did you use when using this patch?

@PCate, which version of Drupal core did you use when using this patch?

Drupal 8.7.2

SectionComponent::getThirdPartySettings() error fixed via applying patch from #3015152: Support third-party settings for components within a section to Drupal 8.7.3 core!

I test this with my 2 sites, and it works well without any errors or warnings!

I update patch with renaming function block_class_layout_builder_config_block_submit to block_class_form_layout_builder_configure_block_submit, also remove unnecessary "new file" section.

@PCate, can you re-test my patch and check warnings?

Sorry, wrong test selected in previous patch file, 8.x version is not available for tests :(

The two new files added in previous patches are not required? How so?

Yes, sorry, I forgot add them to git, here is updated patch. It need to be applied together with patch from #3015152: Support third-party settings for components within a section for exclude fatal error.

After applying patch from comment #30 on Drupal 8.7.2 to Block Class 8.x-1.x-dev, I also get the mentioned error on comment #27:

The website encountered an unexpected error. Please try again later.
Error: Call to undefined method Drupal\layout_builder\SectionComponent::getThirdPartySettings() in Drupal\block_class\EventSubscriber\SectionComponentRender->onBuildRender() (line 39 of modules/contrib/block_class/src/EventSubscriber/SectionComponentRender.php).

Drupal\block_class\EventSubscriber\SectionComponentRender->onBuildRender(Object, 'section_component.build.render_array', Object) (Line: 76)
Drupal\webprofiler\EventDispatcher\TraceableEventDispatcher->dispatch('section_component.build.render_array', Object) (Line: 90)
Drupal\layout_builder\SectionComponent->toRenderArray(Array, ) (Line: 86)
Drupal\layout_builder\Section->toRenderArray(Array) (Line: 302)
Drupal\layout_builder\Entity\LayoutBuilderEntityViewDisplay->buildSections(Object) (Line: 261)
Drupal\layout_builder\Entity\LayoutBuilderEntityViewDisplay->buildMultiple(Array) (Line: 343)
Drupal\Core\Entity\EntityViewBuilder->buildComponents(Array, Array, Array, 'full') (Line: 22)
Drupal\node\NodeViewBuilder->buildComponents(Array, Array, Array, 'full') (Line: 285)
Drupal\Core\Entity\EntityViewBuilder->buildMultiple(Array) (Line: 242)
Drupal\Core\Entity\EntityViewBuilder->build(Array)
call_user_func(Array, Array) (Line: 378)
Drupal\Core\Render\Renderer->doRender(Array, ) (Line: 195)
Drupal\Core\Render\Renderer->render(Array, ) (Line: 226)
Drupal\Core\Render\MainContent\HtmlRenderer->Drupal\Core\Render\MainContent\{closure}() (Line: 582)
Drupal\Core\Render\Renderer->executeInRenderContext(Object, Object) (Line: 227)
Drupal\Core\Render\MainContent\HtmlRenderer->prepare(Array, Object, Object) (Line: 117)
Drupal\Core\Render\MainContent\HtmlRenderer->renderResponse(Array, Object, Object) (Line: 90)
Drupal\Core\EventSubscriber\MainContentViewSubscriber->onViewRenderArray(Object, 'kernel.view', Object) (Line: 76)
Drupal\webprofiler\EventDispatcher\TraceableEventDispatcher->dispatch('kernel.view', Object) (Line: 156)
Symfony\Component\HttpKernel\HttpKernel->handleRaw(Object, 1) (Line: 68)
Symfony\Component\HttpKernel\HttpKernel->handle(Object, 1, 1) (Line: 57)
Drupal\Core\StackMiddleware\Session->handle(Object, 1, 1) (Line: 47)
Drupal\Core\StackMiddleware\KernelPreHandle->handle(Object, 1, 1) (Line: 47)
Drupal\Core\StackMiddleware\ReverseProxyMiddleware->handle(Object, 1, 1) (Line: 38)
Drupal\webprofiler\StackMiddleware\WebprofilerMiddleware->handle(Object, 1, 1) (Line: 52)
Drupal\Core\StackMiddleware\NegotiationMiddleware->handle(Object, 1, 1) (Line: 23)
Stack\StackedHttpKernel->handle(Object, 1, 1) (Line: 693)
Drupal\Core\DrupalKernel->handle(Object) (Line: 19)

@altrugon, as mentioned in earlier comments (and again in #27), you need a core patch before this patch will work. Apply the latest patch from #3015152 first.

Here is a new version with a change that may fix the issue in #23 and the renamed submit, I provided and interdiff from 20 because it was the last with an interdiff and the only difference between #20 and #30 is the name of the submit function.

Looking good, jidrone.

@Morbus Iff, sorry I missed that core patch, my fault. As soon as I applied the patch to core and the latest patch from #33, things started to work. Thank you so much for your hard work, I'm going to change the status of the ticket to keep things moving forward. I also would like to mentioned that I tried to add a test, but the D8 version for the module was not available on the test form.

I applied both #33 to the latest block_class dev version and the core one to 8.7.3, but am still getting the same error I was in #23.

Is there another patch needed?

Warning: Invalid argument supplied for foreach() in block_class_preprocess_layout() (line 70 of modules/contrib/block_class/block_class.module).
block_class_preprocess_layout(Array, 'layout__onecol', Array) (Line: 287) Drupal\Core\Theme\ThemeManager->render('layout__onecol', Array) (Line: 437) Drupal\Core\Render\Renderer->doRender(Array) (Line: 450) Drupal\Core\Render\Renderer->doRender(Array) (Line: 450) Drupal\Core\Render\Renderer->doRender(Array, ) (Line: 195) Drupal\Core\Render\Renderer->render(Array) (Line: 501) Drupal\Core\Template\TwigExtension->escapeFilter(Object, Array, 'html', NULL, 1) (Line: 186) __TwigTemplate_b0269476c6682a3cd5cd589262516610d3c8eccea2d2cdb972c6a31fe29bfb2d->doDisplay(Array, Array) (Line: 443) Twig\Template->displayWithErrorHandling(Array, Array) (Line: 414) Twig\Template->display(Array) (Line: 422) Twig\Template->render(Array) (Line: 64) twig_render_template('themes/custom/nih_ohr/templates/content/node--layout-builder.html.twig', Array) (Line: 384) Drupal\Core\Theme\ThemeManager->render('node', Array) (Line: 437) Drupal\Core\Render\Renderer->doRender(Array, ) (Line: 195) Drupal\Core\Render\Renderer->render(Array, ) (Line: 226) Drupal\Core\Render\MainContent\HtmlRenderer->Drupal\Core\Render\MainContent\{closure}() (Line: 582) Drupal\Core\Render\Renderer->executeInRenderContext(Object, Object) (Line: 227) Drupal\Core\Render\MainContent\HtmlRenderer->prepare(Array, Object, Object) (Line: 117) Drupal\Core\Render\MainContent\HtmlRenderer->renderResponse(Array, Object, Object) (Line: 90) Drupal\Core\EventSubscriber\MainContentViewSubscriber->onViewRenderArray(Object, 'kernel.view', Object) call_user_func(Array, Object, 'kernel.view', Object) (Line: 111) Drupal\Component\EventDispatcher\ContainerAwareEventDispatcher->dispatch('kernel.view', Object) (Line: 156) Symfony\Component\HttpKernel\HttpKernel->handleRaw(Object, 1) (Line: 68) Symfony\Component\HttpKernel\HttpKernel->handle(Object, 1, 1) (Line: 57) Drupal\Core\StackMiddleware\Session->handle(Object, 1, 1) (Line: 47) Drupal\Core\StackMiddleware\KernelPreHandle->handle(Object, 1, 1) (Line: 106) Drupal\page_cache\StackMiddleware\PageCache->pass(Object, 1, 1) (Line: 85) Drupal\page_cache\StackMiddleware\PageCache->handle(Object, 1, 1) (Line: 47) Drupal\Core\StackMiddleware\ReverseProxyMiddleware->handle(Object, 1, 1) (Line: 52) Drupal\Core\StackMiddleware\NegotiationMiddleware->handle(Object, 1, 1) (Line: 23) Stack\StackedHttpKernel->handle(Object, 1, 1) (Line: 693) Drupal\Core\DrupalKernel->handle(Object) (Line: 19)

@PCate that is odd, I didn't have any issue after I applied the core patch. Have you tried to run drush updb and drush cr? Not that this patches need it but perhaps you have pending updates and you haven't realized about that.

@altrugon I had no database updates and cleared cache many times, same result.

Works fine for me,
I applied patches
#3015152: Support third-party settings for components within a section, #5
#2998114: Integration with Drupal core's new Layout Builder, #33.

Thanks

OK, I tested the patches again on another environment and I'm not seeing the error. Not sure if the previous error was a conflict with another enabled module or something.

Hi PCate,
Maybe it is related to your theme.

OK, I think I have been able to reproduce the error now.

It seems to happen when you save a layout with a section that doesn't have any blocks added to it.

Can anyone else reproduce this? I tested with both a custom theme and Bartik.

We can also see this in our tests. https://travis-ci.org/acquia/df/builds/551853337#L2024-L2041

I'd check when $variables['content'][$region_name] is loaded as to whether or not that key exists.

/**
 * Implements hook_preprocess_HOOK().
 */
function block_class_preprocess_layout(&$variables) {
  $layout = $variables['layout'] ?? NULL;
  if (!empty($layout->getRegionNames())) {
    foreach ($layout->getRegionNames() as $region_name) {
      foreach ($variables['content'][$region_name] as &$section_component) {
        if (isset($section_component['#block_class']['classes'])) {
          $classes = explode(' ', $section_component['#block_class']['classes']);
          $existing_classes = $section_component['#attributes']['class'] ?? [];
          $section_component['#attributes']['class'] = array_merge($existing_classes, $classes);
        }
      }
    }
  }
}

Looking at this right now - seems like a lot of assumptions are going on re: what will be available. Might help to break the function out into its own helper, I suppose?

Just because its a .module, we don't have to go down a route where we aren't checking variables as we're maybe afraid to add another if statement to this already nested statement. Something like _block_class_section_component_add($region_name); could stub in where a method or service is not available and keep things more sane. An actual service class that took care of these things, called by the hooks, would be even better.

Here's an attempt at checking the section component. Honestly having trouble re-creating this outside the functional tests we're running.

Just tested patch #45 and didn't run into any issues. The error message I was previously seeing for empty sections is no longer happening.

I think I've narrowed down where the "Warning: Invalid argument supplied for foreach() in block_class_preprocess_layout() (line 69)" error is coming from: a layout region that has nothing in it. If I define a layout with three columns, and put something in each column, I don't see the error. If I remove all the entries from one column, leaving it utterly empty, I get the block_class warning.

EDIT 1: Confirming #42.

EDIT 2: Looks like that was handled in #45 and I'm still running #33. Will retest.

#45 fixed the empty region warning for me as well.

+++ b/block_class.module
@@ -42,6 +60,33 @@ function block_class_form_block_form_alter(&$form, FormStateInterface $form_stat
+  $layout = $variables['layout'] ?? NULL;

Note: This is php7+ syntax And Drupal only really requires that with 8.8. Making it compatible with PHP5 with an extra isset() is probably easier than adding an explicit dependency to info.yml.

Also, a test for this would be nice, especially since layout builder is still actively improved and this is the kind of stuff that could change if forms/UI's are refactored.

+1

@Berdir: I agree with the test.

I don't agree with the PHP versioning comments and, if we're going to do "the right thing", it should be to encourage a newer version of PHP (i.e., the .info.yml change, which itself is probably unnecessary Right Now) and not an additional two lines of code for something that isn't actively supported Right Now (i.e., new 8.7.0 sites require PHP 7; only pre-existing 8.x sites are allowed to remain on PHP 5, cf. https://www.drupal.org/node/3044409).

I think is ok to make it compatible with PHP 5, because Drupal 8.6 is still supported and it can use that PHP version.

#45 not working

nginx_1      | 2019/09/08 04:08:12 [error] 43#43: *74 FastCGI sent in stderr: "PHP message: Error: Call to undefined method Drupal\layout_builder\SectionComponent::getThirdPartySettings() in /var/www/html/modules/contrib/block_class/src/EventSubscriber/SectionComponentRender.php on line 39 #0 [internal function]: Drupal\block_class\EventSubscriber\SectionComponentRender->onBuildRender(Object(Drupal\layout_builder\Event\SectionComponentBuildRenderArrayEvent), 'section_compone...', Object(Drupal\Component\EventDispatcher\ContainerAwareEventDispatcher))
nginx_1      | #1 /var/www/html/core/lib/Drupal/Component/EventDispatcher/ContainerAwareEventDispatcher.php(111): call_user_func(Array, Object(Drupal\layout_builder\Event\SectionComponentBuildRenderArrayEvent), 'section_compone...', Object(Drupal\Component\EventDispatcher\ContainerAwareEventDispatcher))

@batkor, see #31 and #32.

Thanks for the patch. I am getting an error when I install our custom profile because the block_class module is install before the layout_builder module. I was able to resolve this adding drupal:layout_builder as a dependency in block_class.info.yml. The error message I received is below.

OK
ResponseText: Error: Class 'Drupal\layout_builder\LayoutBuilderEvents' not found in Drupal\block_class\EventSubscriber\SectionComponentRender::getSubscribedEvents() (line 25 of /Users/Username/drupal-dev/issue271/www/modules/contrib/block_class/src/EventSubscriber/SectionComponentRender.php).

I've attached a modified patch.

It needs to use a class_exists() check instead, because people might want to use this without layout_builder.

Reroll of patch #45 using class_exists() as @Berdir recommended.

On clicking edit link of a block on a */layout page, I'm getting this error with #58 (and a lot of contrib installed):

AjaxError: 
ResponseText: Error: Call to undefined method Drupal\layout_builder\SectionComponent::getThirdPartySetting() in block_class_form_layout_builder_configure_block_alter() (line 38 of /var/www/html/web/modules/contrib/block_class/block_class.module).

edit: Sorry, I missed the required patch from #3015152-19: Support third-party settings for components within a section. Works nicely! See next comment.

With #58 my class was not rendered. #56 does not apply to latest dev. #33 is working for me.

For me #45 works well, with #58 class are not added to blocks on render, #55 failed to apply.

#63 is working for me on 8.8.0-beta1.

I missed that you also need the core patch from https://www.drupal.org/project/drupal/issues/3015152

So #63 works for me too.
Drupal 8.8.0-beta1
Block class 1.0

Is there an interdiff for this or is it just a reroll?

Here's the interdiff between the last two patches.

Just reviewed and tested the latest patch and it's looking good when applied to the 8.x-1.x-dev branch

This can't be RTBC. It relies on a core patch, which still needs work itself.

This patch (for Block Class) also needs to define the schema for the third-party settings it's adding to components. This work is blocked by work on the core patch, because the core patch doesn't define the schema for component third-party settings yet.

I've set the status to 'Needs work'; however, 'Postponed' would probably be more accurate due to the blocking core issue.

Let's make #71 explicit then. Postponed on the related issue.

I'm finding this does not quite work for me. I've applied the core patch as well.

The field appears within the block configuration form in Layout Builder and appears to function, however the class is never rendered to the block.html.twig template. This is because within function _block_class_layout_builder_add_classes() this line is never true: if (is_array($section_component) && isset($section_component['#block_class']['classes'])) {

This is on Drupal 8.8.1 and block_class 8.x-1.1

Edit: I take it back, it works! Somehow src directory and block_class.services.yml ended up outside of the block_class directory. I moved them and now it works.

Thank you for this! I needed to figure out how to add fields to the block config form in Layout Builder and I would have never figured it out if it weren't for this thread.

+++ b/src/EventSubscriber/BlockComponentRenderArray.php
@@ -0,0 +1,36 @@
+      $build['#block_class'] = $event->getComponent()->getThirdPartySettings('block_class');

is there a reason why this doesn't just set the attributes - that way we wouldn't need block_class_preprocess_layout or _block_clasS_layout_builder_add_classes?

There's a related module, Layout Builder Component Attributes, which allows for the following attributes to be added to Layout Builder components (blocks): id, class, style, data-*. It'd be an option to look at if someone doesn't want to get held up by a core patch.

Re #74, Layout Builder strips HTML attributes from entities when it renders them as components. I ran into this issue with the CSS Field module. I used the same workaround.

block_class.schema.yml needs the following added:

layout_builder.component.third_party.block_class:
  type: mapping
  label: Block class third party settings
  mapping:
    classes:
      type: string
      label: Additional classes for the block

Glad to see #3015152: Support third-party settings for components within a section is RTBC, which will hopefully be committed for the 9.1.0 release so that this issue can be (un)postponed!

Here is the patch for 8.x-1.3, based on #67.
update: Sorry for uploaded wrong file. Please look #81.

Sorry for upload wrong patch.

It would be a dream if Block Class, Block Classes, Block Attributes, and Layout Builder Component Attributes could all be refactored into a single solution and rolled into Core. With the Layout Builder, being able to add custom attributes to blocks is a game-changer, especially if you're using something like Bootstrap, it allows you to give editors/authors more control over layout. Being able to add attributes to both the block container, title, and content gives a lot of options.

Works for me on D9, take into account that you also need to apply the patch for drupal core mentioned in #39.

Rerolled patch against block_class-2.0.0. (Test coverage not available for this branch!)

Update -- my patch from #84 does not work -- in block_class 2.x, it does not show. In 1.x, it does not output the class.

Since 2.x is not yet recommended for production, we're using the patch in #81 with block_class 1.x for now...

Rerolling this patch based on #81 for 2.0.x compatibility.

#86 Patch does not apply, So moving this to needs work.

Patch seems to have missed the an empty line at the end. This one should work. Unfortunately testing is not enabled for the 2.0.x branch. Could you please test?

On most of our newer sites, we've switched over to using Layout Builder Component Attributes instead of applying this patch, and that works fine without requiring a core patch -- and does more than this, allowing you to specify id, data- attributes, inline styles on not just the block but also the wrapper and the title (if your theme injects the attributes correctly).

So we're now planning to convert our older sites that used this patch to use that module instead. I've opened an issue #3395068: Migration from block_class there to provide an upgrade path using a custom Drush command, if anyone else is interested.

Simply reporting that patch https://www.drupal.org/files/issues/2023-10-01/2998114-88.patch applied successfully on 2.0.11

  - Installing drupal/block_class (2.0.11): Extracting archive
  - Applying patches for drupal/block_class
    https://www.drupal.org/files/issues/2023-10-01/2998114-88.patch (https://www.drupal.org/project/block_class/issues/2998114 Integration with Drupal core's new Layout Builder)

@mmatsoo the previous patch may apply, but I don't think it actually works.

We have entirely moved over to Layout Builder Component Attributes for block classes within layouts (we still use Block Class with core block system placements).

On #3395068: Migration from block_class, I've posted code we successfully used to update block_class usage inside all node and taxonomy term layout overrides. This doesn't update block_class usage on "manage display" pages (the templates) -- for those we just searched our config for usage of block_class, moved the classes from the block_class field to the manage attributes field, and then we could export the config. The update function is for content with layout overrides.

Hope that helps anyone else stuck on this!

Thanks for sharing @freelock. Layout Builder Component Attributes seems really good.

For the ones still relying on block class for this matter, here's a patch for block_class 2.0.12

Is anyone using the patch successfully with D11? The field is displayed but the class doesn't seem to be saved.

Note: I'm using MR64 along with https://www.drupal.org/project/drupal/issues/3015152#comment-16285306 on Drupal 11.2.4 and it seems to be working as expected.