You can check your logs to see if there are any clues there.
Version 7.9 has a few nasty bugs, but 7.9.1 should be out any day now, so the first thing I would do is install 7.9.1 to see if it solves your problem.
I have now loaded 7.9.1 and can confirm that fields of type HTML are still only being displayed as a blank. - Tested in Chrome and MS Edge (both up to date)
This way we can check whether it’s just a problem with your install.
While you’re doing it, please make a note of every step so that then you can give me a “steps to reproduce” list and I can try it here in my installation. Many thanks
Version 7.9.10 - Html field still not able to display anything. This field worked in Sugar 6.5 !!
As an asised, we have been running a demo version of SuiteCRM for over a year as there is obviously a need to migrate from Sugar CE. However, given the number of bugs in SuiteCRM, (especially in items that work in Sugar) it is hard to gather the required support to make a transition. Instead we may start to look elsewhere. Too bad as the SuiteCRM effort looked to be quite noble and support worthy.
The reason it was introduced were the hundreds of security fixes that the team has been making in the past year, following an independent security review. Many things that “worked in SugarCRM” were security holes and needed to be fixed. HTML fields are a specially sensitive area since you can do many things from HTML if care is not taken. Javascript injections, etc.
I am with you in your disappointment on the lack of robustness that SuiteCRM has shown sometimes, but consider that the team is growing at a fast pace, the automated test framework was just put into place and is about to get its coverage expanded, the rhythm of bug fixing and PR merging has increased tremendously… there is no reason why 2018 can’t be an excellent year for SuiteCRM.
Anyway thanks for your frank appraisal. I hope to see you around in the future
Many thanks for your explanation regarding the security risks. It might be useful to advise your growing audience that your proactive work in providing a secure CRM will limit past functionality. This would be superior to having probably many (including myself) believe that poor software practices are reducing/eliminating past functionality. The first is easy to promote and support. The latter obviously not.
I will forward your security explanation and hope that the html functionality can be re implemented in a secure manner.
It’s not that “our proactive work in providing a secure CRM will limit past functionality”, it’s just that something broke when we were trying to fix it
What I mean is, this is a bug that shouldn’t have been introduced, and you do have reason to complain. My explanation is only meant to justify why we couldn’t simply leave things as they were…
SuiteCRM has been receiving some structural improvements, to try to insure this doesn’t happen too often. The most important is the automated tests infrastructure. It’s there, but still has quite limited coverage of this huge app.
Anyway, this is real open-source, this is a Community. We count on help from everybody reporting bugs, fixing them, suggesting things to improve, etc.
I think that it would be better to change implementation of SuiteEditorConnector::getSuiteSettings function and add more parameters so to make it more flexible