Add block classes for bundle and view mode

For the test case, I followed the below step.

1. Create a basic page.
2. Create a block & assigned to basic page.
3. With the assertRegExp() try to verify the class name.

But after checking this I did not found, drupalGet() return class name of the newly created custom block.
Please correct me if I am wrong.

I worked for my failed test case & I found when I changed in twig file & run test case(core/tests/Drupal/KernelTests/Core/Theme/ConfirmClassyCopiesTest.php), I found a hash value is generated against the changed file which is not matched.
The file location of HASH Value matching is core/tests/Drupal/KernelTests/Core/Theme/ConfirmClassyCopiesTest.php.
Can anyone help me to match the HASH value of the changed file?

sorry for the noise, un-assigning so others may review it

#17 does the job.
Tested it on multiple block types and in layout builder.
One thing to mention if you are using a custom theme, you need to add the classes to your block.html.twig.
The following is for easy reference:

{%
  set classes = [
    'block',
    'block-' ~ configuration.provider|clean_class,
    'block-' ~ plugin_id|clean_class,
     bundle ? 'block--type-' ~ bundle|clean_class,
     view_mode ? 'block--view-mode-' ~ view_mode|clean_class,
  ]
%}

I'll keep the status "Needs Review" so maybe someone else could try it out too.

Just rerolled the patch in #17, thanks!

Just tested #23 and works for me. Moving to reviewed.

We still need test coverage and a change record. As the changes in the issue show a themer will need to update a theme in order to take advantage.

+++ b/core/profiles/demo_umami/themes/umami/templates/classy/block/block.html.twig
@@ -30,6 +33,8 @@
+    bundle ? 'block--type-' ~ bundle|clean_class,
+    view_mode ? 'block--view-mode-' ~ view_mode|clean_class,

Also I'm wondering if using type here is correct - at least without indicating that we mean content block type. This feels like it might be confusing because other blocks do not have a type. Same for view mode.

Here's a reroll of the patch in #17 for 9.5

Core/Theme/ConfirmClassyCopiesTest.php
themes/bartik/templates/block.html.twig
core/themes/classy/templates/block/block.html.twig
could not find these files.
Rerolled for 10.1.x.
Please review.

Added a simple asserting to an existing test.

Also please this belongs under the block_content module.

Would like some feedback before making the change record.

I'm not convinced that this is a good idea at all. We're conflating a block_content concept into a block template.

I have no worries about adding the prepreprocess hook, but adding them by default to the base templates feels like overreach.

Checked and applied patch it is working for 10.1.x

Please read the comments and tags too. #33 discuss this not being the correct approach and it was tagged for change record.

Changed preprocess to add classes instead vs relying on template.

Took a shot at the CR also.

+++ b/core/modules/block_content/block_content.module
@@ -51,6 +51,19 @@ function block_content_theme($existing, $type, $theme, $path) {
+    $variables['attributes']['class'][] = 'block-type--' . $variables['elements']['content']['#block_content']->bundle();
+    if (isset($variables['elements']['#configuration']['view_mode'])) {
+      $variables['attributes']['class'][] = 'view-mode--' . $variables['elements']['#configuration']['view_mode'];

I'm still not convinced adding these classes across the board is the right approach.

Personally I want less Drupal noise in my templates, not more.

Should we be instead taking the approach node takes, which is to add additional theme suggestions?

i.e so block--block-content--{bundle} and block--block-content--{bundle}--{view-mode} works out of the box?

That seems to be what we're doing in #3062376: Template suggestions for custom block view modes

Can see both scenarios where one may want to add css targeting a specific class without having to override the template.

I'm still not convinced adding these classes across the board is the right approach.

Personally I want less Drupal noise in my templates, not more.

Should we be instead taking the approach node takes, which is to add additional theme suggestions?

i.e so block--block-content--{bundle} and block--block-content--{bundle}--{view-mode} works out of the box?

I'm sort of leaning that way as well. It always bothers me how much markup Drupal can spew out onto the page. There's also the question of sites which may not even want to expose their internal naming to end users. It's probably not a security concern, but personally I might find it a bit annoying.

Building on that thinking, this does make me wonder if we should instead provide template suggestions for all [content] entities out of the box. This is a case of boilerplate code which at some point every entity type (core or contrib) is probably going to come up against.

Yeah, I still think #3062376: Template suggestions for custom block view modes is the best approach here, @AaronMcHale seems to agree. Should we close won't fix this?

I asked in #frontend for others to chime in.

For posterity, for a very long time our frontend workflow has been to use something like BEM to bring order to class naming, preferring to override templates to use class names that are meaningful to the project.

Theming using Drupal generated classes is considered an edge-case/last resort when you can't change the markup and typically isolated in CSS files under the heading 'Fugly selectors' 😛

FYI not married to the idea here if the consensus is it’s not needed.

Adding a preprocess hook is also very simple.

I'd prefer to avoid this... theme suggestions and variables sure, but classes output by default means more things I need to override and strip out.

Thanks @smustgrave @nedjo @rikki_iki