Adding datetime field type tokens

This patch adds a desired processing format DateTime fields. It also adds an asterisk to create full anarchy in the validation of tokens :)

Example template:

events/[node:field_event_date:*:Y]/[node:field_event_date:*:m]/[node:field_event_date:*:d]/[node:title]

or

events/[node:field_event_date:*:Y/m/d]]/[node:title]

But in last case you should change settings in Pathauto. It is necessary to set option for Slash (/) in "No action (do not replace)".

@Berdir, thank you for attention. Totally agree with you, but now I'm not clever enough for do it. Maybe later.

And yes, I also have an idea :) What about this:

1. Universal functions for all types (with cast/convert between types) :

date_format:Y/m/d // '2016-00-30 01:17:23' -> '2016/08/30'
sub_format:1,3 // 'Hello world' -> 'ell'
math_format:floor(x/100)*100 // '12345' -> '12300'
size_format:Kb // '10240' -> '10'
...

example:

[node:field_date:value:date_format:Y/m/d] 
[node:field_text:value:date_format:Y/m/d] 
[node:field_text:value:sub_format:2] 
[node:field_text:value:sub_format:2,10] 

2. Expressions:

object:(expression) // get function by entity type, data by entity value

Type      |  default

Date      |  date_format
Text      |  sub_format
Number    |  math_fomat

example:

[node:field_date:(Y/m/d)]
[node:field_text:(Y/m/d)] # mistake!
[node:field_text:value:date_format(Y/m/d)]
[node:field_text:(2)]
[node:field_text:(2,10)]
[node:field_number:((x-5)*10)] # (( )) - no problem with smart parsing

3. Nesting:

[[node:field_text:(5,2)]:date_format:(F)] 
# '2015.11.19 rocks!' -> '11' -> 'november'

[[node:field_image:(Kb)]:math_format:(floor(x/100)*100)] 
# 'image of 1234567 byte' -> '1205' -> '1200' /* good for cataloging */

These steroids are real for Token? Or rather to build own module, with nesting and expressions?)

Don't forget about cache update. Example:

[node:field_date:format:custom:d]
[node:field_date:format:custom:Y/m/d]
[node:field_date:format:html_date]
etc

Great improvement! Thank you, @hussainweb.

