Warnings when using token replacements in multiple string context parameters

I can confirm that this is happening for me also, but the patch provided (#2) does not work.

I ended up re-writing the scan function to check the $text variable to see if it's an array, and if it is then it loops through it recursively to get the results. With the patch above an array still ended up getting through, and this solves it by going right to the end point and fixing it there.

Messed up when generating the patch file. You can find the updated patch file attached.

I don't think it's the placeholder resolver's job to deal with arrays. It seems like Rules is using the API in an invalid way. Thus moving this to Rules and re-titling.

This bug affects all RulesDataProcessors, so I implemented a fix in the ContextHandlerTrait to cover more instances of this problem. If a given context definition is multiple, value processing now happens in a loop. I'm not a Rules expert, so let me know if this isn't the right place to fix this.

The last test run for 8.x-3.x was in September, I'm guessing that branch tests are failing.

Filed #2849779: Implement missing PluginDefinitionInterface methods in RulesUiDefinition.

Subscribing, I am experiencing this in a functional REST test that (for some reason) calls the token processor on when our event broadcaster runs. Which also uses an array, but in our case of queues.

Warning: preg_match_all() expects parameter 2 to be string, array given in Drupal\typed_data\PlaceholderResolver->scan()
(line 186 of /modules/typed_data/src/PlaceholderResolver.php)

This same php warning is produced when a rule has a condition 'user having role'. It is due to the same cause - the role names are sent as an array not a string. The patch in #9 fixes this error, and I confirm that it also fixes the original reported problem when sending an e-mail.

With regard to automated testing, the rules patch on #2849779: Implement missing PluginDefinitionInterface methods in RulesUiDefinition fixes the tests and that issue should really be committed immediately as it is preventing further patches from passing. I have run the full Rules tests locally with both of these changes and they all pass. Just for fun here is a patch with simply combines the fix for abstract classes and fix in #9 above, to show it passing on D.O. (hopefully). The fixes should be committed in the separate issues, of course.

OK, so I can't override the "waiting for branch to pass" so we are stuck. When the branch does eventually pass the patch in #15 will fail to apply (as it contains the fix for the tests).

thx, the patch looks good. The test fix has been committed meanwhile, can you re-roll it and/or post it as PR? Thanks!

+++ b/src/Ui/RulesUiDefinition.php
@@ -111,6 +111,20 @@ class RulesUiDefinition implements PluginDefinitionInterface {
+    return $this->id;

This was for fixing the tests - the changes in RulesUiDefinition should not be part of this patch.

This was for fixing the tests - the changes in RulesUiDefinition should not be part of this patch.

Yes, I knew that. I was just trying to see if we could get the tests to pass before that commit was done. But as I realised in #16 I did not have the authority to bypass the 'waiting for branch to pass'. So, ignore the patch in #15. I will try to re-queue the patch in #9

I put the patch in a GitHub PR here:
https://github.com/fago/rules/pull/484

Tests on the PR on Github are now passing, so I think it should be good to go.
https://github.com/fago/rules/pull/484
https://travis-ci.org/fago/rules/builds/226603466

I've just checked the PR - works fine for me.

Good work jonathan.green and thank you max-kuzomko for testing it.

What we really need is for the rules tests to pass on d.o. as well as in github. The single failure is #2871526: AutocompleteTest fails at D8.4 but OK at D8.3. Until this is resolved all patches on d.o. will remain "waiting for branch to pass" and we won't see much progress on patches.

thx, that looks good now. I merged the PR!