Elements: Guard against non-string className in render filter

[aaronrobertshaw]

What?

Adds a type check so the elements block support's render_block filter bails out gracefully when a block's className attribute isn't a string, rather than passing it straight to preg_match().

Why?

We had a report of a fatal error coming from gutenberg_render_elements_class_name():

PHP Fatal error: Uncaught TypeError: preg_match(): Argument #2 ($subject) must be of type string, array given in .../lib/block-supports/elements.php:242

The className attribute is registered everywhere as type: 'string', and the editor only ever writes a string or undefined, so this comes from invalid stored block data (the trace shows a block serialised with class="0 1 …"). It surfaced via an Elasticsearch re-index walking over old posts rather than normal rendering.

It's not something this code produces, but there's no reason to fatal on it. The sibling supports (block-style-variations.php and custom-css.php) already guard against this, so this just brings elements.php in line.

How?

Adds an early is_string() return before the preg_match() call, matching the existing pattern in gutenberg_get_block_style_variation_name_from_class().

Testing Instructions

This is hard to hit through the editor since className is always a string there, so it's covered with a unit test:

npm run test:unit:php -- --filter test_elements_block_support_class_with_non_string_class_name

The test passes a block with an array className and asserts the content is returned unchanged. You can also confirm the whole WP_Block_Supports_Elements_Test class still passes.

[andrewserong]

LGTM! Not sure how anyone would wind up with an array in this case, but now that lots of folks are generating block markup via LLMs, it makes sense to harden this IMO.

Also, an early return for invalid values rather than attempting to treat it as "real" seems the right approach to me 👍

[github-actions]

The following accounts have interacted with this PR and/or linked issues. I will continue to update these lists as activity occurs. You can also manually ask me to refresh this list by adding the props-bot label.

If you're merging code through a pull request on GitHub, copy and paste the following into the bottom of the merge commit message.

Co-authored-by: aaronrobertshaw <aaronrobertshaw@git.wordpress.org>
Co-authored-by: andrewserong <andrewserong@git.wordpress.org>

To understand the WordPress project's expectations around crediting contributors, please review the Contributor Attribution page in the Core Handbook.

[westonruter]

@aaronrobertshaw Follow-up: #79023