Problem/Motivation
The description for BodyAdjuster form says:
This field may support tokens or Twig template syntax – please check the supplied default policy for possible values.
We should instead help people out. This issue covers the tokens - see #3404625: Email body policy form should show available TWIG variables for the variables.
Steps to reproduce
Edit a policy and add a body element
Workaround
- Look at the default installed policy - this will often use most of the available tokens
- Look at the code in the EmailBuilder. The tokens are normally set with
setParam()or this can be overridden withtokenData().
Proposed resolution
1) Add new parameter to the @EmailBuilder annotation: token_types = array of types to show in token browser.
2) Make the EmailBuilder definition available in the form
- Add MailerPolicy::getBuilderDefinition()
- Deprecate MailerPolicy::getCommonAdjusters(), as it's easy to get from the above
- In
PolicyEditForm::form(), call$this->entity->getBuilderDefinition()and store the result in the form.
3) Use these annotations in BodyEmailAdjuster::settingsForm(). Create a token browser with '#theme' => 'token_tree_link', and set #token_types based on the token_types annotation.
Example
UserEmailBuilder:
token_types = {"user"}
Remaining tasks
User interface changes
API changes
Data model changes
| Comment | File | Size | Author |
|---|---|---|---|
| #36 | Screen Shot 2024-01-22 at 17.15.44.png | 67.65 KB | mav_fly |
| #36 | Screen Shot 2024-01-22 at 16.45.21.png | 80.85 KB | mav_fly |
| #36 | Screen Shot 2024-01-22 at 16.50.04.png | 175.89 KB | mav_fly |
| #27 | variables_display.png | 29.77 KB | adamps |
Issue fork symfony_mailer-3270408
Show commands
Start within a Git clone of the project using the version control instructions.
Or, if you do not have SSH keys set up on git.drupalcode.org:
Comments
Comment #2
adamps commentedThe module business_rules has a nice example. It shows the available twig variable, and also shows the fields available on each, a bit like the token browser.
Comment #3
nchase commentedA token browser would be really helpful.
Comment #4
featuriz commentedI'm so confused with policy.
NOTE: In my gmail - I can see only the paragraph tags content rendered correctly. All the other things in spam twig content are empty.
My token for email field is: [contact_message:field_email]
Nothing works for me. help needed. Because there is no such thing in google search, I can't find any helpful links.
Comment #5
sachbearbeiter commented+1 for this feature ...
Comment #6
thalemn commented+1 for this feature
Comment #7
anche commented@featuriz did you manage to solve the problem?
Comment #8
anche commented+1 for this feature
Comment #9
adamps commentedPlease no more "+1 for this feature"😃. It needs a volunteer to write the code (or to offer sponsorship).
Comment #10
abyss commentedI will try to add the described functionality
Comment #11
adamps commentedGreat thanks - I added some more information to the Issue Summary.
Comment #12
anche commentedwhile we are waiting for volunteers, can at least someone explain where to get tokens or twig variables for email body in policy?
Comment #13
adamps commented@Anche Good question - I added a "workaround" heading to the Issue Summary.
Comment #14
anche commented@AdamPS Thanks! Do I understand correctly that before you get the necessary twig variables for your form, you need to programmatically set them? That is, if you are not good enough in programming, symfony mailer will not help you in any way to send emails in html format?
Comment #15
adamps commentedNo, the variables will already be set automatically. The purpose of this issue is to inform people using the GUI what variables are available.
Comment #16
adamps commentedComment #17
adamps commentedComment #18
coaston commentedAdamPS so how to add tokens to email body ? I am confused.
Comment #19
vlad.dancerHere is a cheap way to add token browser on mailer policy edit form:
I'm not a fan of Token UI but at least then we will have tokens list at the hand.
Comment #20
tomsaw commentedThanks @vlad.dancer, this is simple and does the job for me!
Comment #22
adamps commentedThanks it's a good start. Please see the issue summary for the next steps. I guess the MR will only show the global tokens.
Comment #23
abyss commented@AdamPS, I added the token list display in the BodyEmailAdjuster.
About adding an annotation, it seems impossible at the moment, because Adjusters don't know anything about the place where they are called, namely EmailBuilder. So, we had to abandon this idea.
If you have any other suggestions, I will be happy to add them.
Comment #24
adamps commentedThe annotation is on @EmailBuilder instead of the adjuster. Please check the issue summary. It also explains how to adjust 2 of the email builders. Some of the others will need adjusting too.
EDIT: deleted rest of answer which is wrong😃 Updated IS instead
Comment #25
abyss commentedHowever, in this case, this data will be available only at the stages of building an email, which will no longer be valuable to us.
The data about the current EmailBuilder is not contained in the settingsForm stage, and if I understood the existing code correctly, it cannot be contained there.
If I've misunderstood something, please correct me.
Alternatively, we can store these values in the form_state in the PolicyEditForm and retrieve them from the form_state in the BodyEmailAdjuster.
In this case, to display the available tokens by type, we can indeed describe token_types, but I don't see how we can use variables in this context.
Comment #26
adamps commentedHa I just realised my answer was wrong, however you beat me to it😃. I updated the IS with an explanation as you said.
Comment #27
adamps commentedFor the variables, I imagined something like on a view. Configure a field, select "Override the output of this field with custom text" and expand the box "REPLACEMENT PATTERNS". I uploaded a screenshot. It's completely separate from the token browser, just a list of variables with a description of each.
Comment #28
abyss commentedIf I understood correctly, it doesn't seem logical to do this in BodyBuilder.
In this case, the user will still have to write a handler for their own twig tokens, which is similar to creating their own token.
So do you mind if we add only token_types?
Comment #29
adamps commentedYes I would accept a patch for only tokens.
I would create a follow-on issues for the variables. I don't understand what problems you see for them, please could you explain more?
For example, in
ContactEmailBuilder::build()there is this code:The @EmailBuilder annotation would then have a line for each variable giving a description. This allows the form to tell the user the available variables.
Comment #30
abyss commentedI'm afraid I misunderstood you a bit.
In this context, it makes sense to add it.
Then do we need to add something else in this task?
Comment #31
adamps commentedGreat. You can choose: do both token and variables in this issue OR have one issue for each of them. I added some more notes to the IS.
Comment #32
abyss commentedIf so, let's split it into two tasks and I'll add this functionality tomorrow.
Comment #33
abyss commented@AdamPS, could you separate these tasks then?
Comment #34
adamps commentedOK I raised #3404625: Email body policy form should show available TWIG variables
Comment #35
abyss commentedUpdated the title and description as it was misplaced with #3404625: Email body policy form should show available TWIG variables.
Comment #36
mav_fly commentedI did the propsed patch but after applying this patch i got the follow error :
Call to undefined method Drupal\symfony_mailer\Entity\MailerPolicy::getVariables()
line 30 --> www/modules/contrib/symfony_mailer/src/Form/PolicyEditForm.php.
When set line 30 in comment $form_state->setValue('variables', $this->entity->getVariables());
The error disappears, but when you click on available tokens the popup windows appears but it's empty .
Maybe I forgot something, can anyone help me to solve my problem ?
Comment #37
adamps commentedI am working on this and also the TWIG variables, so let's combine the issues again.
Many thanks to @abyss for the valuable work on the MR in the other issues.
Comment #42
adamps commentedMR ready for 2.x please review and test
Comment #43
adamps commentedI'm going to make a release soon, so I'll commit this now. Thanks everyone for the contributions. Please do test and give any feedback if anyone gets a chance.
We're missing any kind of functional test for mailer policy, so there's not yet a framework to a new test into. Unfortunately I don't have time to fix that right now, so let's just get this in and I'll continue work towards a 2.x stable release.
Comment #45
adamps commented