Add configuration to allow toolbar to show all icons by wrapping to multiple lines

Wim Leers → credited lauriii → .

Discussed this in detail with @lauriii.

The CKEditor 5 toolbar configuration admin UI at /admin/config/content/formats/manage/basic_html is a visual wireframe-esque representation of the enabled buttons. It looks quite different from the actual CKEditor 5 on the /node/add form. On top of that, it can look even more different in other contexts: in narrow viewports, when used inline (like Quick Edit used to — CKEditor 5 supports that too!), and so on.

These principles were also the case for CKEditor 4's toolbar configuration admin UI, actually! (But there, the admin UI actually looked more like the actual end result — so it was arguably more confusing.)

While I appreciated your suggestion at #9, it unfortunately really is not feasible to implement — @lauriii confirmed that.

So, to keep this module's issue queue maintainable, closing this issue — hope you agree with the rationale!

Automatically closed - issue fixed for 2 weeks with no activity.

woops sorry for the late reply. the window i've kept open for writing up the reply slipped through - too many open tabs in too many browser windows.

and yep no problem at all. the current iteration isn't wrong or bad in any way. the suggestion was just towards a potential further improvement. but as you outlined it is a totally reasonable to close the issue if the endeavor isn't feasible at all. thanks for the investigation and discussing the issue with lauri!

I'm seeing this problem with embedded form contexts. I have a D9.5.9 site I am working on at the moment. I am using the Gin theme. When I am looking at text area fields using CKEditor that are directly in fields of the content type it looks great (see screenshot below). It clearly stuffs the extra controls behind a triple-dot icon and looks great.

However, when I edit and embedded entity form (entity reference field) and that entity (in this case ECK Brick) has a text area with editor I see it overflowing to the right instead of nesting in this triple-dot menu. That to me is the problem.

Good width display:

Problem toolbar width:

I am rerolling the patch for 9.5.x

Please check the below given patch as ckeditor5 is now part of core.

We are about to run patch 5 from #20.

If you don't want to make this the default, can we add a drupal config to wrap the toolbar to multiple lines?

I confirm patch 5 from #20 works running Drupal 10.2.x

Whao, we just ran into this issue and it was not easy to find out how it works. It's just a UX / help text bug, from my perspective!
The feature is already built-in, but super hard to guess :D

I finally found it out by reading the discussions and outcome in #3202589: Follow-up for #3198297 Support explicit wrapping breakpoint →

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.

So to fix this, I think we should add information here about placing the "Wrapping" button at the very end of all buttons to achieve "breaking" functionality instead of hiding. It works perfectly!

Here we go!

I added the following sentence:

To dynamically wrap each button into the next line, instead of grouping them into the dropdown, place the explicit wrapping breakpoint at the very end.

I'm not a native EN speaker, so could someone please review the sentence?

Once we agreed on a final one, this needs to be rebased. Seems the issue branch was heavily outdated... ;)

But first let's come to a conclusion.

AND: I'd even vote to place that wrapper in the end by default for new installations. I think adding an extra click and hiding the items by default is always worse UX, but that's just my personal oppinion.
Follow-up?

Visual explanation of how it works as expected:

Placing the wrapping at the very end

uhhhh that is a behavior i wouldn't have expected by the wrapping button. nice catch and digging, thank you!

i've changed the version to 11.x. @quietone always provides the following explanation on issues: "Changes are made on on 11.x (our main development branch) first, and are then back ported as needed according to our policies." and i can confirm that the issue branch is outdated, since i am unable to checkout:

$> git checkout -b '3229177-add-wrapping-eol-feature-documentation' --track drupal-3229177/'3229177-add-wrapping-eol-feature-documentation'
error: The following untracked working tree files would be overwritten by checkout:
	core/modules/system/tests/modules/driver_test/src/Driver/Database/DrivertestMysql/Connection.php
	core/modules/system/tests/modules/driver_test/src/Driver/Database/DrivertestMysql/Install/Tasks.php
	core/modules/system/tests/modules/driver_test/src/Driver/Database/DrivertestMysqlDeprecatedVersion/Connection.php
	core/modules/system/tests/modules/driver_test/src/Driver/Database/DrivertestMysqlDeprecatedVersion/Install/Tasks.php
	core/modules/system/tests/modules/driver_test/src/Driver/Database/DrivertestPgsql/Connection.php
	core/modules/system/tests/modules/driver_test/src/Driver/Database/DrivertestPgsql/Install/Tasks.php
Please move or remove them before you switch branches.
Aborting

i run into that error due to a commit on the 13th or 16th of august (can't remember the exact date) which causes that issue due to the none case sensitive file system on macos for me. but the odd thing is i thought there was no MR nor created issue fork on this issue and you were opening a new MR? i would have assumed it would then be based on the latest state of 11.x? so i am unable to see your changes in context, in particular where the sentence is placed. i can base my comment only on #27 💬 Add configuration to allow toolbar to show all icons by wrapping to multiple lines Active for now.

About the sentence, I would refer to it as the wrapping button divider or simply wrapping button not as the wrapping breakpoint. the term "breakpoint" isn't used on the text formats page so it might be potentially confusing for a user since the sentence is about the placement of the wrapping button? but the sentence is still hard to grok.

Knowing now those two options i've played around with the wrapping button a bit more and i consider the outcomes still sort of unintuitive and in part unexpected. If you have 27 buttons added to the toolbar:

1. if you place no wrapping button, a drop button is placed in position 15 at the end of the row. only a single row is displayed.
2. if you place the wrapping button in position 28, the toolbar buttons are wrapped. two rows are displayed
3. if you place the wrapping button in position 3, the first row contains only the first two buttons , the rest of the buttons are wrapping across row two and three. three rows are displayed => i would have expected, with a wrapping button placed just in position 3, that you have two buttons in the first row and 14 buttons in the second row with a drop button at the end soonly two rows are displayed instead of wrapping into a third row.
4. if you place wrapping buttons in position 3 and 28, the first row contains only the first two buttons , the rest of the buttons are wrapping across row two and three. three rows are displayed

so the wrapping button has two function, first it acts as a line break and second as a toggle to switch between keeping the toolbar in that row the wrapping button is placed at the end showing a drop button and wrapping the toolbar across multiple rows. so the wrapping button has still a bit of implicit behavior as illustrated in scenario 3 and 4. i wonder if it would make sense to separate those two aforementioned functions? meaning the button positioned in the toolbar solely acts as the line break for starting a new row and in regards of the toggle functionality add maybe a radio button to the toolbar configuration fieldset where you decide how the toolbar should behave if the maximum available space is exceeded - either display a drop button or wrap into a new row. that way the implicit functionality would become explicit and more clear?

question is which route to take. simply adding a sentence "might" be enough. but do people really read some description? i just realized i never really read the description already in place in the toolbar configuration fieldset entirely:

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.

the second paragraph already "sort" of covers the behavior of the wrapping button as well, if you know its inherent specifics. so i am not sure if just adding a text would do the trick? what do you think?

and i set the issue back to needs work for the rebase which will be needed in any way for the way forward.