HTML Field not being displayed

I had been making use of html fields to display some headings/instructions in the edit/detail view. The html is however no longer being displayed.

I am running Version 7.9. I am not sure at which revision level the html field stopped working as I was not notified of the problem until now.

Please let me know what to check.

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)

Ok, and do you see anything in your logs? We need clues to find the problem… thanks!

Do you need the diagnostic file that can be created via Admin? Let me know what logs to collect.

In my first post above, I linked the words “your logs” to an article explaining where to find the logs.

This might be easy or difficult depending on your environment. Is this Linux or Windows? Is it your own server or a shared hosting?

Here the same,
In a html field, the source Code is shown. In the editor The field looks great.
I will post the log later.


Here a screenshot, maybe someone can help us/me.
I didn’t find anything in the logs and rebuilt the 7.8.2 Version.

Can you try doing the same thing in this online demo?

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

hey mjr1,

thanks for your fast answer. I created a new HTML field in invoices in the demo. If you create an invoice / edit view, you see the same thing…

Confirmed as a bug. I’ve raised this on GitHub here:

1 Like

Same here, html fields not showing

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.

@mjr1, that bug was introduced recently, you can track it here

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 :slight_smile:

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 :slight_smile:

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.

Hello everyone.

I needed html field in my custom module so I just extended default html field. This is my solution:

create file custom/include/SugarFields/Fields/Html/SugarFieldHtml.php
it’s content:


include_once 'include/SugarFields/Fields/Html/SugarFieldHtml.php';

class CustomSugarFieldHtml extends SugarFieldHtml {

	 * @param string $parentFieldArray
	 * @param array $vardef
	 * @param array $displayParams
	 * @param integer $tabindex
	 * @return string
	public function getEditViewSmarty($parentFieldArray, $vardef, $displayParams, $tabindex) {

		$sugarCleaner = new SugarCleaner();
		$vardef['value'] = $sugarCleaner::cleanHtml($this->getVardefValue($vardef));

		require_once 'include/SuiteEditor/SuiteEditorConnector.php';

		$settings = SuiteEditorConnector::getSuiteSettings($vardef['value'], 600);
		// set real field name
		$settings['textareaId'] = $vardef['name'];
		// and remove onclick actions
		$settings['clickHandler'] = 'function(e){}';
		$settings['tinyMCESetup'] = "{
                setup: function(editor) {},
                plugins: ['code', 'table', 'link'],

		$this->ss->assign('BODY_EDITOR', SuiteEditorConnector::getHtml($settings));
		$this->ss->assign('value', $vardef['value']);

		$this->setup($parentFieldArray, $vardef, $displayParams, $tabindex);
		return $this->fetch($this->findTemplate('EditView'));

	private function getVardefValue($vardef) {
		if (empty($vardef['value'])) {
			if (!empty($vardef['default'])) {
				return $vardef['default'];
			} elseif (!empty($vardef['default_value'])) {
				return $vardef['default_value'];

		return utf8_decode($vardef['value']);



Create file custom/include/SugarFields/Fields/Html/EditView.tpl

<div id='{{$}}_div'>
	<textarea id='{{$}}' tabindex='0' name='{{$}}' cols="100" rows="40" style="display: none;">{{$value}}</textarea>


and finally if you wan’t it to display as html on detailview than create custom/include/SugarFields/Fields/Html/DetailView.tpl

<span class="sugar_field" id="{{if empty($displayParams.idName)}}{{sugarvar key='name'}}{{else}}{{$displayParams.idName}}{{/if}}">{{$vardef.value}}</span>
{{if !empty($displayParams.enableConnectors)}}
{{sugarvar_connector view='DetailView'}}


Also you can filter value of the field in the SugarFieldHtml.php e.g.: remove javascript etc.

It works well in 7.9.7

Hi! do you think this solution is good enough so that you could contribute it into the code on GitHub? There is an issue there about this, I believe.

I think that it would be better to change implementation of SuiteEditorConnector::getSuiteSettings function and add more parameters so to make it more flexible


    public static function getSuiteSettings($html, $width, $fieldName = 'body_text', $jsOnclickHandler = 'onClickTemplateBody();') {
        return array(
            'contents' => $html,
            'textareaId' => $fieldName,
            'elementId' => 'email_template_editor',
            'width' => $width,
            'clickHandler' => "function(e){
            'tinyMCESetup' => "{
                setup: function(editor) {
                    editor.on('focus', function(e){
                plugins: ['code', 'table', 'link'],


and then remove overriding parameters of editor config from SugarFieldHtml:getEditViewSmarty

If someone can contribute these changes it would be nice but if no let me know in few days and I will try to do it myself