Page 1 of 1
Bug: Large content in WYSIWYG Editor breaks DB Query + "Solution"
Posted: Thu Jun 03, 2021 10:18 pm
by DReffects
Script URL: admin_ticket.php
Version of script: 3.2.2
Hosting company: selfhosted
I've played around with the KB Feature and found it very helpful to have images in a KB article. Since I want them inline I frequently use copy/paste to directly insert images (from the windows snipping tool for example) into the RTE editor.
At a certain point this will break the INSERT query into the database when submitting a KB article or ticket since the html code gets too big.
Reason: the database field is set to MEDIUMTEXT which has a data limit of 16MB.
Solution: changed the field property to LONGTEXT in phpmyadmin (LONGTEXT supports up to 4GB)
Suggestion: change the field protperty to LONGTEXT / implement a Copy/Paste mechanic into the RTE that creates file attachments out of pasted binary data. (No clue how this works but community software "Invisionpower" has such a feature. Please take a look at:
https://invisioncommunity.com/)
Re: Bug: Large content in WYSIWYG Editor breaks DB Query + "Solution"
Posted: Fri Jun 04, 2021 11:50 am
by Klemen
Thanks for the heads up. Yeah, I thought MEDIUMTEXT would be large enough (estimated 1million+ words) but I can see how embedding several images can go through that easily.
Because all the article contents are indexed (for fulltext search) my recommendation would be to link to images rather than embedding them directly. We will look into automating this in the future as you suggested, but no promises when.
Re: Bug: Large content in WYSIWYG Editor breaks DB Query + "Solution"
Posted: Fri Jun 04, 2021 3:23 pm
by DReffects
The 16MB of LONGTEXT are basically filled when copy/pasting a 4K image
Thank you for the fulltext search info. This indeed would make things very slow for huge databases. I've just looked through the TimyMCE documentation, they infact support the "upload BLOB Data when pasting" via the "automatic_uploads" flag:
https://www.tiny.cloud/docs/configure/f ... ge-upload/
Code: Select all
tinymce.init({
selector: 'textarea', // change this value according to your HTML
images_upload_url: 'postAcceptor.php',
automatic_uploads: false
});
I think this would be a great addition to HESK, as for IT Support you constantly need screenshots from customers and going through a 'classic' upload form overwhelms your stupid end user
WYSIWYG for customers with image upload would be a great addition of course
I also use copy/paste images for tutorials like "How to setup your mail in outlook" which needs a step by step guide with basically images and a bit of explanation after each screenshot.
You can find a server-side upload handler for tinymce here:
https://www.tiny.cloud/docs-4x/advanced ... d-handler/
Edit: I've got a working proof of concept for my installation works really well atm. If you'r interested I'll round up some details.
Re: Bug: Large content in WYSIWYG Editor breaks DB Query + "Solution"
Posted: Sat Jun 05, 2021 12:28 pm
by Klemen
Sure thing, please feel free to share. You can reach me at kstirn at hesk dot com.
Re: Bug: Large content in WYSIWYG Editor breaks DB Query + "Solution"
Posted: Mon Jan 06, 2025 1:43 pm
by morphisto.zet
Hi there,
we were running into the same problem. We have many articles in our knowledgebase with photos. There are arictles with over 30 photos and the blob embedded image isn't very good. Our MariaDB ist nearly 1 GB right now, thanks to this implementation.
@Klemen do you have a rough idea, when HESK will upload images as a file to the server instead of storing it as a blob in the db? For tickets this behaviour is absolutly fine, but not for the knowledgebase.
thx
mz
Re: Bug: Large content in WYSIWYG Editor breaks DB Query + "Solution"
Posted: Mon Jan 06, 2025 5:03 pm
by Klemen
Copying images directly into the DB is indeed a bad idea, something I never recommended.
What I recommend is having all the images you use in KB stored somewhere on your server, and link to them using the img src parameter.
An auto-upload file is currently not in the near-term development plans so I'm afraid I don't have a date to share.