Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add filter to allow other formats to be placed outside the dropdown menu in RichTextToolbarButton #22663

Open
chvillanuevap opened this issue May 27, 2020 · 4 comments
Labels
[Feature] Rich Text Related to the Rich Text component that allows developers to render a contenteditable Needs Decision Needs a decision to be actionable or relevant [Type] Enhancement A suggestion for improvement.

Comments

@chvillanuevap
Copy link

I'm creating a custom format named background-color to be able to highlight text. I basically replicated the code inside the text-color format in the formats library. The cool thing about the text color format is that when active, the button is displayed alongside the bold, italic, and link buttons with a colored line equal to the color of the text. I tried to do the same with my background color button but couldn't get it to work because in wordpress-develop/node-modules/@wordpress/block-editor/src/components/rich-text/format-toolbar/index.js there is a hardcoded array such that only bold, link, italic, and text-color can ever be displayed outside the dropdown menu.

So I hacked my code and set the key and name parameters in the RichTextToolbarButton of my background color format to say text-color instead of background-color.

I would like to request a filter to extend the buttons that can be placed outside the dropdown menu in the RichTextToolbarButton component. I know that I could have placed my background color inside a BlockControls component, but I wanted the text color and the background color to behave identically to provide a better user experience. This is what I ended up with thanks to my "hack":

Background color

I think it works much more cohesively and provides a more intuitive user experience than having the text color inside the drop down menu, and the background color as a block control.

My request is similar to #16014, but I don't know why the highlighter part never made it to core.

@tellthemachines tellthemachines added [Feature] Rich Text Related to the Rich Text component that allows developers to render a contenteditable Needs Decision Needs a decision to be actionable or relevant labels Jul 1, 2020
@tellthemachines
Copy link
Contributor

Hi @chvillanuevap , thanks for creating this issue!

We already have #20835 specifically to add an inline background color option to the toolbar. In addition, #20861 discusses a consistent placement for the text color option (either visible in the toolbar or in the dropdown at all times).

Would there be any other use case for a filter, outside of that background color option?

@chvillanuevap
Copy link
Author

It would be nice to have a filter in general for the developer of a block to decide which formats are visible in the toolbar (i.e. Bold, Italic, Link), and which ones are in the dropdown menu.

@JustinSainton
Copy link
Contributor

Adding my 👍 to this. Many of our publishing clients are frustrated by the lack of developer control here. Whether it's restoring an "Add Media" button like the Classic Editor, or adding shortcut icons to insert block patterns or custom areas with one click instead of 4-5 - the relative inability to customize this area is frustrating:

image

Ideally, as a developer, we'd have the ability to insert buttons/actions in each area represented in this top bar.

@mahnunchik
Copy link

I'm looking for this feature for a while...

Related issues:

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
[Feature] Rich Text Related to the Rich Text component that allows developers to render a contenteditable Needs Decision Needs a decision to be actionable or relevant [Type] Enhancement A suggestion for improvement.
Projects
None yet
Development

No branches or pull requests

5 participants