Let's make the builder much better (incl. GrapesJS and ckeditor)!

Ideas and Feature Requests
1

Email is THE number one important feature in Mautic, yet not the best or most beloved one.

Status quo:

  • Most users find the current builder very limited (same even say ugly words about it ; )
  • Some larger organizations swap it out and user other builders
  • Some frustrated users prefer to build externally & just paste the source code into Mautic.

This has to change.
General options:

  1. get rid of GrapesJS altogether
  2. keep GrapesJS but swap out ckeditor
  3. stick with GrapesJS and ckeditor but make it much better.

My personal preference would be #3 because I feel that yet another change of horses would create even more frustration, and not necessarily trust in whatever comes next.
I also believe that ckeditor is not the root cause for most issues even if it seems to be. Also I am not convinced that another editor (especially a free one) can give us the same value. In the end: There were good reasons behind making that choice.

Therefore, we are currently testing the waters for “3. stick with GrapesJS and ckeditor but make it much better”.
And to do that, I’d appreciate all the input we can get. Items we identified or received so far (intentionally unsorted):

  • Inheritance: Content from GrapesJS blocks has to use the theme’s styling, currently it frequently doesn’t
  • Copy & Paste between email instances (solved, I believe)
  • “Save email as theme” feature
  • If i click outside of the ckeditor modal window, that discards my changes (solved, I believe)
  • Confusion between per-character font styling (ckeditor) and per-element font styling (GrapsJS) → Idea: Prevent per-element font styling for ckeditor elements
  • Fully support dynamic content
  • Fully support tokens incl. forms
  • Support MJML emails through API
  • Simple vs. expert mode
  • “Table” element
  • Control ckeditor font choices from Theme
  • Allow changing of link color
  • Paragraphs are added by editor after saving email (issues with headlines, also: creates isolated elements even for empty lines, impossible to maintain afterwards)
  • GrapesJs is still moving inline CSS to style tags #11934
  • Code Editor in Landing Pages Duplicates Content into the Section #14409 (PR exists: fix(code-editor): prevent head duplication, remove empty < p >, confirm before discard (fixes #14409) #15398
  • When I have a draft in some email, an create a fresh one, I am suggested to restore from that draft
  • Inline ckeditor instead of modal window

Please help us out by adding your observations (bugs, UI flaws, bad code results, missing features, existing solutions, …) here!

1 Like
2
  • Avoid “stuff” from copy&paste e.g. from Word (format-free paste, or even whitelist-based paste)
  • Documented way to strip down the ckeditor options in a Mautic instance (remove icons that are undesired)
  • verify healthiness and future of GrapesJS builder Open Source project
  • allow adding GrapesJS blocks through themes
1 Like
3

Very intresting suggestion @ekke!

Ruth has already explained that once the marketplace is released, new 3rd party builders developed by the community will become available. Although that’s not the ideal solution, some of my clients rely heavily on GrapeJS, even though they share the same concerns has you mentioned.

Avoid “stuff” from copy&paste e.g. from Word (format-free paste, or even whitelist-based paste)

This is extremely important to address and remains a common issue we all face!

I believe that replacing the builder entirely is something that will need to be considered in the future, as the current one often discourages new users due to its learning curve.

There is one more point I would add to your suggestion, something I find very useful:
Giving email/landing page themes the ability to include pre-made blocks. When users drag and drop the standard elements, such as buttons, they don’t have the same visual style of the theme.

"Theme" section containing custom blocks from the theme
"Theme" section containing custom blocks from the theme766Ă—436 40.2 KB

1 Like
4

True… In fact there is a (stale) PR for that: FEATURE: Adds functionality to extend GrapesJS editor via themes by putzwasser · Pull Request #13002 · mautic/mautic · GitHub but I never looked into it, to even understand how it works…
→ Putting it on the list :slight_smile:

1 Like
6

Also add the ckeditor or similar AI assistant

  • spellfix
  • summarise / elaborate
  • translate
  • fix tone of voice
    in the ckeditor

I’m not sure if everyone wants this but just puttig out the idea:

perhaps importing content from remote sources (like the popular questions about the RSS plugin)
or similar by default in GrapesJs

7

Oh and I recently saw a powerful feature in another marketing automation platform:
Generate a template with AI.
What kind of email do you want to send [ input field]
This then generates a template based on a pre-existing set of templates but tailored to your description.

What other tools are doing:
inspiration:

8

Hello,

If you look in the Ideas section, you’ll see that I’ve already proposed several ways to improve the Mautic email builder, but unfortunately they haven’t gained much traction — which is a shame.

Here is my revised idea:

For those running Mautic at scale on servers that are already heavily loaded, creating and building emails directly inside Mautic can be painfully slow. Anyone who has tried to use the email builder on a busy server knows how frustrating the experience can be.

So why not take the email builder out of Mautic entirely and turn it into a standalone tool?

A standalone email-building application could evolve at its own pace, independently of the Mautic core. It would allow users to create, open, and store email designs as separate files, and once a design is finished, it could be imported back into Mautic using a simple import feature.

GrapesJS would be an excellent foundation for such a standalone builder. It’s proven, flexible, and already widely used for email and page design. By building the standalone builder on top of GrapesJS:

  • Mautic would no longer need to maintain a heavy, integrated builder
  • Designers would have a fast, dedicated environment that isn’t affected by server performance
  • The builder could evolve more quickly and remain fully decoupled from Mautic’s release cycle

Additional advantages:

  • Teams of designers could work without putting any extra load on production Mautic servers.
  • No need to maintain a separate Mautic instance purely for design work.
  • The standalone builder could be lightweight and optimised specifically for design.
  • Existing MJML workflows or third-party tools could be integrated instead of reinventing the wheel.
  • Templates would become file-based, making them easy to import into any Mautic instance.
  • This could even support a marketplace where designers sell templates to the community.

Another important point: Mautic needs the ability to disable or soften the email code sanitiser.
Right now it is far too restrictive and often strips out essential code required for modern, responsive layouts. If users are importing trusted templates from a standalone builder, they should be able to bypass the sanitiser entirely or control it selectively.

This is similar to my current workflow — I hand-code templates and can produce them quickly — but a proper standalone builder would make this possible for everyone.

I may still build my own tool eventually independent of any standalone GrapesJS tool (likely in C or C++ which is ideally suited to code creation), but it would be fantastic if Mautic provided a clean, simple import mechanism rather than what we currently have in M6.

Thanks for considering this idea!