We wanted to ship Drupal 8 core with a WYSIWYG. Traditionally configuring a WYSIWYG has meant a separate configuration page for making one-to-one relationships between a WYSIWYG and a text format. The idea of a one-to-one relationship has proven very successful in practice as shown by WYSIWYG module, CKEditor module, BUEditor, and others. However because the text format configuration is a different thing than the WYSIWYG configuration, you end up with a problem where enabling the "Bold" button doesn't necessarily mean that the <strong> tag is enabled. Likewise, other incompatible configurations can take place, such as enabling the line break filter and having the WYSIWYG format your code for you can lead to unexpected line breaks.
Therefore, we've combined the configuration of WYSIWYGs and text formats together into a single page of configuration. This will allow us to do things like automatically set desired HTML tags based on the configuration of a WYSIWYG toolbar, or detect incompatible options that are used together (or ideally just adjust the questions we ask users based on the WYSIWYG that has been selected).
In addition, this patch provides a foundation for binding text editor libraries (which live on the front-end) to text formats by providing JavaScript representations of the format via drupalSettings.
UI changes
The menu item for "Text formats" is renamed to "Text formats and editors". When configuring a text format, you also associate an "Editor" with the format. You may choose "None" to not have a text editor associated with a format.
Internally, we continue referring to text formats as "formats", but (still internally), we now also have the concept of "editors", where each "editor" (a ConfigEntity) is associated with a text format. On the front-end, we commonly refer to formats as "text editors", or "editor" for short when its already clear you're working with text (such as on node forms). This puts front-end emphasis on how the user interacts with Drupal (through the text editor) rather than how Drupal processes the value (through formats and filtering).
API
- New Text Editor module (
editor.module) EditorConfigEntititys, which store the configuration of editor options and are associated with a single text format.\Drupal\editor\Plugin\EditorInterface, for "Editor plugins" (which should use the@Editorplugin annotation) with the following methods:getDefaultSettings()settingsForm()settingsFormValidate()settingsFormSubmit()getJSSettings()getLibraries()
- Several hooks for the above:
- For the new "Editor plugins": a corresponding
EditorManager. - Selecting a text format automatically attempts to notify a front-end library that it needs to turn on. The editor library is given a JS object representing the configuration of the format and DOM object representing the field on which it needs to be enabled.
| Attachment | Size |
|---|---|
| text formats & editors.png | 37.23 KB |
