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 (incl. tokens), also for emails
  • Fully support tokens incl. forms
  • Sort token list
  • Search in tokens
  • Support MJML emails through API
  • Simple vs. expert mode
  • “Table” element for MJML, and for HTML / Landing Pages
  • 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
  • link property “disable link tracking” in ckeditor
  • Dynamic Content - Copying Dynamic Content is not working (as intended) #15214
  • Dynamic Content - Elements always come with default padding thats not removable in the builder #15209
  • Dynamic Content - Deletion of filters is broken #15205
  • 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 PR #13002
  • do not require doubleclick to invoke creditor → not doing this, it is intentional tradeoff behavior of GrapesJS

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

2 Likes
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

3 Likes
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!

3 Likes
9

Thanks @woutersf !
I’ll take the AI-related ideas to the AI initiative (namely Lukas who is leading the effort) who obviously have such things on their list, and coordinate where to best push this forward. (I saw you already contributed big time in Slack #wg-ai :star_struck:)

About

importing content from remote sources (like the popular questions about the RSS plugin)

→ Sounds great! Would you care to elaborate on this idea? I could image online sources like RSS, maybe manual “uploads”,… but we should start by figuring out what the most valuable things would be for users, imho. (NOT looking at Mautic implementation or UI at this point)

10

That seems to have 3 aspects:

  1. see above: “allow adding GrapesJS blocks through themes”

  2. “allow adding GrapesJS blocks through plugins” → We already have that

  3. “When users drag and drop the standard elements, such as buttons, they don’t have the same visual style of the theme.” → That should be covered by “Inheritance: Content from GrapesJS blocks has to use the theme’s styling, currently it frequently doesn’t”

Agreed @ricfreire ?

1 Like
11

@ekke exactly yes, that would be the ideal scenario: for the builder to inherit the template elements so that whenever a user adds a new block, it automatically comes with the proper styling. The challenge is that some templates include multiple button styles, text variations, etc.., and I don’t see an easy solution for handling that.

What we have done so far, and we can already share the code as shown, is create a blocks.json file inside the email template. In that file, we include the block details - label, code, icon - we want to appear in the builder.

Template blocks.json
Template blocks.json1328×694 27.7 KB

Template custom blocks via template
Template custom blocks via template766×436 40.2 KB

Credits to Sebastian for developing this!

12

Good artists copy, great artists steal. – Steve Jobs

In this case, steal the email editor technology the Monkey :monkey: uses. If you can emulate that, you have a familiar system for new Mautic users to be automatically accustomed to. Also, you won’t have to worry about 3rd-party updates to a crucial part of the system. While you are doing this, please also add AI capabilities with API connections to the standard popular LLM options.

It would be wild if you could enable email templates and generative image creation.

13

Just add my 2 cents to this list of issues - here are my issues from the Prague sprint: