Blocks: Always serialize block attributes as a JSON object, matching serializeAttributes() - #14758

`serialize_block_attributes()` encoded the attributes array as is, so an
array that PHP sees as a list came out as a JSON array, which the block
delimiter grammar does not accept:

- An empty array was serialized as `[]`.
- Attributes decoded from `{"0":"a"}`, whose numeric name becomes an
  integer key, were serialized as `["a"]`, so a block with them did not
  survive a parse and serialize round trip, and was no longer a block after
  kses normalized its delimiter.

Cast a list to an object before encoding, so it is serialized as `{}` or
`{"0":"a"}`. Other arrays are left alone, since `json_encode()` skips
object properties whose names start with a null byte, which an attribute
name decoded from JSON may do.

If the attributes cannot be encoded, an empty object is now returned rather
than an empty string, which `strtr()` made of `false`.

Also add a `string` return type, narrow the documented type of the
attributes to `array<string, mixed>`, matching the attributes object of the
JavaScript `serializeAttributes()`, and type the return value as a
`non-empty-string`.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

`wp_json_encode()` is documented to return false when a value cannot be
encoded, but when `$flags` includes `JSON_THROW_ON_ERROR`, the first
`json_encode()` call throws a `JsonException` instead. The exception is not
caught, so it is thrown before the confidence checks can recover from an
error they would otherwise handle, such as invalid UTF-8.

Document the exception with a `@throws` tag, and qualify the return value,
with tests for a value that cannot be encoded, one that exceeds the depth,
and invalid UTF-8.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

…ERROR.

When `$flags` includes `JSON_THROW_ON_ERROR`, `wp_json_encode()` throws a
`JsonException` instead of returning false. Make the return type
conditional on `$flags`: when it is a combination of the other encoding
flags, the function returns `non-empty-string|false`, and otherwise only
`non-empty-string`. A non-constant `$flags` matches neither for certain,
so it keeps the full `non-empty-string|false`.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

A `@throws` tag makes PHPStan treat the listed exceptions as all that a
function can throw. But `json_encode()` also lets through any exception
thrown by a `JsonSerializable::jsonSerialize()` in `$value`, whatever the
flags, so `@throws JsonException` would make a catch of any other
exception around `wp_json_encode()` look dead.

Move the note about `JSON_THROW_ON_ERROR` into the description of
`$flags` instead, so the function goes back to being treated as possibly
throwing anything.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

`array_is_list()` requires an array, so passing an object to
`serialize_block_attributes()`, which it encoded fine before, now threw a
`TypeError`. Only check for a list when the attributes are an array.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

…flag.

The conditional return type of `wp_json_encode()` excluded false whenever
`$flags` was not a combination of the known encoding flags without
`JSON_THROW_ON_ERROR`. That also covered flags with an unknown bit set,
such as one added in a later version of PHP, which can still fail and
return false.

Exclude false only when `$flags` is a combination of the known encoding
flags that includes `JSON_THROW_ON_ERROR`, and keep it for any other
value.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

`serialize_block_attributes()` now serializes a list or an empty array as
a JSON object rather than an array, and returns an empty object rather
than an empty string when the attributes cannot be encoded. Add a `@since`
entry so the change is visible in the developer documentation.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

…sts.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

Excluding false from the return type when `$flags` includes
`JSON_THROW_ON_ERROR` needs the full list of encoding flags twice: once to
match flags without it, and once to match flags with it. A docblock on a
function cannot define a type alias, and one defined in the PHPStan
configuration would be unknown to stubs, IDEs, and anyone else analyzing
code against core.

No caller in core passes `JSON_THROW_ON_ERROR`, so the narrowing gave core
nothing, while the list of flags would have to be kept in sync with PHP.
Go back to `non-empty-string|false`.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

When `$flags` includes both `JSON_THROW_ON_ERROR` and
`JSON_PARTIAL_OUTPUT_ON_ERROR`, `json_encode()` returns the partial output
rather than throwing, for example `'0'` for `INF`. Say so in the
description of `$flags`, and add the case to the test of values that can
encode to `'0'`.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

`serialize_block_attributes()` encoded attributes passed as an object, but
the check for a list made it throw a `TypeError` for one until the check
was limited to arrays. Add a regression test. The object goes against the
documented array type on purpose, so the PHPStan error for it is ignored
with the reason given.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

…PHPStan.

Attribute names are strings, but when `parse_blocks()` decodes a
delimiter's JSON, PHP turns numeric-string names into integer keys, so
`{"0":"a"}` is passed in as `array( 0 => 'a' )`. Serializing exactly those
is why a list is cast to an object.

With the attributes typed as `array<string, mixed>`, PHPStan considers a
list impossible, and takes that as certain once the encoding result is
checked, which would report the cast in a retry as dead code. Keep the
documented `array<string, mixed>`, which describes the attributes object,
and give PHPStan the actual `array<array-key, mixed>`, here and in the
test that passes integer keys.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

JSON cannot represent `INF` or `NAN`, so a block with one in its
attributes failed to encode, and `serialize_block_attributes()` returned
`{}`, losing all of the block's attributes, not just that one. The
`JSON.stringify()` in the block editor's `serializeAttributes()` encodes
them as `null` instead, keeping the rest.

Do the same: when encoding fails, replace any `INF` or `NAN` in the
attributes, including in nested arrays, with null, and encode them again.
Objects in the attributes are left alone, since they belong to the caller.
Attributes that still cannot be encoded are serialized as `{}`, as
before.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

…@SInCE.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

The retry that replaces `INF` and `NAN` with null ran after any failure
to encode the attributes. For attributes that refer to themselves,
`array_walk_recursive()` then threw an `Error` for the recursion, where
the function used to fail quietly, and other failures, such as exceeding
the depth limit, paid for a walk and a second encoding that could not
succeed.

Only retry when `json_last_error()` reports `JSON_ERROR_INF_OR_NAN`, and
add a test for self-referencing attributes.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

`array_walk_recursive()` replaced `INF` and `NAN` in place, and though the
attributes array is a copy, an element that is a reference still points
at the caller's variable, so serializing the attributes set that variable
to null.

Build new arrays with the values replaced instead, walking no deeper than
`json_encode()` does as a safeguard, and add a test that a referenced
variable is left unchanged.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

The recursive closure captures itself by reference, so it is left in a
reference cycle that only the cycle collector frees. Clear the variable
once the replacement is done, which breaks the cycle and frees the closure
right away.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

…ject.

Add `@ticket` tags to the tests of `serialize_block_attributes()`, and to
the round trip tests whose data now includes a numeric attribute name.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

Invalid UTF-8 in an attribute name or value made `json_encode()` fail, and
`wp_json_encode()` then retried with the strings repaired by
`_wp_json_convert_string()`, which turns each invalid byte into a question
mark. That is indistinguishable from a real one. Pass
`JSON_INVALID_UTF8_SUBSTITUTE` instead, so the invalid bytes are replaced
with the replacement character U+FFFD, which marks them as such, without
the failed first pass.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>