We want 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.
Combine 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).
- General patch and concept review
- This patch needs to be rerolled after #1779026: Convert Text Formats to Configuration System, which should happen first.
- #1878344: Add CKEditor JS library to core
- #1890502: WYSIWYG: Add CKEditor module to core
- #1886566: Make WYSIWYG editors available for in-place editing
- #1684930: Add description to "administer filters" permission
User interface changes
The menu item for "Text formats" is renamed to "Text editors and formats". 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).
ConfigEntititys, which store the configuration of editor options and are associated with a single text format.
\Drupal\editor\Plugin\EditorInterface, for "Editor plugins", with the following methods:
- For the new "Editor plugins": a corresponding
- 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.