A plea for the option of ‘Builder only’ email editing in Mautic 2

We have used Mautic for nearly a year for our agency promotions and have been considering offering it as a platform for clients. Unfortunately, the introduction of the Froala Editor in 2.0 has caused issues which impact the creation of consistently well formatted emails and make us question if we can continue with Mautic.



While I’m sure many of the teething problems with Froala will be overcome I have concluded that for us it’s use is fundamentally flawed. Using the editor can only result in emails that do not contain the code necessary to preserve their intended appearance on a sufficiently wide range of email clients.



Our own responsive email templates have been modified from proven examples and tested exhaustively using Litmus to maintain their appearance on as wide a selection of email clients as possible. As always with html email this results in files that are littered with odd workarounds and code that a standard editor will find unorthodox.



Currently Froala will remove many of our code elements and add its own code the moment an email is created. This immediately compromises the integrity of our carefully crafted code.



Should the email be edited further any code added using the visual editor will have the standard html that Froala inserts and will be unlikely to include an refinements necessary to make sure it renders well in Outlook 2007, Yahoo Mail! etc. etc.



Even if Froala could be made to respect the integrity of the provided template it is inevitable that using Froala to modify almost any element will result less than optimal code.



I cannot therefore see how we can use Mautic successfully with Froala on our own work or as a service to clients who expect consistent delivery of content to a wide range of email clients.



Can I plea for at least the option to return to the exclusive use of the Builder. The Builder mechanism allowed tightly defined editable areas within a template and was very successful. With Builder providing the only editing interface the integrity of the template was preserved and users were not given the opportunity to break carefully constructed code.



Do other Mautic users share our concerns?

@coh998 , yes it’s frustrating, I had suggested the sql update solution, may be you came across on one of my workaround posts, if not, there’s an easy way to use load_file that makes the process a bit easier directly from your html…

update pages set custom_html=load_file('landingpage.html') where id={your-page-id};

Suggestions about fixing the code doesn’t apply, froala on git is minified, changing the mautic code is no easy task. Besides edit issues, we had designed templates that became useless with froala. Also froala is not offered on GPL, I believe it’s on a OEM license mautic currently has. In any case, we’re planning on going back to ckeditor, there was nothing wrong with it.

I agree there should be some consensus from community when making such big-impact changes, it’s hard to implement it though.

The builder does not work for me at all. Dragging is not working. The froala editor is not the best one (used the resize images) but it works fine and the HTML view makes it easy to correct mistakes.

I agree with MxyzptlkFishStix. It is open source, if you really need it, build it and support the community in making Mautic a better product. Or collect enough votes so that Mautic community will pick it up and build it for you.

An “editor” that rewrites your carefully crafted code without permission is hardly worthy of the name.

Now that we are aware of this very serious issue that impacts directly upon the ability to write responsive emails and to have them display as written, the only question should be how to fix it. ASAP! “Live with it or fix it yourself” is not an admirable response, mainly because most of us are not capable of fixing it ourselves.

code view should not be subject to any unannounced rewrite at all. It mainly exists to allow the fixing of goofy wysiwyg code that results from drag and drop editors. Now the wysiwyg editor is [i]overwriting[/i] the editor?! What fresh hell is this?!

We just need a switch to turn it off. And it should be a priority. The email content, and it’s precise formatting, are the most important thing in an email marketing app. No…?

Thank you.

… hardly worthy of the name.
“Live with it or fix it yourself” is not an admirable response…
What fresh hell is this?!
And it should be a priority.

While I’m impressed with the gall of your demands of the individuals who make this [amazing] FREE tool, I might suggest that learning to fix it yourself could be quicker than waiting for a fix from the developers, e.g. learning some HTML in an hour or less.

I have to agree that every profesional Marketing Automation tool has the option to put in/upload your own HTML code/e-mail template. Reason being the above problems that occur when using the Froala source editor and placing here your own HTML code.

If Mautic wants to become a real competitor for paied MA systems this has to become a standard feature, otherwise it will be hard to let them consider Mautic.

“While I’m impressed with the gall of your demands of the individuals who make this [amazing] FREE tool, I might suggest that learning to fix it yourself could be quicker than waiting for a fix from the developers, e.g. learning some HTML in an hour or less.”

I’m not making demands, I’m stating informed opinions. Whatever. I’m not interested in your pissin’ contest.

For what it’s worth, tough guy, I do know how to fix my code. I just don’t know how to fix the thing that keeps screwing it up! Why should I put up with that without complaint or notification to the devs? Got any useful suggestions? Any workarounds? Is there a way to disable that editor module or disable it’s code stripping function?

Something other than pasting my code directly into the MySql tables…? Which is what I’m doing now…

And by the way, it’s not Free! I have a lot of time invested in tracking down this infuriating bug and notifying the developers.

You’re welcome.

Ok, Ok everyone no need for any arguments. I think the whole point of this thread is really to ask the devs for the option to turn off the editor. Why? Because it is a third party editor that for many of us causes more trouble than it is worth. I do understand however, the reason for having it, that being that many many users prefer a drag and drop interface to hand coding or other means of building emails.

So can we have a constructive conversation?

I agree and apologize for my part in making the tone less than pleasant.

