Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Feature request: A better Wysiwyg editor. #1801

Closed
hdijkema opened this issue Oct 5, 2020 · 10 comments
Closed

Feature request: A better Wysiwyg editor. #1801

hdijkema opened this issue Oct 5, 2020 · 10 comments

Comments

@hdijkema
Copy link

hdijkema commented Oct 5, 2020

The current editor is very limited compared to some good open source wysiwyg HTML editors available.

It is hard without the <> to get e.g. a good formatted table. And also more formatting tags are created then is necessary and they are not always good for the markup.

E.g.: https://github.com/tinymce/tinymce

Or is it already possible to replace 'summernote' with something else?

@yurikuzn
Copy link
Contributor

yurikuzn commented Oct 5, 2020

It's quite a lot of work to replace. We have some customization done for summernote.

@hdijkema
Copy link
Author

hdijkema commented Oct 5, 2020

Can you elaborate a littlebit on the customization?

@yurikuzn
Copy link
Contributor

yurikuzn commented Oct 6, 2020

Dialogs are customized to fit espocrm UI design, some custom buttons added: https://github.com/espocrm/espocrm/blob/master/client/src/views/fields/wysiwyg.js

EDIT 2024. Ever since we have added even more customizations. We cannot scrap it all and start from scratch. BTW I like our editor, it's simple and minimalistic what fits Espo.

@yurikuzn yurikuzn closed this as not planned Won't fix, can't repro, duplicate, stale Nov 7, 2022
@M0hamedSalem
Copy link

Are there any plans or intentions for this update soon?

@radek3911
Copy link

radek3911 commented Mar 31, 2024

Hello, if you are interested let me know. We have implemented a CK Editor 5 as Espo customization.

If advertising is allowed here feel free to contact me at info@autocrm.cz (if it is not please remove this comment)
image
image

Edit: But as Yuri mentioned it is quite complex task, and not exactly 100% replacement, summernote cannot be replaced on some parts of Espo - for example email, our customization does not support replacement for email editor, due to the nature of CK editor style handling.

@yurikuzn
Copy link
Contributor

yurikuzn commented Apr 1, 2024

Under the hood the editors are all the same contenteditable, there should not be any drastic difference with markup they produce. It's very unlikely that we change the editor any soon, instead we could improve the current one. But to be able to improve, we need to know what exactly issues are present, how to reproduce them and what exactly vital features are missing.

@radek3911
Copy link

Under the hood the editors are all the same contenteditable, there should not be any drastic difference with markup they produce. It's very unlikely that we change the editor any soon, instead we could improve the current one. But to be able to improve, we need to know what exactly issues are present, how to reproduce them and what exactly vital features are missing.

The CK editor we implemented was on-demand by client, because they wanted to make a nice knowledge base and needed the extra features of CK editor (better tables, font options etc.)

The summer note is not itself bad, but quite limited and the biggest flaw(feature) is formatting. We also had to implement Ace editor in combination with puppeteer PDF engine, because we weren't able to make good PDF templates, any custom styles got stripped by summernote and the only option was to fill the HTML in DB (until we implemented the ace editor) - I am not sure if "clean text" was an option at the time we implemented Ace.

But I can see that you are reworking this in 8.2.0 so probably the ace editor will be a built in option?

@yurikuzn
Copy link
Contributor

yurikuzn commented Apr 1, 2024

Could you provide an example of custom styles being stripped. If it strips, does any other Wysiwig not strip it? I assume any editor based on contenteditable will strip style tags.

Edit. Checked our code. We strip style tags on purpose, to prevent the page layout and style being affected by the field.

8.2.0 so probably the ace editor will be a built in option

Yes. Plus it's possible to specify styles (CSS) separately for PDF templates (only).

the biggest flaw(feature) is formatting.

What exactly is wrong with formatting? How other editors perform better here?

font options

What is meant by font options? Different fonts? I don't think we can support different fonts for both PDF and frontend. Anyway having different fonts on the same page is not good from the UI design point of view.

@radek3911
Copy link

Could you provide an example of custom styles being stripped. If it strips, does any other Wysiwig not strip it? I assume any editor based on contenteditable will strip style tags.

We had a problem mostly around PDF templates where we wanted to (for example) make a full HTML page (with <style> tags etc.). This was impossible in the summer note (or so I recall) so we implemented ace editor to edit HTML directly with syntax highlighting. It was around version 7.3 (and the clear text template option was also our customization so sorry for the misunderstanding), so when we wanted a complex template (usually invoice with complex layout and styling) we ran into issue where the styles and layout would get purged if we inserted it as code in the summernote. Which is of course intended behavior (for any other parts of the CRM - not to allow HTML because that is XSS) but for the goal of having complex PDF templates it was a "flaw".

Alongside ace editor we did implement the puppeteer PDF engine which worked great in comparison to Dom PDF. While using Dom PDF we also ran into other issues with the HTML rendering.

I just checked 8.2.0 demo, and I am not sure if we would still need to use ace editor for the template body, I tested it out with one of the template we are working on and when seperating the style and body into the wysiwig and style field the template completely broke (altough I beleive that was more likely caused by dompdf rather than wysiwig stripping it - need more time to test it)

Yes. Plus it's possible to specify styles (CSS) separately for PDF templates (only).

This is nice, I just tried it out and it seems to be working on demo.espocrm.com, however the template still turned "crooked" after printing (I am very positive that it's due to Dompdf through)

What exactly is wrong with formatting? How other editors perform better here?

The flaw I was referring to is stripping the custom styles, otherwise I don't see any issue (not exactly an issue for typical end-user)

What is meant by font options? Different fonts? I don't think we can support different fonts for both PDF and frontend. Anyway having different fonts on the same page is not good from the UI design point of view.

Yes, switching fonts as the client had a company wide font "branding rules", now that I think of it, we probably should have handled it differently - using just custom css for the entire espo crm instance. I don't exactly recall, why they wanted a different editor, but looking at the usage it seems to me that the table functions of CK editor (+ the fonts) and probably the more "intuitive UX" were the main points. CK editor has a lot more features for making tables in wysiwig and also a lot more plugins that can get added on demand.

I will test a bit more with PDF templates in 8.2.0 and get back to you, thank you for all your hard work.

@yurikuzn
Copy link
Contributor

yurikuzn commented Apr 1, 2024

stripping the custom styles,

Actually, we strip style tags on purpose, to prevent the page layout and style being affected by the field. It's not the editor.

Note that we can't embed any other PDF engines and ship them out of the box due licensing incompatibility. But PDF is offtopic.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants