Hi,
Email was working fine and variables in Email templates were getting replaced with corresponding values in my SuiteCRM 7.6.4.
I have recently upgraded the SuiteCRM to 7.10.7
Now variables in Email template are not being replaced with their values and appearing same in received email as in template.
Please suggest how to resolved this.
Thanks,
I know this was a known issue, maybe you can find it on Github?
It might be already fixed. Can you try it in 7.10.9?
Sorry I didn’t see that post when I submitted another post a couple of hours after you.
It looks like all fields are correctly parsed … except enum and multienum fields.
That was fixed a long time ago, but it reappeared in Campaigns since modifications were made in modules/EmailMan/EmailMan.php.
It now uses class EmailTemplateParser instead of parse_email_template.
This apparently was done to support surveys … but EmailTemplateParser does not translate enum fields or multienum fields for Contacts/Leads/Accounts.
I can’t reproduce that on http://demo.suiteondemand.com/ as it would require admin rights to access dropdown editor, but it’s very easy to reproduce.
Hi pgr,
Thanks for your suggestion.
I am trying to upgrade my SuiteCRM to 7.10.9 it is showing error “Database failure. Please refer to suitecrm.log for details.” in upgrade wizard.
upgradeWizard.log updated with below error during this process :
Mon, 24 Sep 2018 11:05:08 +0000 [UpgradeWizard] - setting session variables…
Mon, 24 Sep 2018 11:05:08 +0000 [UpgradeWizard] - -----------------------------------------------------------------------------
Mon, 24 Sep 2018 11:05:08 +0000 [UpgradeWizard] - Upgrade started. At start.php
Mon, 24 Sep 2018 11:05:08 +0000 [UpgradeWizard] - at unlinkUWTempFiles()
Mon, 24 Sep 2018 11:05:08 +0000 [UpgradeWizard] - finished!
Mon, 24 Sep 2018 11:05:08 +0000 [UpgradeWizard] - resetting $_SESSION
Mon, 24 Sep 2018 11:05:12 +0000 [UpgradeWizard] - setting session variables…
Mon, 24 Sep 2018 11:05:12 +0000 [UpgradeWizard] - [At systemCheck.php]
Mon, 24 Sep 2018 11:05:12 +0000 [UpgradeWizard] - Starting file permission check…
Mon, 24 Sep 2018 11:06:34 +0000 [UpgradeWizard] - Finished file permission check.
Mon, 24 Sep 2018 11:06:34 +0000 [UpgradeWizard] - Starting database permissions check…
Mon, 24 Sep 2018 11:06:34 +0000 [UpgradeWizard] - Checking CREATE TABLE permissions…
Mon, 24 Sep 2018 11:06:34 +0000 [UpgradeWizard] - cannot CREATE TABLE!
Mon, 24 Sep 2018 11:06:34 +0000 [UpgradeWizard] - Checking INSERT INTO permissions…
Mon, 24 Sep 2018 11:06:34 +0000 [UpgradeWizard] - cannot INSERT INTO!
Mon, 24 Sep 2018 11:06:34 +0000 [UpgradeWizard] - Checking UPDATE TABLE permissions…
Mon, 24 Sep 2018 11:06:34 +0000 [UpgradeWizard] - cannot UPDATE TABLE!
Mon, 24 Sep 2018 11:06:34 +0000 [UpgradeWizard] - Checking SELECT permissions…
Mon, 24 Sep 2018 11:06:34 +0000 [UpgradeWizard] - cannot SELECT!
Mon, 24 Sep 2018 11:06:34 +0000 [UpgradeWizard] - Checking DELETE FROM permissions…
Mon, 24 Sep 2018 11:06:34 +0000 [UpgradeWizard] - cannot DELETE FROM!
Mon, 24 Sep 2018 11:06:34 +0000 [UpgradeWizard] - Checking ALTER TABLE ADD COLUMN permissions…
Mon, 24 Sep 2018 11:06:34 +0000 [UpgradeWizard] - cannot ADD COLUMN!
Mon, 24 Sep 2018 11:06:34 +0000 [UpgradeWizard] - Checking ALTER TABLE CHANGE COLUMN permissions…
Mon, 24 Sep 2018 11:06:34 +0000 [UpgradeWizard] - cannot CHANGE COLUMN!
Mon, 24 Sep 2018 11:06:34 +0000 [UpgradeWizard] - Checking ALTER TABLE DROP COLUMN permissions…
Mon, 24 Sep 2018 11:06:34 +0000 [UpgradeWizard] - cannot DROP COLUMN!
Mon, 24 Sep 2018 11:06:34 +0000 [UpgradeWizard] - Checking DROP TABLE permissions…
Mon, 24 Sep 2018 11:06:34 +0000 [UpgradeWizard] - cannot DROP TABLE!
Mon, 24 Sep 2018 11:06:34 +0000 [UpgradeWizard] - Finished database permissions check.
suitecrm.log was updated by below errors during the process :
Mon Sep 24 11:04:24 2018 [27344][1][FATAL] log call at: modules/Administration/index.tpl:54 - MY_FRAME is not set
Mon Sep 24 11:06:34 2018 [27456][1][FATAL] Mysqli_query failed.
Mon Sep 24 11:06:34 2018 [27456][1][FATAL] Query Failed: CREATE TABLE temp (id varchar(36)): MySQL error 2006: MySQL server has gone away
Mon Sep 24 11:06:34 2018 [27456][1][FATAL] Checking privileges: MySQL error 2006: MySQL server has gone away
Mon Sep 24 11:06:34 2018 [27456][1][FATAL] Mysqli_query failed.
Mon Sep 24 11:06:34 2018 [27456][1][FATAL] Query Failed: INSERT INTO temp (id) VALUES (‘abcdef0123456789abcdef0123456789abcd’): MySQL error 2006: MySQL server has gone away
Mon Sep 24 11:06:34 2018 [27456][1][FATAL] Checking privileges: MySQL error 2006: MySQL server has gone away
Mon Sep 24 11:06:34 2018 [27456][1][FATAL] Mysqli_query failed.
Mon Sep 24 11:06:34 2018 [27456][1][FATAL] Query Failed: UPDATE temp SET id = ‘100000000000000000000000000000000000’ WHERE id = ‘abcdef0123456789abcdef0123456789abcd’: MySQL error 2006: MySQL server has gone away
Mon Sep 24 11:06:34 2018 [27456][1][FATAL] Checking privileges: MySQL error 2006: MySQL server has gone away
Mon Sep 24 11:06:34 2018 [27456][1][FATAL] Mysqli_query failed.
Mon Sep 24 11:06:34 2018 [27456][1][FATAL] Query Failed: SELECT id FROM temp WHERE id=‘100000000000000000000000000000000000’ LIMIT 0,1: MySQL error 2006: MySQL server has gone away
Mon Sep 24 11:06:34 2018 [27456][1][FATAL] Get One Failed:SELECT id FROM temp WHERE id=‘100000000000000000000000000000000000’: MySQL error 2006: MySQL server has gone away
Mon Sep 24 11:06:34 2018 [27456][1][FATAL] Mysqli_query failed.
Mon Sep 24 11:06:34 2018 [27456][1][FATAL] Query Failed: DELETE FROM temp WHERE id = ‘100000000000000000000000000000000000’: MySQL error 2006: MySQL server has gone away
Mon Sep 24 11:06:34 2018 [27456][1][FATAL] Checking privileges: MySQL error 2006: MySQL server has gone away
Mon Sep 24 11:06:34 2018 [27456][1][FATAL] Mysqli_query failed.
Mon Sep 24 11:06:34 2018 [27456][1][FATAL] Query Failed: ALTER TABLE temp add COLUMN test varchar(50) NULL : MySQL error 2006: MySQL server has gone away
Mon Sep 24 11:06:34 2018 [27456][1][FATAL] Checking privileges: MySQL error 2006: MySQL server has gone away
Mon Sep 24 11:06:34 2018 [27456][1][FATAL] Mysqli_query failed.
Mon Sep 24 11:06:34 2018 [27456][1][FATAL] Query Failed: ALTER TABLE temp modify COLUMN test varchar(100) NULL : MySQL error 2006: MySQL server has gone away
Mon Sep 24 11:06:34 2018 [27456][1][FATAL] Checking privileges: MySQL error 2006: MySQL server has gone away
Mon Sep 24 11:06:34 2018 [27456][1][FATAL] Mysqli_query failed.
Mon Sep 24 11:06:34 2018 [27456][1][FATAL] Query Failed: ALTER TABLE temp drop COLUMN test: MySQL error 2006: MySQL server has gone away
Mon Sep 24 11:06:34 2018 [27456][1][FATAL] Checking privileges: MySQL error 2006: MySQL server has gone away
Mon Sep 24 11:06:34 2018 [27456][1][FATAL] Mysqli_query failed.
Mon Sep 24 11:06:34 2018 [27456][1][FATAL] Query Failed: DROP TABLE IF EXISTS temp: MySQL error 2006: MySQL server has gone away
Mon Sep 24 11:06:34 2018 [27456][1][FATAL] Checking privileges: MySQL error 2006: MySQL server has gone away
Mon Sep 24 11:06:34 2018 [27456][1][FATAL] Mysqli_query failed.
Mon Sep 24 11:06:34 2018 [27456][1][FATAL] Query Failed: SELECT version() version LIMIT 0,1: MySQL error 2006: MySQL server has gone away
Mon Sep 24 11:06:34 2018 [27456][1][FATAL] Get One Failed:SELECT version() version: MySQL error 2006: MySQL server has gone away
Mon Sep 24 11:06:34 2018 [27456][1][FATAL] Mysqli_query failed.
Mon Sep 24 11:06:34 2018 [27456][1][FATAL] Query Failed: SELECT id FROM upgrade_history ORDER BY date_entered desc: MySQL error 2006: MySQL server has gone away
Mon Sep 24 11:06:34 2018 [27456][1][FATAL] Exception handling in /home/shirtwor/public_html/suite/include/MVC/Controller/SugarController.php:402
Mon Sep 24 11:06:34 2018 [27456][1][FATAL] Exception in Controller: Database failure. Please refer to suitecrm.log for details.
Mon Sep 24 11:06:34 2018 [27456][1][FATAL] backtrace:
#0 /home/shirtwor/public_html/suite/include/database/DBManager.php(353): sugar_die(‘Database failur…’)
#1 /home/shirtwor/public_html/suite/include/database/DBManager.php(328): DBManager->registerError(’ Query Failed: …’, ’ Query Failed: …’, true)
#2 /home/shirtwor/public_html/suite/include/database/MysqliManager.php(177): DBManager->checkError(’ Query Failed: …’, true)
#3 /home/shirtwor/public_html/suite/data/SugarBean.php(5519): MysqliManager->query(‘SELECT id FROM …’, true)
#4 /home/shirtwor/public_html/suite/modules/Administration/UpgradeHistory.php(171): SugarBean->build_related_list(‘SELECT id FROM …’, Object(UpgradeHistory))
#5 /home/shirtwor/public_html/suite/modules/Administration/UpgradeHistory.php(167): UpgradeHistory->getList(‘SELECT id FROM …’)
#6 /home/shirtwor/public_html/suite/modules/UpgradeWizard/index.php(312): UpgradeHistory->getAll()
#7 /home/shirtwor/public_html/suite/include/MVC/View/SugarView.php(840): include_once(’/home/shirtwor/…’)
#8 /home/shirtwor/public_html/suite/include/MVC/View/views/view.classic.php(74): SugarView->includeClassicFile(’/home/shirtwor/…’)
#9 /home/shirtwor/public_html/suite/include/MVC/View/SugarView.php(207): ViewClassic->display()
#10 /home/shirtwor/public_html/suite/include/MVC/Controller/SugarController.php(432): SugarView->process()
#11 /home/shirtwor/public_html/suite/include/MVC/Controller/SugarController.php(375): SugarController->processView()
#12 /home/shirtwor/public_html/suite/include/MVC/SugarApplication.php(109): SugarController->execute()
#13 /home/shirtwor/public_html/suite/index.php(54): SugarApplication->execute()
#14 {main}
SuiteCRM was upgrading till existing version smoothly.
Please suggest how to resolve this.
Thanks,
Harendra
These “MySQL server has gone away” are serious database crashes. Normally they should not happen even if SuiteCRM has some bug asking the database to do something crazy. It should give a proper error, not crash.
You’ll find pages explaining a number of causes for this:
https://dev.mysql.com/doc/en/gone-away.html
These can be very diverse things, from memory problems to timeouts to DNS issues. Try to check each one.
Hi Benoit,
just found this thread after having discussed this issue in Github (https://github.com/salesagility/SuiteCRM/issues/5771) for months without any outcome. We have just updated our installation to 7.10.9. but the bug stillt isn’t fixed 
Since you seem to know where the bug has been introduced, do you have any idea how to “hot fix” it without having to wait for the next scheduled SuiteCRM release? We had to create a nasty workaround to send out mailings at all and I would really like to get this working properly again soon…
Best
Matthias
Hi Pgr,
Thanks for your advise.
I have upgraded my SuiteCRM to 7.10.9 but email template variables are still not getting values.
Can you please suggest some solution for this.
Thanks,
Hi,
I have upgraded my SuiteCRM to 7.10.11 from 7.10.9 but email template variables still not getting values.
Please suggest some solution for this.
Thanks,
You can check what is planned for the next version here:
https://github.com/salesagility/SuiteCRM/milestone/6
You will see these issues you mention are included there.
You can keep an eye on them, see if the fixes are already available, and if you can help out by testing them, that is helpful. Thanks.
Good morning @harendra and a Happy New Year to everyone!
The bug you are looking a solution for has already been hotfixed, see here:
https://github.com/salesagility/SuiteCRM/pull/6466
We have implented the fix and the template variables are replaced correctly again.
Best
Matthias
Hi Mathias
please make sure you comment on the PR in Github to say that you have tested successfully, that helps the team be sure they can move it forward. Thanks.
Hi pgr,
thanks for reminding me, I’ve just posted a corresponding comment in Github.
Best
Matthias
Hi,
I am using SuiteCRM 7.10.9 but email template variables are still not getting values at my end.
Can anyone please suggest specific changes on SuiteCRM to resolve this issue.
Thanks,
The specific changes I suggest are upgrading to the latest in your branch - 7.10.14
You can also try applying the fix manually by making these changes:
i know they say this is resolved but i just upgraded to 7.11.14 and php 7.3 and it seems to still be a issue . workflow emails do seem to work correctly this is only affecting campaign email variables .
$contact_first_name
$contact_email1
this is tested with contact / lead / target they all 3 do the same no value inputed . i have looked at suitecrm.log dont see any errors calling out the error . any help would be great .
For this to be worked on, an open Issue needs to exist on GitHub. Please either create a new one, or comment on the existing one asking for reopening.
Same problem here. I am on 7.11.9.
I am trying to get the agent’s name into the email and his full name at the end.
Still shows variables and not the names.
This has now been going on for 6 years if I look at the history of not Suite CRM being able to merge the names etc into the variables.
Why?
The context that is used for the variables is the one coming from the Relate to box, on the top right.
Many people think it is the email address in To: box, but it isn’t. There can be many of those, not just one; it is not sufficient to establish an unambiguous context.
We are populateing our email body with for example our sales representative’s name, his phone number, his email etc. (extracting it from the Profile for the sales rep/our employee).
We use the leads or opportunity’s email of course.
We have not tried to include any other dynamic variables yet as this part is not working.
How should we do to be able to get this to work properly?
If you can get by with getting variables from just one module, then put that reference in the Related to box and it should work.
If you need variables form Leads and Users, then that is going to take some customizations. (I am working on an add-on called PowerReplacer which should be available this month that provides a lot more variable substitution functionality.)