You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
To my understanding we have the nice possibility to create many CKEditor presets where you can explicitly fine grade what you need. I often have multiple presets with complete different use cases and very different configs to support the backend editor as much as it is possible. With your approach the adoptions are made ALWAYS, no matter how the preset is configured. This often makes sense in smaller TYPO3 projects, but not for enterprise.
So, what do you think about adding at least an extension configuration setting which can be used to disable the default injection of your extension related CKEditor preset adoptions?
I really would like to discuss this on your implementation. Let's find some way to have an example implementation of the used event listener. We can add examples in the rte_ckeditor documentation afterwards too.
@benjaminkott, what are your backgrounds to the currently implemented approach?
The text was updated successfully, but these errors were encountered:
To my understanding we have the nice possibility to create many CKEditor presets where you can explicitly fine grade what you need. I often have multiple presets with complete different use cases and very different configs to support the backend editor as much as it is possible. With your approach the adoptions are made ALWAYS, no matter how the preset is configured. This often makes sense in smaller TYPO3 projects, but not for enterprise.
So, what do you think about adding at least an extension configuration setting which can be used to disable the default injection of your extension related CKEditor preset adoptions?
I really would like to discuss this on your implementation. Let's find some way to have an example implementation of the used event listener. We can add examples in the rte_ckeditor documentation afterwards too.
@benjaminkott, what are your backgrounds to the currently implemented approach?
The text was updated successfully, but these errors were encountered: