Standardise our 2 pledge templates to use tokens, add tests

[eileenmcnaughton]

Overview

Standardise our 2 pledge templates to use tokens, add tests

Before

These 2 templates are still calling the legacy getTokenDetails which renders hooks (as well as using the tokent processor). $contact and $domain are assigned to the template and to some degree used

After

legacy getTokenDetails not longer called, templates updated to use tokens

Technical Details

Consistent with past template changes the upgrade script should upgrade any sites where the templates are not customised and notifty them if their templates are customised.

We have recently augmented this with a status check - which doesn't reply on them responding to the upgrade script

Comments

I think this is an appropriate level of effort for the pledge templates. My suspicion based on gitlab & github activity and general chat is that they are barely used, ditto pledge code in general

[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).

[demeritcowboy]

Should I laugh or cry about the expectation that a civi component should have more bugs than it does.

On the topic of bugs though, the email I get for the receipt comes thru as the literal text Array(), but at first glance I don't think this PR touches receipts, so I'll check if that might be something else going on.

[demeritcowboy]

This is preexisting but if updating anyway can you remove the <p></p> from this text version?

[eileenmcnaughton]

fixed

[demeritcowboy]

Copy/paste probably.

[demeritcowboy]

I think my problem with the receipt email is something else. So except for the <p></p> and a couple minor notes this seems ok.

[eileenmcnaughton]

Thanks @demeritcowboy I've pushed this up - ideally as I go through templates I'd add classes to support them like in #21611 - but I didn't do that on this one since there isn't a pledge token class yet & I wasn't sure how hard it would be to get review (that one seems a bit stalled). But for the participant ones which also use this old pattern I might have a go

[demeritcowboy]

Great, thanks. Github doesn't seem to have noticed the push? Maybe a temp glitch?

[eileenmcnaughton]

@demeritcowboy fixed now - after re-checking the branch name...

[eileenmcnaughton]

The test fails were

1. a fail that related to the requested template fix
2. 9 fails that appear related but are actually happening now without this PR merged

[eileenmcnaughton]

I also put in the empty workflow message templates in that last force-push - https://github.com/civicrm/civicrm-core/compare/c8af61776e1b5dde005610f7ac1707135c223785..358171fba9d6dc164fc8153dbf98f30a95067e8b

Eventually we will add these for all templates and they will specify the entities to render tokens for. However, these 2 are really just placeholders. I'm still on the fence about going that bit further & adding a pledge token class & migrating the pledge tokens to it - but suspect I'd be better to put the effort into the more used messages

[eileenmcnaughton]

failures are now fixed in master - test this please

[demeritcowboy]

I've merged but I don't think {domain.phone} is correct. I missed it the first time since it's blank in the demo data. I'll make a lab ticket.

[demeritcowboy]

Clearing cache fixed the phone. I guess domain info is cached even after saving the org info form? Anyway it seems ok.

[eileenmcnaughton]

@demeritcowboy I doubt that value changes much in 'real' use so probably not a biggie if the cache is a bit aggressive

[demeritcowboy]

Ooh that sounds pretty smart!