I’m in the process of updating JS dependencies of Mautic and I found that we are still loading the Froala editor. This WYSIWYG editor was replaced with CK editor 2 years ago:
But it was kept in the code as it’s used in the legacy email and page builder that was in use before the GrapeJS editor.
The main problem with Froala editor is that we are not able to update it. We used to have a deal with the authors of this editor that we can use it in the open source project but this is no longer the case so we are not able to get updated version and cannot ensure security patches.
So I’m wondering if we can remove the legacy builder together with the Froala editor in Mautic 5.
I know for a fact that some companies are still using the old builder, since they have invested some time and money to build themes.
That said…
The cost of migrating any custom emails is usually low, so I think it could be removed without any major negative impact.
Plus, what are the options/alternatives @escopecz?
Like @Norman Pracht said in Slack:
If we have to consider removing it, then I would rather go for a Community survey to be sure if it used or not (we could use this process anytime we have the question).
We count with remove the legacy builder in the next major release. Probably the best way would get back Code Mode editor and migrate all legacy builder content to Code Mode. We knows some HTML content from legacy builder is broken in Grapes JS, email and page as well.
The Code Mode builder was removed and I don’t yet understand why. But if we’ll be able to get it back and open emails and pages that do not support the new builder in the Code Mode builder then the users will have a way to edit old emails and pages.
How do I do that? I thought that Norman meant a Forum post similar to this one where we can see the community members react. Is there such a thing as Community survey? If so, can someone help me set it up and put it in front of the wider audience?
Oh!, sorry, I thought it was a “thing” already.
Let me talk to @rcheesley, see if we can define “Community survey” and also get it done for you.
We will just need the text for the question (I guess the same as you already posted initially on Slack) and we will run it for you and get back to you with the response.
Am I wrong by saying that the integration of the new CKEditor (GrapeJS) has many bugs?
I mean, one bug that I was facing many times was that the email content was not saved, even if I clicked Save. By opening the email again, my last changes were not there.
It was Mautic 4.2.something, installed on VPS, with php 7.4.something and MySQL 10.3… .
There were some other bugs too (the link attribute in emails: mautic:disable-tracking=“true” did not work either - it was removed every time by the editor), and I decided to change to classic editor.
Unfortunately, the classic editor is also not bug free and I am not as happy as I wished. Still, the emails are all saved, and this I find very important.
I do not have a solution. I am willing to test again the CKEditor, to proof if the saving problem is still there.
That’s exactly the reason why I’m asking. I haven’t used the GrapeJS builder much myself. I know that some features like dynamic content or gated video weren’t built in. Maybe they are now. I appreciate any feedback from the marketers actually using it. If a substantial part of users are still using the legacy builder then we should keep it in M5 too.
I have many questions open regarding the actual editors:
what are the specifications? what should [the editor in Mautic] can? Are the specifications anywhere defined?
if first point is clear, are defined what are the main criteria for an [editor for Mautic] to be chosen.
According to Froala license, it is not allowed the editor to be used in open source projects. So there is no need to contact Froala. This means… no Froala anymore, but GrapesJS.
PS: CKEditor is the most used open-source HTML-Editor according to GitHub.
We use the grapejs builder with ckeditor. It was a bit of a hassle when we upgraded from v3 to v4. There was some copy paste bug that popped up and a couple other bugs. Let me find our PR for it to see what changes we made and I could perhaps get a PR in for it on v5.
I just had a look at our PR, there is a lot of changes, 13 files in total all in the GrapesJsBundle. @escopecz I can push up a PR for you to take a look if you like?
@escopecz I only now stumbled upon this topic… First of all: Has there been a resolution to your original question already?
My 0,02$:
I can confirm that there is serious usage out there of the legacy builder
And yes, we should force them over eventually - we cannot carry that legacy with us forever
This would indeed require the GrapesJS builder to work sufficiently well
Also, a much longer notice would be the professional way to go
Thus, suggestion:
We try to find a solution for using Froala another bit. Maybe with crowdfunding from those who desire using it.
With the release of M5 we clearly state that this is the last version to support the legacy builder.
If all goes wrong, another option would be to offer the Legacy builder as a paid add-on for those who still need it. This way we ensure funding of the license (and the effort involved) and maybe even earn some money for the good cause.
Licensing. AFAIK David purchased the OEM license as it allowed us to use it in an open source project. They no longer provide this option but it’s visible here: Pricing Plans | WYSIWYG HTML Editor | Froala
This basically means we are stuck with the very old Froala version and the bad news is that it has several known vulnerabilities: froala-editor 2.4.2 vulnerabilities | Snyk
So basically if we want to still have it in Mautic 5 core then we agree with having security vulnerabilities there.
So I think we should move it out of the core for M5 and make a plugin out of it. However, that would require resources that we don’t have (if anyone wants to get their hands dirty and get this done, please do!). So the next best option is to at least stop loading the Froala editor assets if the GrapeJS plugin is enabled. Since it is enabled by default we ensure that the security vulnerabilities are not present in fresh Mautic installation.
Of course the best option would be to improve the GrapeJS builder so it’s a no-brainer that that’s the builder to use so we can remove the legacy builder completely. It seems that’s not an option for M5. Hopefully we’ll get there for M6.
would the PR be good for 4.x ? I am not sure how many people are running on 5 in production at the moment. if so would be happy to look at the draft and try it out
ok, do you think loading those assets could trigger something bad? Afterall, all vulnerabilities seem to be XSS and thus only apply in situations where an editor is actually using Froala, no?
So maybe all we need to do is communicate well - like putting a red sticker into the legacy builder that says “This is insecure, please switch to GrapesJS”
And I like the external plugin idea a lot, maybe THAT could be combined with a paid license (paid to Froala, but also paid by the users). Still there would have to be enough serious interest in that, and someone willing to do it.
