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

HubSpot updates
Configurable Appearance of Richt-Text EditorsHubSpot Product Team
Oct 19, 2018

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 https://designers.hubspot.com/slack .

Configurable Appearance of Richt-Text EditorsHubSpot Product Team
changed to: In Planning
Apr 30, 2018

9 Replies
HubSpot Product Team
HubSpot Product Team
updated to: In Planning
 
arinker
Top Contributor

That's great!

arinker
Top Contributor

Any updates on this?

AJLaPorte_diagr Advisor | Platinum Partner
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:

sample-tinymce-extension.jpg

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
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 https://designers.hubspot.com/slack .

arinker
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

arinker
Top Contributor

Any updates on this @kleonard?

imdaniel
New Contributor

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

Hubmate
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 Smiley Happy