Error when saving long text in richeditor fields

[KevinReina]

When you have a lot of data and is using repeater-fields with rich editors and is also copy pasting images, it will surpass the amount of data the attribute "attribute_data" can hold. This is because the attribute data has a type of "mediumtext". (in rainlab_transte_attributes)

Change Proposal(s)

• change attribute type of "attribute_data" in rainlab_translate_attributes to "longtext"
• let the rich editor upload the images to storage instead of converting to base64

To recreate this scenario 1.create a form with repeater fields with rich editors and let it be translatable

2. copy-paste a few images instead of uploading
3. also paste lorem ipsum text, eventually, this will surpass the mediumtext limit

When it surpasses the limit, there are no closing brackets and October does not know how to process the data and it will seem empty.

[LukeTowers]

Personally in my mind needed to store ~4 GB of data in attribute_data is a bit much, 16 MB as provided by MEDIUMTEXT should be enough in most use cases.

also paste lorem ipsum text, eventually, this will surpass the mediumtext limit

It would take 36,873 copied and pasted instances of the standard lorem ipsum text to reach that limit:

Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum.

How would you suggest implementing the richeditor upload-on-paste functionality?

[KevinReina]

yes it is too much but clients keep pasting images instead of first uploading, i had 5 images and from word and it almost filled attribute_data.

Maybe we can look into this for upload-on-paste? https://wysiwyg-editor.froala.help/hc/en-us/articles/115000555949-Can-I-insert-images-as-base64-

using the image.beforeUpload event to get the image and store it in october's mediamanager in a folder called upload-data ?

[LukeTowers]

@KevinReina perhaps, although we'd need to make the storage location of such unprompted uploads configurable by the developer. A PR to octobercms/october would be welcome.

[Denoder]

I tried the base64 way. The load ended up being too great for the editor.

[mjauvin]

I think we should either just add a check on the uploaded size here, and send an error to the user if it exceeds current medium text capacity. What do you think @LukeTowers ?

[LukeTowers]

Ultimately the best solution would be to auto upload pasted images instead of inlining them; at least in my opinion. Any input @bennothommo?

[bennothommo]

I agree with @LukeTowers. It shouldn't be encoded in the content as that would result in easily breaching the size limit - it should instead be processed and uploaded using the normal file attachments means. Froala supports an imagePaste and imagePasteProcess option which might be worth looking into to allow handling of image uploads from the paste action.

[mjauvin]

I suggest setting Froala's imagePaste option to false in the MLRichEditor formwidget in order to prevent the problem from happening.

I submitted a PR to allow setting this when using the RichEditor formwidget. See https://github.com/octobercms/october/pull/4990

[mjauvin]

@bennothommo I tried an event handler for Froala's image.beforePasteUpload event as shown below, but no matter what I try, the image is still pasted in the editor:

this.$textarea.on('froalaEditor.image.beforePasteUpload', function (e, editor, img) {
   alert('hello world!');
   e.preventDefault();
   return false;
});

The "hello world!" alert displays when pasting the image, so I know the function gets executed.

The doc says if one returns false from the handler, the event should be cancelled, but apparently this is not working. If I could see how this is coded in Froala, that would help, but since it's closed source, I cannot...

[bennothommo]

@mjauvin you'll need to ask @daftspunk if he can investigate the source code as to the workings of the event.

[mjauvin]

@daftspunk can you investigate this in Froala?

[LukeTowers]

@mjauvin does the return false work if you assign the event the way it's mentioned in the Froala docs, attaching the listener in the initialization of the editor.

[mjauvin]

couldn't make this work

[daftspunk]

Had a look at this and you may need to convert attribute_data to large text, which is capable of supporting a larger value. It will most likely impact performance but will solve the problem as a workaround safely.