Using: 8.x-3.x-dev, 9.5, and php 8.1.
Deprecated function: preg_match_all(): Passing null to parameter #2 ($subject) of type string is deprecated in Drupal\typed_data\PlaceholderResolver->scan() (line 185 of modules/contrib/typed_data/src/PlaceholderResolver.php).
Drupal\typed_data\PlaceholderResolver->scan(NULL) (Line: 53)
Drupal\typed_data\PlaceholderResolver->resolvePlaceholders(NULL, Array, NULL, Array) (Line: 167)
Drupal\typed_data\PlaceholderResolver->replacePlaceHolders(NULL, Array) (Line: 72)
Drupal\rules\Plugin\RulesDataProcessor\TokenProcessor->process(NULL, Object) (Line: 320)
Drupal\rules\Plugin\RulesExpression\ActionExpression->processValue(NULL, Array, Object) (Line: 297)
Drupal\rules\Plugin\RulesExpression\ActionExpression->processData(Object, Object) (Line: 83)And
Deprecated function: str_replace(): Passing null to parameter #3 ($subject) of type array|string is deprecated in Drupal\typed_data\PlaceholderResolver->replacePlaceHolders() (line 172 of modules/contrib/typed_data/src/PlaceholderResolver.php).
Drupal\typed_data\PlaceholderResolver->replacePlaceHolders(NULL, Array) (Line: 72)
Drupal\rules\Plugin\RulesDataProcessor\TokenProcessor->process(NULL, Object) (Line: 320)
Drupal\rules\Plugin\RulesExpression\ActionExpression->processValue(NULL, Array, Object) (Line: 297)
Drupal\rules\Plugin\RulesExpression\ActionExpression->processData(Object, Object) (Line: 83)I had same deprecation messages for a rule that sent an email after a comment was submitted. The patch works for me clear the errors.
- π§πͺBelgium f2boot
Patch #5 breaks Data Comparison if value = 0 so let's check if value is a string before going for return
- π§πͺBelgium f2boot
Sorry, got a bit too enthousiast.
Here is a new try, limiting "return" in patch #5 to empty string - πΊπΈUnited States scotthreha
Drupal 9.5.8
PHP 8.1.19
Rules 8.x-3.x-devI updated to the 8.x-3.x-dev version as suggested, which fixed the deprecated function errors but now none of my rules work as before. I tried deleting and recreating them, still not working. Anyone else have this experience? Any suggestions for how to get Rules working again?
- π©πͺGermany florianboehme
same here... after updating to Rules 8.x-3.x-dev all deprecated errors are gone, but no rule seems to work anymore. No error appear when the rule should fire.
I have as trigger on creating/updating user entity β but I don't think it matters. - π¬π§United Kingdom freelylw
I have an issue my rules action can't send email out by using the token [node:author:mail], but it works if I use a fixed email address like abc@gmail.com. I got the similar log message like above. please see this post π Can't send email out by using token [node:author:mail] Active
- Status changed to Needs review
10 months ago 3:18pm 2 February 2024 - last update
10 months ago 414 pass - last update
10 months ago 414 pass - πΊπΈUnited States dcam
Those who are having trouble with rules not firing should make certain they aren't affected by π Rules registers no listeners on rare occasions. Needs review - basically just clear the cache.
Setting the issue status to start the tests on #12.
- π―π²Jamaica axle_foley00
I had this same issue and the patch in #12 worked for me.
- πΊπΈUnited States tr Cascadia
The root problem is that there are cases when a data processor plugin is being called on to process a NULL value.
Yes, patches like #12 can narrowly avoid the problem by checking on the value inside the data processor, but as data processors are plugins that means that each and every data processor needs to know it has to do this, then needs to do it. That is not a scalable solution, and it is error prone.
I better solution IMO is outlined in my comment at #3095216-4: [meta] Data Processors β .
Specifically, DataProcessor plugins should have mandatory method defined in the plugin interface to declare the data type(s) they can process. That way, we can see if the DataProcessor applies to our data before we try to process our data. That's far better than just checking for NULL, because as described in the related issue #2849810: Data processors do not check type before performing type-specific operations β the problem isn't always a NULL value - however it IS always a value of the wrong data type.