Add {domain.now}, supporting |crmDate

[eileenmcnaughton]

Overview

Add new {domain.now} token - this provides the current date.

It also supports formatting and provides a mechanism for other dates to follow - ie the following work based on the formats configured in the date settings page.

Token	example output
{domain.now}	September 18th, 2021 11:58 PM
{domain.now|crmDate:"Datetime"}	September 18th, 2021 11:58 PM
{domain.now|crmDate:"shortdate"}	09/18/2021
{domain.now|crmDate:"Full"}	September 19th, 2010
{domain.now|crmDate:"Partial"}	September 19th, 2010
{domain.now|crmDate:"Time"}	1:34 PM
{domain.now|crmDate:"Year"}	2010
{domain.now|crmDate:"FinancialBatch"}	09/19/2010
{domain.now|crmDate:"%B %Y"}	September 202

Before

^^ not available

After

and now it is

Technical Details

This expands the range of what is considered a valid token-filter. The filters may now accept string-parameters, as in |crmDate:"first":"second":"third".

crmDate works if the token-value is defined as a \DateTime object (which I will do on the main entities as a follow up)

https://lab.civicrm.org/documentation/docs/user-en/-/merge_requests/498

[civibot]

(Standard links)

• If this is your first pull-request for CiviCRM, please browse CONTRIBUTING.md for information about the development and testing processes.
• If you are reviewing this pull-request, you may wish to consult the test sites and the Review Standards (long template, short template).

[totten]

There was a problem where CRM_Core_DomainTokens populated {domain.now} but not {domain.now|crmDate:foo}. The problem was that the it didn't perceive domain.now as an active token... the active token list is built via TokenProcessor::addMessage() => CRM_Utils_Tokens::getTokens(). That function relies on an older regex.

I've added a bit here so that the same regex is always used by TokenProcessor::addMessage() and TokenProcessor::render().

Also, rebased/force-pushed

[eileenmcnaughton]

@totten are you happy with this now, pending a PR template re-write & some thoughts about docs?

[totten]

@eileenmcnaughton I've added several more tests, changed the notation to match Smarty (ie string-parameters are in quotes), and fixed the handling of %a/%b %c formatting expressions. Also updated description accordingly.

There are some limitations with string-parameters - e.g. it will not accept a quote-mark or curly-brace inside of a quoted string. But I don't think this is problematic with our target use-cases.

Date expressions that involve month/day names are sort of localized - ie if you have |crmDate:"%B", the token-stuff does what it should to output "April"(en), "Avril"(fr), or "Abril" (es). However, it doesn't work because CRM_Utils_Date has a caching bug. Sending up a separate PR to address that.

If you're happy with the updates, then I am too.

[eileenmcnaughton]

Thanks @totten this looks good to me - it's actually quite exciting to think that we will have a non-hacky way to consolidate the various date handling (e.g I can update event badge tokens to use the token processor now it can support their preferred processing).

@seamuslee001 @colemanw @demeritcowboy can one of you MOP this

[eileenmcnaughton]

Docs PR https://lab.civicrm.org/documentation/docs/user-en/-/merge_requests/498

[eileenmcnaughton]

I also added a note to the update docs https://lab.civicrm.org/-/ide/project/documentation/docs/sysadmin/tree/case/-/docs/upgrade/version-specific.md/

[colemanw]

Code, docs & tests all look good.