Expose TinyMCE editor content manipulation APIs in Gutenberg

[pavelthq]

Please make sure that there is same api for setContent, getContent and getting the editor wrapper as in current version of tinymce.

Many compatibility issues can be solved if there will be same api for settings the content.

wp.tinymce.get('content').setContent('something').

[jaswrks]

Related: https://wordpress.org/support/topic/breaking-compatibility-api/

[danielbachhuber]

Hi @AngeIII,

Thanks for the report. Can you document what does and doesn't currently work?

[pavelthq]

@danielbachhuber Hello, I already wrote in ticket start:

• wp.tinymce.get('content') - getting the "Editor" instance
• wp.tinymce.get('content').setContent('customContent')

also, there was some twinks and abilities to show source/html mode API.

[danielbachhuber]

Related #6648

[gziolo]

@iseulde, what's your opinion on this one? I don't think we want to expose internal TinyMCE API for every RichText component. What would be the alternative?

[adamsilverstein]

I don't think we want to expose internal TinyMCE API for every RichText component.

Maybe not every API? Why not expose common TinyMCE API points like getContent and setContent which could be extremely useful/required for certain extension use cases?

[danielbachhuber]

Why not expose common TinyMCE API points like getContent and setContent which could be extremely useful/required for certain extension use cases?

And if we don't want to expose these directly, their equivalents would be just as helpful.

[simondowdles]

I feel that some of the important TinyMCE API points (like getContent and setContent as other have pointed out) should be a baseline requirement here.

We've experienced a bug when using custom formatters, where the value of the RichText component is not passed to the onChange event when content is pasted. This ultimately resulted in attributes that relied on the onChange callback to have their value(s) set, not receiving the expected value. (This is an issue I shall soon open)

I would like to believe that had we had the getContent API point exposed, we could have reverted to that and hopefully gotten the content we expected.

Furthermore, having the getContent and setContent API points exposed, we would not have to convert from a ReactDOM object to an HTML string (using renderToString() for example) had we had more native API's exposed. We'd also not have to rely on third party libraries to get HTML strings back into ReactDOM arrays when setting the (HTML) value of a RichText component from an attribute that may have been saved as a string value.

[ellatrix]

The shape of the content of RichText is being revised in #7890. That PR will hopefully partly address the issues mentioned here.

Please make sure that there is same api for setContent, getContent and getting the editor wrapper as in current version of tinymce.

Could you elaborate on what you need those for? In what way are you trying to extend the editor. Maybe with that knowledge we can provide more suitable APIs.

[aaronjorbin]

This may be completed after #7890, milestoning to make sure it is

[ellatrix]

#3688 (comment) would need a reply in order to know what is needed.

[danielbachhuber]

@iseulde I documented some TinyMCE API usage in #6648

[gziolo]

By the way, @iseulde proposed Formatting API which is going to play a role of TinyMCE editor content manipulation APIs in Gutenberg. Let's close this issue, and move the discussion to #10068 to ensure that all requirements shared above are included in the final version.

[gziolo]

We have just landed Format API with #10068. It allows registering any format you need. We are still working on a way to give better control which control can be displayed for a given block and documentation. It should be all ready early next week.