I’d much rather a discussion on workable methods to get around this issue. More than a few of us are generating and inlining our responsive email code outside Mautic, and we’d just like a way to integrate that code into the messaging workflow and not have it be rewritten without warning or permission. As I said, the only method I’ve found so far is to paste my code into the sql table directly, completely bypassing the offending editor. That’s one clunky method; are there any others we might like to know about while waiting for the developers to come up with a built-in solution?

For those that worship at the altar of responsive email—I know we are but a minority, for now—and those others who are merely fussy about their code not being tampered with, this is a potential showstopper. I would have pulled the plug on this entire project if I hadn’t found the “paste into sql table directly” workaround. And I found that suggestion in a different, equally contentious and argumentative thread elsewhere on this same subject

It seems that there is significant disagreement on how big a problem this is; I’d like to see less criticism of those who know it’s a problem by those who think it isn’t, and more discussion by all on how many ways there may be to get it fixed.

Respectfully,

Thank you.

We have used Mautic for nearly a year for our agency promotions and have been considering offering it as a platform for clients. Unfortunately, the introduction of the Froala Editor in 2.0 has caused issues which impact the creation of consistently well formatted emails and make us question if we can continue with Mautic.

While I’m sure many of the teething problems with Froala will be overcome I have concluded that for us it’s use is fundamentally flawed. Using the editor can only result in emails that do not contain the code necessary to preserve their intended appearance on a sufficiently wide range of email clients.

Our own responsive email templates have been modified from proven examples and tested exhaustively using Litmus to maintain their appearance on as wide a selection of email clients as possible. As always with html email this results in files that are littered with odd workarounds and code that a standard editor will find unorthodox.

Currently Froala will remove many of our code elements and add its own code the moment an email is created. This immediately compromises the integrity of our carefully crafted code.

Should the email be edited further any code added using the visual editor will have the standard html that Froala inserts and will be unlikely to include an refinements necessary to make sure it renders well in Outlook 2007, Yahoo Mail! etc. etc.

Even if Froala could be made to respect the integrity of the provided template it is inevitable that using Froala to modify almost any element will result less than optimal code.

I cannot therefore see how we can use Mautic successfully with Froala on our own work or as a service to clients who expect consistent delivery of content to a wide range of email clients.

Can I plea for at least the option to return to the exclusive use of the Builder. The Builder mechanism allowed tightly defined editable areas within a template and was very successful. With Builder providing the only editing interface the integrity of the template was preserved and users were not given the opportunity to break carefully constructed code.

Do other Mautic users share our concerns?

+1

+1

@MxyzptlkFishStix telling someone to go build their own isnt really helpful.

I believe what is being asked is for the option to turn off Froala. I agree with him, for professionals Froala destroys what we have spent so much time formatting. On the flip side for average users Froala makes it easy for them to build decent emails without all the technicalities.

So the solution is simply an option in the settings to turn it on or off.

+1

I used to create the pretty emails, and since have learned from marketing pro’s like Perry Marshall and others, that text only emails receive much higher open rates. So I’ve tested myself, and so far… yeah. Hell yeah. So the option to turn off any type of graphical stuff would be fine with me. I’m currently choosing the plain template, going to code view, and doing it there.

I hesitated before revisiting this surprisingly devisive thread but after several hours weeding out
tags automatically inserted between table rows and other Froala oddities in an email in 2.2…

I still strongly believe that Mautic needs to offer an alternative to using the Froala editor for emails. This could be a simple config switch to turn the editor off when required.

For the majority of clients with whom I work it is important that…

  1. The integrity of the code in email templates which has been tested extensively (and expensively) against a wide range of email clients is preserved. Froala simply isn’t able to work this way.

  2. Clients have an editing interface that doesn’t require html/developer skills. Asking most end users to work with a complex html editor like Froala will cause them frustration and cause unecessary support time. Builder used to provide a quick, user friendly and tightly controlled editing environment but now seems to function only partially and is still subject to code changes imposed by Froala.

Mautic is fantastic, I’m hugely impressed with the rate of progress and I’m very grateful to have access to an open source MA solution. My feed back here is as a designer/marketer who has been putting stuff into html tables since 1997 and sitting in front of difficult clients explaining why things can’t look exactly as they wish for even longer.

If Mautic can address the two points above it can only help adoption of the product to the benefit of the project and members of the community who face similar issues.

If anyone has similar concerns it would be great if you can make them known here. It would also be interesting to hear from the Mautic team on this issue?

+1
That editor is awful.
It garbles the most to-the-point, clean html.

Editors should not be a prerequisite, but an option.

I’m now more than delighted to discover that there is an imminent solution to this problem.

https://github.com/mautic/mautic/pull/2653

Many thanks to the Mautic team for recognising and addressing this issue.

Unfortunatley the PR mention by katalysis did not make it into 2.2.1 (although it was added to 2.2.1 some days ago, but oviously removed). There is a bit of a progress though in 2.2.1 (image size, no borders anymore), but in the end a clean html editor would be the best. Keep fingers crossed for 2.3.

P.S.: A possible workaround is to enter the HTML code directly into the database. But be sure then not to open the email again in Mautic! This works for me, althoug it isn’t very nice… And not possible for everybody.