+        foreach (['value', 'end_value'] as $property) {
+          $date_tokens = \Drupal::token()->findWithPrefix($tokens, $property);
+          if ($date_tokens) {
+            $datetime = strtotime($field_item->$property);
+            $replacements = ...

If the foreach can produce results twice, it is better to use the addition operation like this:
$replacements += ...

I also like the idea to attach a format to the 'value' token. But the version with insulation in a new token ('format') seems more compatible solution, no?

Raw test, but it can be helpful to starting.

@Leo Pitt, for 'created' field is already possible, for custom field - not yet, but this dream is real :)

+++ b/token.tokens.inc
@@ -1337,12 +1337,15 @@ function field_token_info_alter(&$info) {
+        $info['tokens'][$field_token_name]['start_date'] = $info['tokens'][$field_token_name]['value'];

I'm bad undestand 'daterange', but seems it haven't 'date' property, but it have 'start_date' property. It works for me (8.2.0-rc1).

+++ b/token.tokens.inc
@@ -1576,12 +1579,14 @@ function field_tokens($type, $tokens, array $data = array(), array $options = ar
+          if($field_item->$property) {
+              $datetime = $field_item->$property->getTimestamp();

Realize the rest part of #12

+++ b/token.tokens.inc
@@ -1337,12 +1337,15 @@ function field_token_info_alter(&$info) {
+        $info['tokens'][$field_token_name]['date']['name'] .= ' ' . t('format');

Maybe we need to make different UI names for 'value' and 'date' tokens (eg: ' format' postfix :)

attempt to correct fail patch #21

It's me again :)

diff --git a/token.tokens.inc b/token.tokens.inc
@@ -1565,6 +1579,16 @@ function field_tokens($type, $tokens, array $data = array(), array $options = ar
+      elseif (in_array($field_item->getFieldDefinition()->getType(), ['datetime', 'daterange']) && in_array($property_name, ['date', 'start_date', 'end_date'])) {

We must handle only our tokens, right?

diff --git a/token.tokens.inc b/token.tokens.inc
@@ -1565,6 +1579,16 @@ function field_tokens($type, $tokens, array $data = array(), array $options = ar
-          if($field_item->$property) {

If check by getType and list tokens, this condition seems unnecessary

diff --git a/token.tokens.inc b/token.tokens.inc
@@ -1565,6 +1579,16 @@ function field_tokens($type, $tokens, array $data = array(), array $options = ar
-        foreach ($properties as $property) {

If use '$property_name' and '$replacements += ', this cycle seems unnecessary

diff --git a/token.tokens.inc b/token.tokens.inc
@@ -1565,6 +1579,16 @@ function field_tokens($type, $tokens, array $data = array(), array $options = ar
+        if(isset($tokens[$property_name])) {
+          $date_tokens['raw'] = $tokens[$property_name];
+        }

For case like '[node:field_date:date]', '[node:field_date:start_date]', '[node:field_date:end_date]'. See test.

What do you think?

+        if(isset($tokens[$property_name])) {
+          $date_tokens['raw'] = $tokens[$property_name];
+        }

Ok, it is bad idea. Because overriding when both variants are used simultaneously (e.g [..:date:raw] & [..:end_date]).

Possible solutions:

 elseif (in_array($field_item->getFieldDefinition()->getType(), ['datetime', 'daterange']) && in_array($property_name, ['date', 'start_date', 'end_date'])) {
        $date_tokens = \Drupal::token()->findWithPrefix($tokens, $property_name);
        if ($date_tokens) {
          $datetime = $field_item->$property_name->getTimestamp();
          $replacements += \Drupal::token()->generate('date', $date_tokens, ['date' => $datetime], $options, $bubbleable_metadata);
        }
+      if($property_name == $token) {
+        $replacements[$original] = $field_item->$property_name; # or other processing
+      }
      }

or skip this variant (and the process such as a value in last 'else'):

- elseif (in_array($field_item->getFieldDefinition()->getType(), ['datetime', 'daterange']) && in_array($property_name, ['date', 'start_date', 'end_date'])) {
+ elseif (in_array($field_item->getFieldDefinition()->getType(), ['datetime', 'daterange']) && in_array($property_name, ['date', 'start_date', 'end_date']) && $property_name != $token) {
        $date_tokens = \Drupal::token()->findWithPrefix($tokens, $property_name);
        if ($date_tokens) {
          $datetime = $field_item->$property_name->getTimestamp();
          $replacements += \Drupal::token()->generate('date', $date_tokens, ['date' => $datetime], $options, $bubbleable_metadata);
      }
      else {
        $replacements[$original] = $field_item->$property_name; // HERE
      }

xo-xo!

elseif (
    in_array($field_item->getFieldDefinition()->getType(), ['datetime', 'daterange']) &&
    in_array($property_name, ['date', 'start_date', 'end_date']) &&
    $property_name != $token &&
    $is_date_tokens = ($date_tokens = \Drupal::token()->findWithPrefix($tokens, $property_name)) &&
    $datetime = $field_item->$property_name->getTimestamp()
) {
    $replacements += \Drupal::token()->generate('date', $date_tokens, ['date' => $datetime], $options, $bubbleable_metadata);
}

Thanks! I also think that this feature is useful in many cases. And its implementation is quite isolated, so as not to damage other parts of the module. I attached one more patch. It has new tests (extends KernelTestBase) and sensible dates for daterange testing :)

Sorry for my stupid typos :(

back to RTBC by #37, because #43 only adds tests.