I just upgraded to 7.12.6 from 7.12.4 and when going into Compose Email the body field is missing.
Before the upgrade the emails working perfect - now we have no body field.
I found in the history, this problem already exist in version 7.11.16 - but solved in Oct. 2020.
Any idea?
Can you please try deleting a few things from your server-side cache? I saw this problem myself, and I think that is how I solved it, but I’d like to make sure.
Can you please try deleting these two files in your server and see if anything changes?
cache/smarty/templates_c/%%D1^D15^D1540D1D%%ComposeView.tpl.php (the codes will be different but the Composeview.tpl.php part should be there)
cache/themes/SuiteP/modules/Emails/ComposeView.tpl
I deleted those file, but nothing changed. As soon I open the crm in Browser, those files a generated new by the system. The body for the mail composer is still not here.
The point of deleting the files was precisely to ensure that they were regenerated.
But since it didn’t fix the problem I don’t know what else to try…
did you try to inspect element and see if there is something missing there?
have the same Problem (only with Edge and Chrome Browser).
There’s definitely a bug here.
Is any of you coming from an older installation that still had the SuiteR theme? If so, can you please check any mentions of SuiteR in config.php and config_override.php, and change them to SuiteP?
And you can also delete everything from cache/themes/SuiteR.
To be honest… I am not the hard coder (more an advanced user). Which elements I have to compare with?
Hi,
Follow this step to step process, it should do the trick.
If you have any other requirements around SuiteCRM you can always head over to our website for a free consultation SuiteCRM Solutions | Rolustech
I started from Version 7.11 and checked if there is any waste from SuiteR Theme - nothing found…
@StefanL did you check all the logs?
Are you a developer? Can I give you a list of steps involving changes to PHP code?
This solution is from Oct 2020 and doesn’t work. The Codes are different with 7.12.6.
If anyone really wants to debug this I suggest the following.
Go here: SuiteCRM/SugarFieldHandler.php at master · salesagility/SuiteCRM · GitHub
And change those lines
} else {
$string = $field->$displayTypeFunc($parentFieldArray, $vardef, $displayParams, $tabindex);
}
to add some logging:
} else {
$c= New \ReflectionClass($field);
$f= $c->getMethod($displayTypeFunc)->getFileName();
$GLOBALS['log']->fatal('SugarFieldHandler.php: vardef is ' . $vardef['name'] . ' of type ' . $vardef['type'] . ' at ' . $f);
$string = $field->$displayTypeFunc($parentFieldArray, $vardef, $displayParams, $tabindex);
}
Now, between each test you have to go and delete some cached tpls:
cache/smarty/templates_c/%%D1^D15^D1540D1D%%ComposeView.tpl.php (the codes can be different but the Composeview.tpl.php part should be there)
cache/themes/SuiteR/modules/Emails/ComposeView.tpl (if it exists, but probably it won’t)
cache/themes/SuiteP/modules/Emails/ComposeView.tpl
Then, visit the Compose window once and you will see messages in the logs explaining which files were used for each SugarField. The ones you are interested in are description and description_html. Tell me what you find.
Hey everyone!
There is a bug in the latest version 7.12.6 and it seems there are many from you also affected.
Any solution or idea?
Or what to do, so Sales Agility is taking over this issue?
Hi @smoothius!
I just wrote a detailed solution/idea (at least it could advance the diagnostic) above.
I wouldn’t assume (for now) that this is happening to everyone on 7.12.6. It’s quite possible that only a subset of people, with specific circumstances, are facing this issue. SalesAgility won’t be able to do anything if they can’t reproduce the issue on their test computers. We still don’t know if they can.
I had a look in the console while trying to do this and it generates the following errors, not sure if anybody has any ideas off the back of this. Sorry, not a coder.
JQMIGRATE: Migrate is installed, version 3.4.0
VM512:396 unable to find tinymce editor
$.fn.EmailsComposeView.updateSignature.self.updateSignature @ VM512:396
/vendor/tinymce/tinymce/themes/silver/theme.min.js:1 Failed to load resource: the server responded with a status of 404 ()
2DevTools failed to load source map: Could not load content for https://domainremoved/jquery.qtip.min.js.map: HTTP error: status code 404, net::ERR_HTTP_RESPONSE_CODE_FAILURE
VM688:396 unable to find tinymce editor
$.fn.EmailsComposeView.updateSignature.self.updateSignature @ VM688:396
(anonymous) @ VM688:1105
each @ sugar_grp1_jquery.js?v=loadofrandomcharactersIremoved
each @ sugar_grp1_jquery.js?v=loadofrandomcharactersIremoved
(anonymous) @ VM688:1077
c @ sugar_grp1_jquery.js?v=loadofrandomcharactersIremoved
add @ sugar_grp1_jquery.js?v=loadofrandomcharactersIremoved
self.construct @ VM688:1074
$.fn.EmailsComposeView @ VM688:1237
(anonymous) @ sugar_grp1_jquery.js?v=loadofrandomcharactersIremoved
c @ sugar_grp1_jquery.js?v=loadofrandomcharactersIremoved
add @ sugar_grp1_jquery.js?v=loadofrandomcharactersIremoved
$.fn.openComposeViewModal @ sugar_grp1_jquery.js?v=loadofrandomcharactersIremoved
onclick @ index.php?action=ajaxui:1
VM689:9 GET https://domainremoved/vendor/tinymce/tinymce/themes/silver/theme.min.js net::ERR_ABORTED 404
Hey Everyone,
I had the same bug. For me it was as simple as resetting the permissions for all the folders.
With inspecting I found that it couldn’t load:
/vendor/tinymce/tinymce/themes/silver/theme.min.js
But the file was in the folder.
Resetting de folders to 755 brought back the body of the e-mail composer.
I hope it also workes for you guys.
Tom
Hi Sorry for late reply, I was on vacation. I´m not an Developer, but I´ll check it and I´ll test the 755 rights - normal I do that after every update as descripted in documentation…
This seems to be the solution… Thank you. After setting /vendor plus all subfolders to 755, the composer is back again.
Should I reset also all folders from the complete installation?
The solution from TomvtZand seems to be the solution.
Should I also reset all other folders from the complete installation to 755?