Date fields which have end dates are exposed to the entity token system as structs with three properties: value, value2, and duration. When a date field is configured to have multiple values, then the token type is set to list<struct>.

These are currently not supported, which can lead to either the token being rendered as "Property 0" or to fatal PHP errors which interrupt the page rendering process. See #1618200: Fix date tokens for multiple values (fatal php error) for details on the date example and steps to reproduce.

Underlying problems are (as far as I was able to identify):

  • There is no "default value" for structs, so if a token is specified without the suffix ":value" or ":value2", then the token replacement value falls back to the string representation of the respective wrapper. For structs within a list that representation is "Property 0".
  • Currently all properties which have a "property info" key (i.e. have sub-properties?) are treated as structs in _entity_token_map_top_token_type(); this includes lists of properties (list<struct>). This can lead to cases where entity_token_tokens() is called with type=struct and data wrapped into EntityListWrapper, which eventually can lead to a fatal error...

I'll upload a patch which tries to solve these problems in a few minutes...

CommentFileSizeAuthor
#1 struct-lists-1621084-1.patch3.91 KBbforchhammer

Comments

bforchhammer’s picture

bforchhammer commented
Status: Active » Needs review
StatusFileSize
new struct-lists-1621084-1.patch3.91 KB

Attached patch does the following:

  • It allows tokens of type list<struct>. In order for structs to be built properly, the list wrappers need to be constructed with the respective field property info array (--> passed via the token info array).
  • It adds support for a "default callback" in the property info array, which can be called to produce the "standard" output for structs when struct token suffixes are not specified. For example, the date module could specify a callback which just renders the full date as @start-date to @end-date.

The patch will probably need more work and testing (I may have broken things); setting to "needs review" to get feedback on the general approach... I'm no expert on the entity api; is this going into the right direction?

matmasr’s picture

matmasr commented

So will this patch fix the issue related to Date fields with multiple dates ? I can test this patch on a development site to see if it works.

bforchhammer’s picture

bforchhammer commented

So will this patch fix the issue related to Date fields with multiple dates ?

Yes; with the patch tokens of the following format should work: [node:field_date:0:value], [node:field_date:0:value2], [node:field_date:1:duration], ...

matmasr’s picture

matmasr commented

But the issue I am having is not the extraction of the Date "Repeat" tokens. I am interested in getting the following token to work

<p>[node:field-time:value:custom:Y]</p>
<p>[node:field-time:value:custom:D]</p>
<p>[node:field-time:value:custom:j]</p>
<p>[node:field-time:value:custom:M]</p>

Do you think this patch will fix that ?

Thanks!

bforchhammer’s picture

bforchhammer commented

If I remember correctly, I think I did successfully test [node:field_date:0:value:short] (where "short" is a date format), so theoretically [node:field_date:0:value:custom:Y] should work as well...

lhubbert’s picture

lhubbert commented

I can confirm that the patch worked for me.

(I literally just did a happy dance around my desk after testing it - thank you!)

bcobin’s picture

bcobin commented

I tried the patch in relation to this issue: http://drupal.org/node/1872468

No joy.

There seems to be active work going on here on what looks to be a thorny issue - any guidance much appreciated... thanks!

mstef’s picture

mstef commented

What about this token: [entity:field:format]? That results in a fatal error with and without this patch.

Here's an example:

The main body text
[comment:comment-body:?]
The main body text The following properties may be appended to the token: value (Text), format (Text)

I tried using it as [comment:comment-body:plain_text] (and a few other ways..). No luck.. My fault?

Error with patch:

Notice: Undefined property: EntityValueWrapper::$plain_text in entity_token_tokens() (line 187 of /var/www/sites/all/modules/contrib/entity/entity_token.tokens.inc).
Recoverable fatal error: Argument 1 passed to _entity_token_get_token() must be an instance of EntityMetadataWrapper, null given, called in /var/www/sites/all/modules/contrib/entity/entity_token.tokens.inc on line 187 and defined in _entity_token_get_token() (line 305 of /var/www/eweb/htdocs/sites/all/modules/contrib/entity/entity_token.tokens.inc).

