Come together with the global Drupal community in Rotterdam, 28 Sept – 1 Oct 2026. Sessions, contribution, connection, and Early Bird savings until 8 June.I wrote an unserialize action for the rules_data_transform module, which returns an associative array.
It seems like the system is only set up to handle numbered arrays though, and I can't work out how to access any of the array items with tokens/data selectors, it only seems to work if I convert to an indexed array.
If I try a token such as [array:key] it doesn't get replaced, if I use [array:index] (e.g. [array:0] I get a fatal error:
Fatal error: Call to undefined method EntityValueWrapper::get() in C:\xampp\htdocs\x\sites\all\modules\entity\entity_token.tokens.inc on line 222
After applying the patch in this issue #1440928: Entity tokens for multi-value fields produce a fatal error the fatal error goes away, replaced with these notices:
Notice: Undefined index: text in entity_token_tokens() (line 220 of C:\xampp\htdocs\x\sites\all\modules\entity\entity_token.tokens.inc).
Notice: Undefined variable: property_name in entity_token_tokens() (line 222 of C:\xampp\htdocs\x\sites\all\modules\entity\entity_token.tokens.inc).
But still doesn't work. Am I barking up the wrong tree here (have a mistaken idea), or should this be possible? Apologies if this is more to do with rules than Entity API - wasn't sure which module to submit the issue to.
| Comment | File | Size | Author |
|---|---|---|---|
| #7 | entity_token-unchained-lists-2126215-7.patch | 1.1 KB | jgullstr |
| #5 | entity_token-unchained-lists-2126215-5.patch | 699 bytes | jgullstr |
| #1 | entity_token-entity-types-2126215-1.patch | 1.79 KB | jantoine |
Comments
Comment #1
jantoine commentedI have run into this same problem and it seems to stem from some confusion as to whether a list should be defined as list<$entity_type> or list<$token_type>. Rules demands the former, so I'll assume that is the correct format. It appears however, that the entity_token_tokens() function assumes the latter. Patch attached that corrects entity_token_tokens() to assume the former.
Comment #3
xamanu commentedIt is not recomendable to apply this patch, as this breaks other stuff. In my case, the pathauto generation of urls based on tokens. Using the newest version 1.5 all works fine and it seems to make this issue here obsolete.
Can you confirm this?
Comment #4
jantoine commentedI am no longer using this patch but the functionality I wrote it for continues to work, so I must have removed it from my project after updating to Entity API 1.5, but neglected to come back and comment on this issue. I think this should be marked as fixed and closed!
Comment #5
jgullstr commentedI believe the underlying problem here is that lists are expected to consist of chained token types. If an entity property type is, for example, "list<text>", entity_token_tokens() can't wrap the data properly, as $token_types['text'] is not set.
This can be prevented by including the additional token types available from entity_token_types() when evaluating tokens for "list<type>" properties.
Attached patch reloads $token_types using entity_token_types() to make missing token types available for lists.
Comment #6
jgullstr commentedComment #7
jgullstr commentedFaster, slightly less readable approach attached.
Comment #8
jgullstr commentedThis fork of the message module illustrates a use case that needs this patch.
I've added a list property to the Message entity. Without #7, I get the "Fatal error: Call to undefined method EntityValueWrapper::get()", with the patch applied everything works fine.
Comment #9
jgullstr commentedComment #11
osopolarThis works for me using a text field token like
[node:field-text:0].BTW: It does not work with
[node:field-text:0:value]on this field, which is not correct, but should not result in a fatal error.@xamanu: What exactly did not work while using patch in #1 (maybe this is still valid)? Therefore no RTBC yet.
Comment #12
jgullstr commentedPatch in #7 only extends available tokens in case $token_types[$item_token_type] is not set. As current implementation assumes that $token_types[$item_token_type] exists, the additional cases made available by this patch will produce errors already, hence nothing that is not already broken will break.
Comment #13
chris matthews commented