Title might be a bit confusing, but the behavior I'm seeing is:
1. Create a contact form
2. Create a contact email referencing some tokens from that form
3. Delete one of the fields from the contact form that's being referenced within the email body
4. Edit the email and try to save it--as expected, I get a validation error about an invalid token.
5. Remove the invalid token and try to save it--I get the same error.
It seems as if it's using the previous body value for the token validation at the moment, though I'm not sure if that's actually the case or not.
| Comment | File | Size | Author |
|---|---|---|---|
| #5 | unable_to_save_an_email-2868559-5.patch | 1.03 KB | scott_euser |
Comments
Comment #2
scott_euser commentedHmmm I tried following the steps above and didn't encounter the issue. I was able to save fine. I don't think there is anything special happening in the module compared to the use of tokens elsewhere such as core so perhaps you've come across an issue with core or another contrib module that is modifying how tokens work?
Comment #3
replicaobscuraSo your steps 1-4 are the same, but in #5 saving works properly?
The issue is consistent for me every time, and only affects contact_emails, nowhere else that tokens are used are experiencing this issue, which is confusing.
It seemed to me it's likely got something to do with how the body field is output separately in the form and then stored to the entity's body field within the validate callback. That is happening before the parent validate function is called, so I would have expected it to work, but something seems to be attempting to validate the existing value in my case before it's assigned in that validate callback, or so it seems.
I'll keep investigating on my end to see if I can track it down. It's definitely possible it's related to something else in my environment, but it seems fishy that tokens used everywhere else I've tested don't experience this problem. I'll post back if I do find anything.
Comment #4
scott_euser commentedI'll try to give it a shot over the weekend again as well.
Comment #5
scott_euser commentedSorry for the delay on this. I have investigated further and was able to reproduce - I must have done something wrong before.
So following the code in core for the content entity form validation, I can see the $form_state is being used to create a clone of the entity to validate it
$entity = $this->buildEntity($form, $form_state);here. The cloned entity correctly returns the new body with the deleted token. However, when that clone calls getTypedData here to process any base entity constraints it getTypedData returns the original body and not the one set by the form state.I have attached a patch for a workaround for now.
Comment #6
scott_euser commentedFound the issue but have to run now, will solve tonight or tomorrow morning. Issue is with $form['body'] not being created as part of the base entity unlike the other fields.
Comment #7
replicaobscuraNice! Glad to hear I'm not going crazy :) Thanks for looking further into this one.
Comment #9
scott_euser commentedNo problem :) That should do it!
Note that if you're on the dev branch you'll need to run 'drush entity-updates'.
On release this will be covered by the existing hook install: contact_emails_update_8005 by running 'drupal updb'
On fresh install the entity is installed fresh, so no issues.
Can you let me know if that works correctly for you as well and if not, reopen?
Comment #10
replicaobscuraI believe this is good. Haven't noticed the issue yet and I'm fairly certain I just removed a token that no longer exists, without an error!
Comment #11
scott_euser commentedGreat thanks, just wanted to make sure it also worked for you for sanity :)