Problem/Motivation
In the CKEditor configuration, plugins are referred to inconsistently in the interface. This means it is not clear that each toolbar button is a plugin. This can lead to confusion with regard to following instructions or resolving errors, if the administrator does not realize that the toolbar icon represents a plugin.
Tagging for accessibility, as this adds to cognitive load.
Steps to reproduce
1. Go to /admin/config/content/formats/manage/basic_html
Expected result:
Move a button into the Active toolbar to enable that plugin, or into the list of Available buttons to disable it. Buttons may be moved with the mouse or keyboard arrow keys.
The toolbar buttons that don't fit the user's browser window width will be grouped in a dropdown. If multiple toolbar rows are preferred, those can be configured by adding an explicit wrapping breakpoint wherever you want to start a new row.
Available buttons/plugins
Active toolbar plugins
Actual result:
Move a button into the Active toolbar to enable it, or into the list of Available buttons to disable it. Buttons may be moved with the mouse or keyboard arrow keys.
The toolbar buttons that don't fit the user's browser window width will be grouped in a dropdown. If multiple toolbar rows are preferred, those can be configured by adding an explicit wrapping breakpoint wherever you want to start a new row.
Available buttons
Active toolbar
2. Click Source Editing
(Update Sept. 17, 2024: This item appears to have been resolved separately from the current issue.)
Expected result, if Source Editing is a plugin:
A list of HTML tags that can be used while editing source. It is only necessary to add tags that are not already supported by other enabled plugins. For example, if "Bold" is enabled, it is not necessary to add the
<strong>tag, but it may be necessary to add<dl><dt><dd>in a format that does not have a definition list plugin, but requires definition list markup.
There might be other edits needed to this text per #3468404: Make CKEditor be forgiving of enabling something that's already enabled.
Expected result, if Source Editing is not a plugin:
A list of HTML tags that can be used while editing source. It is only necessary to add tags that are not already supported by enabled plugins. For example, if "Bold" is enabled, it is not necessary to add the
<strong>tag, but it may be necessary to add<dl><dt><dd>in a format that does not have a definition list plugin, but requires definition list markup.
There might be other edits needed to this text per #3468404: Make CKEditor be forgiving of enabling something that's already enabled.
Actual result:
A list of HTML tags that can be used while editing source. It is only necessary to add tags that are not already supported by other enabled plugins. For example, if "Bold" is enabled, it is not necessary to add the
<strong>tag, but it may be necessary to add<dl><dt><dd>in a format that does not have a definition list plugin, but requires definition list markup.
Proposed resolution
Consistently refer to plugins throughout the interface, since error and warning messages refer to plugins.
Remaining tasks
User interface changes
Introduced terminology
API changes
Data model changes
Release notes snippet
| Comment | File | Size | Author |
|---|---|---|---|
| #13 | 3471896-nr-bot.txt | 1.01 KB | needs-review-queue-bot |
Issue fork drupal-3471896
Show commands
Start within a Git clone of the project using the version control instructions.
Or, if you do not have SSH keys set up on git.drupalcode.org:
Comments
Comment #2
charles belovComment #3
quietone commentedComment #6
annmarysruthy commentedComment #8
kumudbI have verified the changes and have raised a MR to address the issue of inconsistent plugin representation in the CKEditor configuration interface. Please review the PR at your convenience. Thank you!
Comment #9
charles belovReviewed and tested in simplytest.me, thank you!
I didn't change the status because I don't know whether my test is sufficient to be considered Reviewed and Tested by the Community.
The part above about adding "other" to the Source Editing instructions is out of date because that change has already been made to core code. It is correctly not part of the current MR.
Comment #10
charles belovComment #12
smustgrave commentedComment #13
needs-review-queue-bot commentedThe Needs Review Queue Bot tested this issue. It fails the Drupal core commit checks. Therefore, this issue status is now "Needs work".
This does not mean that the patch necessarily needs to be re-rolled or the MR rebased. Read the Issue Summary, the issue tags and the latest discussion here to determine what needs to be done.
Consult the Drupal Contributor Guide to find step-by-step guides for working with issues.
Comment #14
needs-review-queue-bot commentedFalse positive
Comment #15
benjifisherUsability review
We discussed this issue at #3481737: Drupal Usability Meeting 2024-10-25. That issue has a link to a recording of the meeting.
For the record, the attendees at the usability meeting were @benjifisher, @rkoller, @shaal, @amazingrando, @rosendo.fig, @simohell, and @worldlinemine.
We agree that the language here is inconsistent, but we think the right way to fix this is to remove references to "plugins", not add more. The word "plugin" has too many meanings (in Drupal, CKEditor, and WordPress, for example) and someone configuring the toolbar is more likely to think of "features", "buttons", or "toolbar items".
We also think we should use something more generic, like "toolbar items", instead of "buttons", since the toolbar also includes drop-down lists and separators.
We suggest making the following changes to the interface text:
If you want more feedback from the usability team, a good way to reach out is in the #ux channel in Slack.
(edited)
Comment #16
charles belovDid some HTML in that last comment get rendered as HTML instead? There appears to be blank space between "necessary to add" and the period.
Comment #17
benjifisherThanks for pointing out that problem. I edited Comment #15.