Extend token_get_date_token_info/values to grab all system defined date formats (long, medium, short, etc) [#998156]

So, Drupal gives you the ability to define your own custom date formats and to give them designated names (admin/settings/date-time/formats). It would be really great if anytime a new format was added (let's say I want long, medium, short, and a new one called longer) that each of these would have token equivalents through token_get_date_token_info/values so that any module using these function to create their date tokens would have access to token of any of the system defined date formats (like scheduler).

Comment	File	Size	Author
#6	token_date.patch	3.11 KB	sirkitree
#4	token_date.patch	2.49 KB	sirkitree

Comments

Comment #1

sirkitree commented 14 December 2010 at 18:02

Hrm, upon closer inspection it seems this menu item is actually part of date_api.module, not core...

Comment #2

sirkitree commented 14 December 2010 at 18:05

... Which only operates on 'field' types, not 'node' which is what I was hoping for...

Wondering if it would be acceptable to just module_exists('date_api') and still include this within token_get_date_token_info/values

Comment #3

sirkitree commented 14 December 2010 at 19:11

[edit] double post

Comment #4

sirkitree commented 14 December 2010 at 19:18

Status:

Active

» Needs review

Status	File	Size
new	token_date.patch	2.49 KB

Here's a patch - this successfully pulls in any custom date formats you create through date_api which any module utilizing token_get_date_token_info/values can then have tokens for...

Custom date formats:

Corresponding tokens:

Example of Scheduler which utilizes token_get_date_token_info/values for it's publishing tokens:

And a final end result where the new custom 'longer' token is being rendered:

Comment #5

dave reid

he/him

English

Nebraska USA

commented 14 December 2010 at 19:52

Status:

Needs review

» Needs work

I'm worried about this slowing down token. We're already generating every single token possible. Plus this definitely has to re-roll against the lastest 6.x-1.x code because there have been a lot of recent changes to date token generation (i.e. we have our own token_format_date() that should be used). Also, doesn't the 'short' token conflict with the 'small' token? Also the descriptions need to re-use the $description parameter in token_get_date_token_info().

Comment #6

sirkitree commented 16 December 2010 at 06:17

Status:

Needs work

» Needs review

Status	File	Size
new	token_date.patch	3.11 KB

I know what you mean about slowing token down - and ideally this would go into date module, except there is no way presently to extend these functions. Date could provide these in it's hook_token_info, but any module using token_get_date_token_info/value directly will then not benefit from custom formats.

One possibility would be to create a small submodule to encapsulate this functionality, token_date or something, but would still require a hook within token_get_date_token_info/value to allow extension. This would have the effect that a use would need to enable the submodule and therefor (hopefully) be aware that they are adding processing of a significant nature - but that seems a bit overkill for the amount of overhead that module_exists() might create.

In anycase, here is an updated patch against 6.x-1.x

Results:

Also - now removes the date format small if date_api enabled.

Comment #7

dave reid

he/him

English

Nebraska USA

commented 16 December 2010 at 15:16

Status:

Needs review

» Needs work

+++ token.moduleundefined
@@ -490,7 +501,43 @@ function token_get_date_token_values($timestamp = NULL, $token_prefix = '', $lan
+        $format = variable_get('date_format_' . $type, array_shift(array_keys($formats)));
+        $ts = date_convert($timestamp, DATE_UNIX, DATE_DATETIME);
+        $tokens[$token_prefix . $type] = date_format_date($ts, 'custom', $format);

This should just be adding the formats into the array, not actually doing replacement as this will only be executed once per request.

Powered by Dreditor.