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?
- suitecrm.log
- php_errors.log
- browser javascript console
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.
- SugarFieldWysiwyg.php is complete different
-_head.tpl is already changed in the installation
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?
That depends on which user your web server is running under, and on which user owns the directories and files.
Linux permissions have their natural complexity and can’t be reduced to generic recommendations… it’s just not possible.
Hi,
755 didn´t help for me. Would also surprise me, since it does or does not occur depending on the browser you use…
Hi,
Sorry to hear, for me the problem was in all browsers and it works in all browsers since the 755.
However there is still sort of a problem because I always get the tinymce editor, no matter what option (html, mosaic) I set it on.
For now it works for me.
Good luck with searching for your solution.
Tom