Configurable Appearance of Richt-Text Editors

The usage of the richt-text-editor is one the most error prone links in the chain of beautiful content production.


Blog editors and content creators break unwillingly the intended design of a page or blog post by using freely the tools of the rich-text-editor (TinyMCE). Mostly they are not able to control the richt-text-content behaviour in source code. Thus it would be really helpful to allow template & module designers to control the available tools of a richt-text-field.


Bildschirmfoto 2018-03-02 um 19.08.29.png   Bildschirmfoto 2018-03-02 um 19.10.27.png

10 Replies
Status updated to: In Planning
HubSpot Product Team
Top Contributor

That's great!

Top Contributor

Any updates on this?

Advisor | Platinum Partner

@arinker and @kleonard we've been discussing this in the developer slack channel a bit. Here is an example of how I can see this working.

There is currently a Beta for Design Manager v2 with a settings panel. If we added the TinyMCE options to this, we could have something similar to this below:


Essentially, you would be providing the default initialization of the TinyMCE editor in there that can then be extended by the developers under the assumption anything they do inside of this may cause the editor to break and not be HS' responsibility at that point. You can even add in a "reset to default" link that would clear away any changes made to the TinyMCE code and restore it to the default. This would allow us to be able to not only remove features but also add in additional features depending on the plugins HS uses with the editor. Maybe even add in a plugins JS selector in later phases. 




HubSpot Product Team

Hey @arinker@AJLaPorte_diagr really appreciate the details here. It's something we're actively thinking about but nothing's quite set in stone.


I'm curious if this is something you'd prefer to control on a per-field basis (say, some flags in the code of a rich text field type snippet in a custom module) or something more global (like something that you could change upon cloning the default rich text module to a custom module). A setting that would be global across all instances of rich text editing strikes me as the more potentially dangerous approach here, as it would be difficult to reconcile multiple content types and subsequently multiple types of users that may be using the WYSIWYG in some form or another.


The concept of "plugins" is pretty interesting to a handful of us at HS, too. I'd love to hear more about that from both of you-- either here or you could find me in our slack community .

Top Contributor

Hi @kleonard,


control on a per field basis would be awesome. That way developers could enforce the intented content of any given field in a module. A global setting as described by @AJLaPorte_diagr would be sufficient as well. Do you have already a timeframe for a possible implementation?


Best Arno

Top Contributor

Any updates on this @kleonard?

New Contributor

This functionality would be very useful for my team as well. Curious what the status is on this.

Regular Contributor

Hi @kleonard Hope you're well.


Just wondering if this got any further in production? As someone building modules and templates all day for as long as I can remember, I think this would be the most useful update I could hope for.


Steve 🙂

Status updated to: Delivered
HubSpot Employee

Hey Everyone! Good News! You now have the ability to configure the rich text editor toolbar when creating modules in local development (through your fields.json file) using a new enabled_features property. You can learn more about this at the resources below:

If you have any additional questions, please feel free to hop over to our community post that discusses the launch of this feature here: