Add `wp_elements_block_supports_class_name` filter to `wp_get_elements_class_name()`

[baikare.sandeep007]

Description

This patch introduces a new filter, wp_elements_block_supports_class_name, to the wp_get_elements_class_name() function. This allows developers to customize the generated CSS class name for block elements.

Current Behavior

Currently, the function generates a class name by serializing the entire block array and creating an MD5 hash:

$class_name = 'wp-elements-' . md5( serialize( $block ) );

There is no mechanism for developers to modify or override the generated class name without hijacking the entire function.

Proposed Change

The patch adds a filter to enable customization:

return apply_filters( 'wp_elements_block_supports_class_name', $class_name, $block );

Use Cases

This filter is valuable for:

1. Performance optimization – Replace serialize() + md5() with more efficient class name generation for complex blocks.
2. Cache-friendly class names – Generate human-readable names for easier debugging.
3. Custom hashing logic – Implement alternative algorithms or naming conventions.
4. Integration with build tools – Align class names with external CSS processes.

Example

A developer could use the filter to create more readable class names:

add_filter( 'wp_elements_block_supports_class_name', function( $class_name, $block ) {
    if ( isset( $block['attrs']['id'] ) ) {
        return 'wp-elements-' . $block['blockName'] . '-' . $block['attrs']['id'];
    }
    return $class_name;
}, 10, 2 );

Impact

• Backward compatibility: Yes – existing behavior remains unchanged when the filter is not used.
• Performance overhead: Negligible – only executes when hooked.
• Functional change: None – additive only.

Testing

Patch verified:

• Existing functionality unchanged without filter.
• Filter properly receives both $class_name and $block parameters.
• Filter return value properly replaces the default class name.

Additional Notes

• @since tag used: 7.1.0
• Props: @baikare.sandeep007

[westonruter]

I'm not sure this is a good idea. I don't see a clear need for it. Note where the return value of the funtion is used:

​https://github.com/WordPress/wordpress-develop/blob/acebfd0ac218c455d25ae9e06879bc42da18b9c9/src/wp-includes/block-supports/elements.php#L160-L220

By allowing the class name to be filtered, I worry this would introduce breakages.

[baikare.sandeep007]

I thought the class names starting with wp-elements-* would be defined in a CSS file, but it turns out they’re generated dynamically within the same elements.php file. Because of that, I don’t think it will break the UI. However, it would definitely give developers more flexibility to use user-friendly class names.

[sanayasir]

Tested the patch locally on a WordPress trunk installation using the updated implementation:

`php id="l4p8rt"
$class_name = 'wp-elements-' . md5( serialize( $block ) );

/

• Allow customizing the generated class name for block elements. *
• @since 7.1.0 *
• @param string $class_name The generated class name.
• @param array $block The block object. */

return apply_filters( 'wp_elements_block_supports_class_name', $class_name, $block );
`

Expected result:
The generated wp-elements-* class should be customizable through the newly introduced wp_elements_block_supports_class_name filter and reflect the updated class name in the rendered markup.

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 on a local WordPress trunk environment.
• No updated/customized 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 rendered output.
• Further verification may be needed to confirm where wp_get_elements_class_name() is triggered and whether it applies consistently across supported block rendering contexts.

Areas that may require additional investigation:

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

[audrasjb]

Removing trunk version as this is not going to be shipped with WP 7.0 but in the next releases.

[desrosj]

Since this is an enhancement, there's no first version of WordPress this can be reproduced in. Removing trunk version.