[wp-trac] [WordPress Trac] #65120: Add `wp_elements_block_supports_class_name` filter to `wp_get_elements_class_name()`

[WordPress Trac]

#65120: Add `wp_elements_block_supports_class_name` filter to
`wp_get_elements_class_name()`
-------------------------------------+-------------------------------------
 Reporter:  baikare.sandeep007       |       Owner:  (none)
     Type:  enhancement              |      Status:  new
 Priority:  normal                   |   Milestone:  Awaiting Review
Component:  Editor                   |     Version:  trunk
 Severity:  normal                   |  Resolution:
 Keywords:  has-patch needs-testing  |     Focuses:  css, performance,
  has-test-info dev-feedback         |  coding-standards
-------------------------------------+-------------------------------------
Changes (by sanayasir):

 * keywords:  has-patch needs-testing has-test-info 2nd-opinion => has-patch
     needs-testing has-test-info dev-feedback
 * focuses:  template, performance, coding-standards => css, performance,
     coding-standards


Comment:

 Tested the patch by applying the proposed filter:

 ```php
 add_filter(
     'wp_elements_block_supports_class_name',
     function( $class_name, $block ) {
         return 'my-test-class';
     },
     10,
     2
 );
 ```

 Expected result:
 The generated `wp-elements-*` class should be replaced with the custom
 class name (`my-test-class`).

 Actual result:
 After applying the patch and clearing caches, the updated CSS class was
 not generated in either the editor DOM or the frontend output. The
 original generated class behavior remained unchanged.

 Additional notes:

 * Tested multiple times with different callback return values.
 * No custom class name appeared in the rendered markup.
 * It appears that the filter may not be executed in the current rendering
 path, or the generated class is not being applied to the final output.
 * Further verification may be needed to confirm where
 `wp_get_elements_class_name()` is triggered and whether it applies across
 all supported block rendering contexts.

 Areas that may need additional investigation:

 * frontend rendering flow
 * supported block types
 * block supports integration
 * editor vs frontend rendering behavior
 * filter execution path

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65120#comment:7>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform