Refactor usage of "handle_multiples" for Encode-plugin

Thank you for opening the issue. Although I should remark that the problem arises even by trying to encode simple strings, with or without token substitution, when the Conversion mode is "Base 64 Encode" (basically in that case we have a bug).

Note that if we integrate with the latest Tamper with MR!20, which creates 2 separate actions, Encode and Decode (instead of a single Encode/Decode), we should also limit the Conversion mode options accordingly.

The design around handle_multiples in the tamper module doesn't seem to be a type safe implementation, but we don't seem to be able to get that changed. So, instead of relying on that property, I've changed the approach to call the multiple() method of the tamper plugin to determine, whether we need to provide a string or an array.

This affects the following plugins which declare the handles_multiple property:

• ArrayFilter: requires an array
• Encode: requires a string
• Implode: requires a string
• KeywordFilter: requires a string
• Required: requires a string
• Unique: requires an array

I think, this is reasonable, except for the Implode plugin. From my point of view, that should get the multiple method to return TRUE.

I'm now taking an approach where we keep the data as is for the Encode plugin if the selected mode is either unserialize or one of the decode methods.

jurgenhaas → closed merge request !9

I'm still getting the TypeError: base64_encode(): Argument #1 ($string) must be of type string, array given in base64_encode() (line 31 of /var/www/html/web/modules/contrib/tamper_new/src/Plugin/Tamper/Encode.php) #0 [internal function]: base64_encode() when trying to encode a simple string, both with & without MR!20 from the Tamper issue ✨ Create separate Decode-plugin RTBC applied to 8.x-1.0-alpha5.

Decoding works fine instead.

Please don't comment on fixed or closed issues. I've opened a follow-up for this at 🐛 Base64 encoding also requires a string instead of array Active

Automatically closed - issue fixed for 2 weeks with no activity.