Answers.Body: <p>I have just a suggestion for debugging:</p>
  
  <ol>
  <li>Enable debugging at <code>civicrm/admin/setting/debug</code>.</li>
  <li>Add the smarty token <code>{debug  output="html"}</code> to the workflow message template.</li>
  <li>Now a dump of all the smarty variables and their values are shown in the email. Better to this on a test instance because you do not want your participants to see this.</li>
  <li>Examine the values of <code>$event.confirm_email_text</code>, <code>$isOnWaitlist</code> and <code>$isRequireApproval</code>. Maybe this gives some more information.</li>
  </ol>
  
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2017-12-14T21:03:12.460Z
Answers.Text: I'll try that later. It isn't pulling in the waitlist or requireapproval text, as the text under those doesn't show. There's the text I quoted above, then an else, then the waitlist, then the requireapproval. It's pulling the "else".
Answers.UserDisplayName: Jenni Simonis
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2017-12-14T11:47:51.957Z
Answers.LastActivityDate: 2017-12-14T11:47:51.957Z
Answers.UserDisplayName: Kainuk - CiviCooP
Answers.Body: <p>In my experience, registration (receipt etc.) emails can be very finicky, one small character "{" out of place and things can go south quickly. </p>
  
  <p>Have you've customized your email language? If so, you can revert to the default email message - don't forget to keep a copy of your customizations - and run a test registration to see if the error still exists.</p>
  
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2017-12-16T04:29:21.950Z
Answers.Text: We did, but it was working for a couple weeks at least after that. I ran tests after the last changes I made and everything was working.
Answers.UserDisplayName: Jenni Simonis
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2017-12-18T15:01:16.063Z
Answers.Text: Is it a new event registration that the email receipt language is not working properly on or all events?
Answers.UserDisplayName: RayWright
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2017-12-19T00:16:44.913Z
Answers.Text: It's all of them. They're all using the else instead of what they were using previously.
Answers.UserDisplayName: Jenni Simonis
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2017-12-19T14:24:43.433Z
Answers.Text: No other changes to the events themselves? Do the events have confirmation language set in the online registration section?
Answers.UserDisplayName: RayWright
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2017-12-20T03:27:16.117Z
Answers.Text: Nope, there were no changes since then - some of these were created well before then. The confirmation language is the same it's always been. I've gotten pulled off to a couple other things, so I just copied the text into the "else" for now so that at least the emails are sending. I've got to refresh the database on the dev site so that I can test out some things there to see what I can find out.
Answers.UserDisplayName: Jenni Simonis
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2017-12-20T15:57:55.980Z
Answers.Text: I'm starting to run out of trouble shooting suggestions for you ;) Just so I know - did you test reverting to the default message to see if it would catch the correct half of the if statement? (which should be the {$event.confirm_email_text|htmlize} text.)
Answers.UserDisplayName: RayWright
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2017-12-21T00:46:38.063Z
Answers.Text: That's what I'm planning to do on the dev site. I can't do it on the live site since people are actively signing up for things. The band-aid fix works for now, but I want to get it actually fixed. I'm going to reset the dev site to match the live site and then test out all the suggestions. I just hit some other stuff that was more time sensitive and had to switch hats. Isn't that how it always works? ;)
Answers.UserDisplayName: Jenni Simonis
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2017-12-15T14:44:31.107Z
Answers.LastActivityDate: 2017-12-15T14:44:31.107Z
Answers.UserDisplayName: RayWright
Body: <p>Until recently, the correct email was being sent out when someone registered. Recently (I don't know exactly when since I don't get a copy of them), the wrong one started going out. I can't figure out why.</p>
  
  <p>The email template being sent is <em>Events - Registration Confirmation and Receipt (on-line)</em>.</p>
  
  <p>It used to be that the text under this was sent out if you registered: </p>
  
  <pre><code>    {if $event.confirm_email_text AND (not $isOnWaitlist AND not $isRequireApproval)}
  </code></pre>
  
  <p>Now instead of it sending out that, it's sending out what is under the else that is under that.</p>
  
  <p>What could have caused this? The events do not have a waitlist, nor do they require approval. Occasionally we do have ones that do have either/both of those, but none of the current events do.</p>
  
  <p>Thanks!</p>
  
  <p>EDIT: Sorry, forgot to add that this is CiviCRM 4.7.22 and Drupal. I don't know of any PHP updates, but those things sometimes happen via the hosting company without our knowledge. The last CiviCRM updates should have been done prior to the last time I tested the email process a couple weeks back or so.</p>
  
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2017-12-13T22:00:53.433Z
Comments.Text: Hi Jenni, it helps if you add the version of CiviCRM you are using. And did you do a recent upgrade of CiviCRM, PHP or the database?
Comments.UserDisplayName: Kainuk - CiviCooP
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2017-12-13T22:25:53.870Z
Comments.Text: doesn't help you now but using the Transactional Email extension can be useful in such situations as you get to see what went out - https://github.com/fuzionnz/nz.co.fuzion.transactional
Comments.UserDisplayName: petednz - fuzion
Tags: <civievent><drupal><4.7><system-workflow-messages>
Title: Wrong email being sent for event confirmations
ThreadText: # Wrong email being sent for event confirmations
  
  (Asked by: username_0 on 2017-12-13)
  
  Until recently, the correct email was being sent out when someone registered. Recently (I don't know exactly when since I don't get a copy of them), the wrong one started going out. I can't figure out why.
  
  The email template being sent is *Events - Registration Confirmation and Receipt (on-line)*.
  
  It used to be that the text under this was sent out if you registered:
  
  ```
      {if $event.confirm_email_text AND (not $isOnWaitlist AND not $isRequireApproval)}
  
  ```
  
  Now instead of it sending out that, it's sending out what is under the else that is under that.
  
  What could have caused this? The events do not have a waitlist, nor do they require approval. Occasionally we do have ones that do have either/both of those, but none of the current events do.
  
  Thanks!
  
  EDIT: Sorry, forgot to add that this is CiviCRM 4.7.22 and Drupal. I don't know of any PHP updates, but those things sometimes happen via the hosting company without our knowledge. The last CiviCRM updates should have been done prior to the last time I tested the email process a couple weeks back or so.
  
  **Tags:** civievent, drupal, 4.7, system-workflow-messages
  
  > **Comments:**
  > **username_1**: Hi username_0, it helps if you add the version of CiviCRM you are using. And did you do a recent upgrade of CiviCRM, PHP or the database?  
  > **username_2**: doesn't help you now but using the Transactional Email extension can be useful in such situations as you get to see what went out - https://github.com/fuzionnz/nz.co.username_2.transactional  
  
  ---
  
  ## 2 answers
  
  ### Answer by username_1 on 2017-12-14. Score: 1
  
  I have just a suggestion for debugging:
  
  1. Enable debugging at `civicrm/admin/setting/debug`.
  2. Add the smarty token `{debug output="html"}` to the workflow message template.
  3. Now a dump of all the smarty variables and their values are shown in the email. Better to this on a test instance because you do not want your participants to see this.
  4. Examine the values of `$event.confirm_email_text`, `$isOnWaitlist` and `$isRequireApproval`. Maybe this gives some more information.
  
  > **Comments:**
  > **username_0**: I'll try that later. It isn't pulling in the waitlist or requireapproval text, as the text under those doesn't show. There's the text I quoted above, then an else, then the waitlist, then the requireapproval. It's pulling the "else".  
  
  ---
  
  ### Answer by username_3 on 2017-12-15. Score: 0
  
  In my experience, registration (receipt etc.) emails can be very finicky, one small character "{" out of place and things can go south quickly.
  
  Have you've customized your email language? If so, you can revert to the default email message - don't forget to keep a copy of your customizations - and run a test registration to see if the error still exists.
  
  > **Comments:**
  > **username_0**: We did, but it was working for a couple weeks at least after that. I ran tests after the last changes I made and everything was working.  
  > **username_3**: Is it a new event registration that the email receipt language is not working properly on or all events?  
  > **username_0**: It's all of them. They're all using the else instead of what they were using previously.  
  > **username_3**: No other changes to the events themselves? Do the events have confirmation language set in the online registration section?  
  > **username_0**: Nope, there were no changes since then - some of these were created well before then. The confirmation language is the same it's always been. I've gotten pulled off to a couple other things, so I just copied the text into the "else" for now so that at least the emails are sending. I've got to refresh the database on the dev site so that I can test out some things there to see what I can find out.  
  > **username_3**: I'm starting to run out of trouble shooting suggestions for you ;) Just so I know - did you test reverting to the default message to see if it would catch the correct half of the if statement? (which should be the {$event.confirm_email_text|htmlize} text.)  
  > **username_0**: That's what I'm planning to do on the dev site. I can't do it on the live site since people are actively signing up for things. The band-aid fix works for now, but I want to get it actually fixed. I'm going to reset the dev site to match the live site and then test out all the suggestions. I just hit some other stuff that was more time sensitive and had to switch hats. Isn't that how it always works? ;)  
  
  ---
  
  