WYSIWYG can't save images

šŸ‘Øā€šŸ’» Development Help
1

Hi,
I have created a custom form with the WYSIWYG field.
The images I insert into the editor (images that are encoded correctly in base64) show up correctly.
When I save instead they disappear.
As if they are truncated by some text purification feature.
How can I save the images?

Thanks

2

I confirm that there is definitely a feature active that gets in the way before saving to purify the html. Because if I manually copy the html content (taken by firefox console) that is sent, after clicking on the ā€˜Saveā€™ button and I manually insert it in the form table field on the Database, when I go to refresh the detail view of the record in CRM the base64 image is present and visible.

3

Infamous SuiteCRM over-zealous string clean-up routinesā€¦ sighā€¦

Youā€™ll find some clues for your troubleshooting here:

4

Thank you @pgr ,
I suspected it was some overzealous purification functionality :wink:

I used your feature and as per the log you can clearly see that the tag is truncated of the attribute ā€˜srcā€™ where there is the base64 binary of the image.

Array
(
    [nota] => Was <!DOCTYPE html>
<html>
<head>
</head>
<body>
<p>Questo &egrave; lo screenshot che ho fatto:</p>
<p><img src="https://www.elinet.it/wp-content/themes/elinet/images/logo-elinet.png" alt="logo" width="199" height="60" /></p>
<p>Questo &egrave; il secondo screenshot:</p>
<p><img src="data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAb0AAAFPCAYAAADZdBBWAAAgAElEQVR4XuydB3yN1xvHfxmCJEajtlatao3ao1aNoilK1SpqVxTlb5QqtUqNGjWLltoUjVGjqFJq71lpESOoKEIIuTL+z3lHcpPc8d6be2/emzzvp/koed/3nPM94**...**ujF0yAAAEC2QJKL1tcHgECBAiUCSi9MnrBBAgQIJAtoPSyxeURIECAQJmA0iujF0yAAAEC2QJKL1tcHgECBAiUCSi9MnrBBAgQIJAtoPSyxeURIECAQJmA0iujF0yAAAEC2QJKL1tcHgECBAiUCSi9MnrBBAgQIJAt8B8svs29q7jcNwAAAABJRU5ErkJggg==" alt="" /></p>
</body>
</html>, became &lt;!DOCTYPE html>
&lt;html&gt;
&lt;head&gt;
&lt;/head&gt;
&lt;body&gt;
<p>Questo ĆØ lo screenshot che ho fatto:</p>
<p><img src="https://www.elinet.it/wp-content/themes/elinet/images/logo-elinet.png" alt="logo" width="199" height="60" /></p>
<p>Questo ĆØ il secondo screenshot:</p>
<p><img  alt="" /></p>
&lt;/body&gt;
&lt;/html&gt;
    [Date_time] => 2022-02-18 03:16:53pm
    [StackTrace] => Function/method: write_to_log() File: /var/www/html/x-crm-dev/include/utils.php on line: 2529  | 
)

Ps: to show the answer I deleted a lot of the binary in the image, the important thing was to show that first it is present then it is deleted.

5

Unfortunately, this purification also removes images in other places like email templates:
Example:

  • Go to https://demo.suiteondemand.com
  • Create an email template
  • Try to insert an image using the upload (camera) button.
  • Source shows cache/images/xxx.png (or whatever filename you inserted)
  • The image is correctly uploaded to the server
  • When saving, src=ā€œcache/images/xxx.pngā€ is removed from the source in the image definition
6

Confirmed, I had already had issues with the Email Template module as well regarding inline styles.
I had followed some advice from the community that in /data/SugarBean.php
I commented these two lines, using as text editor the pure HTML one not WYSIWYG:

/$this->$key = htmlentities(SugarCleaner::cleanHtml($this->$key, true));/

/$this->$key = htmlentities(SugarCleaner::cleanHtml($this->$key, true));/

However, this solution does not work for the WYSIWYG editor.

As I always thought it would be enough to have a field or a variable where you can specify the security level for the cleanup e.g. high, medium, low etcā€¦

7

Probably the clean_incoming_data function
is not the only one in the flow of saving data to db that takes care of data cleaning.
Yes for the consideration that by commenting out the whole function except return 0 the editor content is cleaned anyway.
I also checked that in the clean_incoming_data function if I comment out the following piece of code:

foreach ($req as $k => $v) {
        $_REQUEST[$k] = $v;

        //ensure the keys are safe as well.  If mbstring encoding translation is on, the post keys don't
        //get translated, so scrub the data but don't die
        if (ini_get('mbstring.encoding_translation') === '1') {
            securexsskey($k, false);
        } else {
            securexsskey($k, true);
        }
    }

The content of the WYSIWYG field in the global variable $_REQUEST is not cleaned, so surely there will be an additional cleanup step afterwards before the data is written to the DB

8

To solve the problem I used the workaround idea found here
I created a Logic Hook of type ā€˜before_saveā€™ for the custom module, so I can rewrite the contents of the field being posted there.
I report the code of the hook.

    class tkLogicHook
         {
             function saveNota($bean, $event, $arguments)
             {
               //Custom Logic
               $bean->nota=$_REQUEST['nota'];
             }
         }