Error without patch: (same as #1440928: Entity tokens for multi-value fields produce a fatal error)

Fatal error: Call to a member function value() on a non-object in /var/www/sites/all/modules/contrib/entity/entity_token.tokens.inc on line 297
xano’s picture

xano
he/they
Primary language English
Location Southampton
commented

#1: struct-lists-1621084-1.patch queued for re-testing.

xano’s picture

xano
he/they
Primary language English
Location Southampton
commented

#1944304: Expose payment status items to Entity/Rules depends on this issue.

xano’s picture

xano
he/they
Primary language English
Location Southampton
commented

I am getting field-related exceptions when testing Entity, both with and without the patch. The testbot branch tests are all green, though.

// Edit: I just refreshed my testing installation to 7.x-dev with the testing profile. The tests still cause exceptions.

xano’s picture

xano
he/they
Primary language English
Location Southampton
commented

It adds support for a "default callback" in the property info array, which can be called to produce the "standard" output for structs when struct token suffixes are not specified. For example, the date module could specify a callback which just renders the full date as @start-date to @end-date.

If we want this (I'm not sure this is a good thing), we should use a different key to indicate the callback. This is horribly NOT self-descriptive. What about "replacement callback"? We can then use that callback for everything and not just structs, which means that the callback is a feature rather than a workaround.

// Edit I just realized my issue is primarily with Rules data tokens.

jromine’s picture

jromine commented

This fixed my issue with date fields using tokens like:

[node:field-date:0:value:custom:M]
[node:field-date:0:value:year]

@mstef: there's a patch in #34 of #1440928: Entity tokens for multi-value fields produce a fatal error which might fix the undefined property issue.

chiebert’s picture

chiebert commented

The patch in #1 didn't work for me, at least when as far as a pathauto (7.x-1.2) pattern rule goes. Date 7.x-2.6, Entity 7.x-1.1 (patched) or 7.x-1.x-dev (patched). I've got a content type with a repeating date (which means its cardinality is unlimited), and an end date. Results:

  • [node:field-event-date] evaluates to 'property-0'
  • pathauto rejects all of the following as invalid tokens (where 'short_2' is a date format that has proven to work in other contexts, like node automatic entity labels):
    • [node:field-event-date:0:value:short_2]
    • [node:field-event-date:0:value]
    • [node:field-event-date:0]
    • [node:field-event-date:value:short_2]
    • [node:field-event-date:value]
miguel’s picture

miguel commented

The same problem here with File (Field) Path module:
If I try to use [node:field-datum:0] I get the error that this token is not valid (Dateipfad verwendet folgende ungültige Tokens: [node:field-datum:0]).

13rac1’s picture

13rac1 commented
Status: Needs review » Needs work

Related giant issue: #1103032: Document how to use date tokens

The Pattern for all Calendar Event paths is using the following invalid tokens: [node:field-calendar-date:0:value:short].

With this applied, I am still unable to get start/end dates. Looking into why...

bforchhammer’s picture

bforchhammer commented

Something I've noticed just now: You're using field tokens with dashes; there's also the ones with underscores... Not sure whether it really makes a difference, but they are provided by different modules (token vs. entity_token module) so it may well be. From my comments above, I think I only tested my patch above with the underscore version.

13rac1’s picture

13rac1 commented

Underscore has the same issue:

The Pattern for all Calendar event paths is using the following invalid tokens: [node:field_calendar_date:0:value:short].
bforchhammer’s picture

bforchhammer commented

Hm, I tested the patch above with automatic entity label module which does not validate tokens at the moment (see #2123733: Validate tokens). So the token validation function still thinks that the token is invalid (token_get_invalid_tokens() is the relevant function). From looking at that function maybe we also need to mark any list<struct> tokens as "dynamic" tokens?

lokapujya’s picture

lokapujya
Primary language English
Location Boston
commented

I opened #2185745: Support text_formatted token replacement. The patch in this issue seems to partially fix my tokens. Has anyone made any improvements to this patch yet? I might work on it, but don't completely understand the fix yet.

wickwood’s picture

wickwood commented

So my particular problem was that I had a date field with starting and ending dates with the possibility of repeating.

Upon trying to setup pattern for the URL aliases path, I discovered that the tokens did not work.

However, I was able to apply the patch from #1 to dev version of the Entity module committed on May 25, 2012. (This is actually version 1.0-rc3, SHA ID:c1a949c89aac9bedf11fa8004ac983c2fd7a6ffd)

I then merged that with most current dev version as of today (committed on 4/8/2014 SHA ID: 4d2cc6fb1ecba4409cb8d1b813133366dea2c460). I've tried to make new patch, but I don't have much experience with that and haven't been able to make one that will apply successfully.

Anyway, this did allow me to use tokens to create patterns for the URL aliases path for date fields that end dates, but not repeating dates, with the following token structure for example: 

[node:field-event-date:value:custom:Y] - for starting dates
[node:field-event-date:value2:custom:Y] - for ending dates

Since I don't really need repeating dates at the moment, this has solved my problem enough to move forward. Hope some else finds this helpful. If I can figure out what is going wrong with my patch creation I will post that later.

rwilson0429’s picture

rwilson0429 commented

Using the dev versions of Path Auto, Entity API and Entity Tokens modules, I was able to setup a URL Alias path using tokens for content having a custom repeating date field (field_event_date) configured to have a start and an end date and with unlimited cardinality.

event/[node:field-event-date:0:value:custom:Y]/[node:field-event-date:0:value:custom:m]/[node:title]

This created a url path of event/yyyy/mm/title (e.g "event/2015/11/My Content Title") based on the date value in the field_event_date field of the node.

Without adding the cardinality value, "0" in my case, to the format, the tokens didn't work.

dadderley’s picture

dadderley commented

@rwilson0429
Thank you very much.