>>> [!note] Migrated issue <!-- Drupal.org comment --> <!-- Migrated from issue #3391110. --> Reported by: [lammensj](https://www.drupal.org/user/1939186) Related to !7 >>> ### Problem/Motivation A tamper plugin may return an object, and `Tamper::execute()` hands that straight to the token service. A value with no token type is wrapped in a `DataTransferObject`, which accepts an associative array and nothing else, so the result is an exception instead of a usable token: ``` InvalidArgumentException: Invalid values given. Values must be represented as an associative array. ``` After a discussion with Jürgen Haas on Slack, there was a proposal to add a safety net inside this module so that valid output of a tamper plugin is stored correctly. #### Steps to reproduce The mode originally reported here, `json_decode`, no longer reproduces it. That was correct when the issue was filed: tamper `8.x-1.0-alpha3` called PHP's bare `json_decode($data)` with no assoc argument and returned a `stdClass`. Current tamper routes the mode through `Drupal\Component\Serialization\Json`, which passes `TRUE`, so it returns an array. See megachriz in #3391110 (comment 2). The mode that still reproduces it is `unserialize`, an official mode of the same official Encode plugin: * Run the `eca_tamper:encode` action with `mode = unserialize` * Pass it `serialize((object) ['a' => 1])` as data * The exception above is thrown instead of a token being set `new DateTime()` reaching `addTokenData()` throws the same way, so the defect is not specific to the Encode plugin. ### Proposed resolution Convert a plain object result into a nested associative array before handing it to the token service. Two constraints, both discovered while writing the test: * **Not `is_object()`**, which was the original proposal here. It destroys entities. An entity survives `serialize()`, so it reaches the action through the same plugin and mode as the bug itself, and the token service has a token type for it and stores it as it is, which is what makes the entity's own tokens resolve. `json_encode()` on a loaded user entity returns `{}`, because an entity keeps its values behind field objects rather than in public properties, so under `is_object()` the entity converts to an empty array and is gone entirely. The conversion is narrowed to `stdClass`, the one class with no meaning beyond its properties. * **Not an `(array)` cast**, which converts only the outermost level and leaves any nested object to be rejected by the DTO's scalar guard instead. A JSON round trip recurses, and it declines the two inputs it cannot represent: an object that refers to itself, and a string that is not valid UTF-8. Both are logged, and the object is then passed on unchanged rather than replaced with NULL, so the failure stays visible instead of the data being discarded silently. Kernel test coverage in `TamperObjectResultTest`, using the official Encode plugin. No test module is needed: the multiple-value limitation that was the original reason for a custom plugin was fixed upstream in [tamper#3391096](https://www.drupal.org/project/tamper/issues/3391096). ### Remaining tasks Review !17. !7 was closed as unrebasable. It targeted `1.0.x`, patched around a property that has since been renamed, and its test plugin used the `@Tamper` annotation, which is no longer discovered now that Tamper uses PHP attributes. Credit to lammensj for the original report and test, and to megachriz for identifying the upstream fix. ### User interface changes n/a ### API changes n/a ### Data model changes n/a