Toolbar group plugin

[dashingswags]

🆕 Feature request

For CKEditor 5
Worked on a plugin that does something like this

📋 Steps to reproduce

Add this to the editor config:

    toolbar: {
               items: [ 'bold', 'italic','underline','highlight','toolbarGroup']
    },
    toolbarGroup: {
               options: [
                   { model: 'paragraph', title: 'Paragraph' },
                   { model: 'heading1',  title: 'Heading 1' },
                   { model: 'heading2', title: 'Heading 2' },
                   { model: 'link',  title: 'Insert Link' },
                   { model: 'ckfinder',title:'Upload Image'}
               ]
      },

✅ Expected result

📃 Other details that might be useful

Can work with any of the builds.
Developed it for apps where grouping independent plugins might be necessary for better UI as i required something like that on the app iam working on. would like to know if i can go ahead to contribute this plugin to the community

---

If you'd like to see this feature implemented, please add 👍to this comment.

[Reinmar]

Hi! Thanks for the ticket and ❤️ for the PR (#1473). It looks great!

Ability to group toolbar items in dropdowns via a declarative API was something that we've discussed in the past, but I can't find the ticket. This is a pitty because that old ticket contained a lot of ideas 😞. Maybe one of my colleagues will be able to find it (cc @oleq @oskarwrobel).

Before we'll move to the implementation, we need to figure out what we want to do. Your solution focuses on adding the "more" option. In fact, this is more a space-saving solution which is in line with what we've been researching in #894 and #416. However, it rather seems that such a grouping should be automatic – we can't expect people to configure their editors always for the smallest screen size.

I like the UI of your solution, though. It's cleaner that what we had so far. However, I'm not sure how dropdowns would look in it. Perhaps it would work with normal buttons only (which could be fine too).

Automatic grouping is one thing. The other is declarative grouping. This, however, should be more flexible than just ability to create one group. We need something like:

	toolbar: {
		items: [
			'heading',
			'|',
			'bold',
			'italic',
			'link',
			{
				type: 'dropdown',
				title: 'Insert',
				icon: insertIconSVG,
				items: [
					'imageUpload',
					'insertTable',
					'mediaEmbed'
				]
			},
			{
				type: 'splitButton',
				title: 'List',
				items: [
					'bulletedList', // default action
					'numberedList'
				]
			},
			'blockQuote',
			'undo',
			'redo'
		]
	},

I'm not sure what types of automatic button groups we could introduce. I showcased a normal dropdown (could look like your proposal) and a split button, but perhaps only a normal dropdown would work automatically. E.g. in case of the split button we'd need to check whether we can automate the icon swapping and handle the default action of this button.

The main point of this is that you should be able to create more groups in one toolbar. You would need to be able to define labels and optionally icons for these groups too. That's why the API needs to look differently than what you proposed.

That's what we need – that's what would make this feature more versatile which is what we need to look for in the core.

Therefore, there are two options:

1. You could publish your plugin on npm – it can be very interesting choice for many developers.
2. If you'd like to go for an adventure, we can guide you how we would approach implementing a more verstile solution into the core :).

[dashingswags]

Yes, I have thought about having more groups in one toolbar, and have run some tests on it which worked (still testing different use cases). But that would serve as another plugin due to the fact that this model has a fixed icon which ships in with the plugin. also the idea behind this is that it should be called at the end of the toolbar item configuration similar to gmail compose mail toolbar on desktop.

With the references to the images above, the toolbargroup can also be configured to have icons only without text, in the event that the developer does not want any label alongside due to the non uniformity of the buttons with references to the images above (would push this update soon).

I really wanted to know if the idea was viable before working on further updates, and your reply was really favorable. Your reviews are highly appreciated

[dashingswags]

And yes, i would like to go on an adventure

[Reinmar]

And yes, i would like to go on an adventure

Cool 🎉

First of all, we need to get @oleq, @dkonopka and @oskarwrobel involved to get their opinion. The goal is to have some kind of initial spec.

[jodator]

Might solve issues with toolbar on mobile views:
#894 (comment)

[Reinmar]

Doh, I forgot to post the spec here :( I'm so sorry.

We've had a call with the guys regarding toolbar grouping back in January and discussed what should be done to improve CKEditor 5's toolbar layout on narrower screens.

We talked about two separate features: automatic grouping and declarative grouping.

Automatic grouping

The point of this feature is to make CKEditor 5's toolbar fit narrow viewports (mobile).

It's exactly this feature: ckeditor/ckeditor5-ui#451

In this case, it's important that grouping is done automatically, based on the viewport. It cannot be a manual configuration because then, the developer would have to configure the editor differently for desktop and for different viewport widths. It wouldn't also work with resizing (e.g. rotating) the viewport.

This feature has the highest priority for us because it will improve the CKEditor 5's responsiveness (see #416).

Another important consideration here is that the grouped buttons will be displayed in a panel – that panel must render well all kind of buttons that are in the normal toolbar – including dropdowns, split buttons, etc. Therefore, we think it'd be easier to go with the UI in the direction proposed by @oleq.

Manual, declarative grouping

I described it in #1472 (comment). It's not as important as automatic grouping and it's actually harder than automatic grouping too. We'd need to make a research first on how to use the existing toolbar items in such automatically created toolbar items and which types of items can actually be grouped. E.g., it may be fairly easy to group normal buttons into a dropdown, but grouping dropdowns into a dropdown will not be that easy (it'd create a nested menu structure). Grouping buttons into a split button may require some thinking as well.

To sum up

We've agreed with @dkonopka, @oleq and other guys who attended that we've got two use cases (making CKE5 responsive and allowing creating toolbar items in a declarative way). The PR that you proposed (#1473) does not address any of these issues. It's nice, interesting addition, but not something that we would like to add to the core and maintain.

If you didn't lose interest in this topic despite my super late answer, I'd see 3 things that can be done here:

• Easiest: you can publish your plugin on npm as a 3rd party addon
• Harder: you can try helping us finish t/ckeditor5/416b: (WIP) Implemented dynamic items grouping for overflowed toolbars ckeditor5-ui#451
• Hardest: implement manual, declarative grouping via config.toolbar. This task can start from a small research and POC what kind of options are feasible here (which will allow us to prioritise stuff and design the scope of MVP).

[cranky-retro-gamer]

Hi! Thanks for the ticket and ❤️ for the PR (#1473). It looks great!

Ability to group toolbar items in dropdowns via a declarative API was something that we've discussed in the past, but I can't find the ticket. This is a pitty because that old ticket contained a lot of ideas 😞. Maybe one of my colleagues will be able to find it (cc @oleq @oskarwrobel).

Before we'll move to the implementation, we need to figure out what we want to do. Your solution focuses on adding the "more" option. In fact, this is more a space-saving solution which is in line with what we've been researching in #894 and #416. However, it rather seems that such a grouping should be automatic – we can't expect people to configure their editors always for the smallest screen size.

I like the UI of your solution, though. It's cleaner that what we had so far. However, I'm not sure how dropdowns would look in it. Perhaps it would work with normal buttons only (which could be fine too).

Automatic grouping is one thing. The other is declarative grouping. This, however, should be more flexible than just ability to create one group. We need something like:

	toolbar: {
		items: [
			'heading',
			'|',
			'bold',
			'italic',
			'link',
			{
				type: 'dropdown',
				title: 'Insert',
				icon: insertIconSVG,
				items: [
					'imageUpload',
					'insertTable',
					'mediaEmbed'
				]
			},
			{
				type: 'splitButton',
				title: 'List',
				items: [
					'bulletedList', // default action
					'numberedList'
				]
			},
			'blockQuote',
			'undo',
			'redo'
		]
	},

I'm not sure what types of automatic button groups we could introduce. I showcased a normal dropdown (could look like your proposal) and a split button, but perhaps only a normal dropdown would work automatically. E.g. in case of the split button we'd need to check whether we can automate the icon swapping and handle the default action of this button.

The main point of this is that you should be able to create more groups in one toolbar. You would need to be able to define labels and optionally icons for these groups too. That's why the API needs to look differently than what you proposed.

That's what we need – that's what would make this feature more versatile which is what we need to look for in the core.

Therefore, there are two options:

1. You could publish your plugin on npm – it can be very interesting choice for many developers.
2. If you'd like to go for an adventure, we can guide you how we would approach implementing a more verstile solution into the core :).

How can I achieve this using ReactJS? I'm trying different approaches but can't use this feature.

[jeffreyclu]

Has there been any update on the development of this feature request?

[CKEditorBot]

There has been no activity on this issue for the past year. We've marked it as stale and will close it in 30 days. We understand it may be relevant, so if you're interested in the solution, leave a comment or reaction under this issue.

[CKEditorBot]

We've closed your issue due to inactivity over the last year. We understand that the issue may still be relevant. If so, feel free to open a new one (and link this issue to it).