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

What's going to happen to media buttons and TinyMCE custom buttons? #794

Closed
UVLabs opened this issue May 15, 2017 · 2 comments
Closed

What's going to happen to media buttons and TinyMCE custom buttons? #794

UVLabs opened this issue May 15, 2017 · 2 comments
Labels
[Type] Question Questions about the design or development of the editor.

Comments

@UVLabs
Copy link

UVLabs commented May 15, 2017

What's going to happen to these?

image

I'm assuming we might not be able to use the same code since the editor will most likely look different? Hoping some documentation could be created ahead of time before this is merged into core so plugin and theme developers could update.

This is a widely used feature and though one can argue that it may be bad UX I believe it still has a place since you don't expect users to remember your shortcode which may be long in most cases or let them have to copy and paste it.

image

In my experience, I've seen both the custom tinyMCE buttons and the media buttons being used for this "shortcode injecting" feature.

Most plugins use this as some sort of a shortcode builder even:

image

I personally use it for one of my plugins to let users build their custom tweet boxes:

image

With this behavior you let users decide on the fly what data they want and not necessarily having to create it prior to needing it. Curious about your approach to this.

@jasmussen jasmussen added the [Type] Question Questions about the design or development of the editor. label May 16, 2017
@jasmussen
Copy link
Contributor

The recommended course of action will be to convert those shortcodes to blocks.

The block can be seen as an evolution of the shortcode. It embraces what made a shortcode great — bundling a bunch of complicated markup together into a single tag — but builds upon it. Blocks can be better designed, they can be manipulated directly inside the editor itself, and later in the year they will serve as a foundation for a customization focus that will likely involve a page building experience.

In this editor, shortcodes will still work, but can be seen as legacy feature. See also #334. That is, they will still technically work, but it would be recommended to migrate them to using the block API.

In that vein, block API documentation will be important, so I've added a milestone to #468.

We have ideas for where plugins can add buttons to the editor, but these depend on how far we get with the other features, and so the buttons that insert these shortcodes should also be seen as a legacy pattern, and they might not work.

@mtias
Copy link
Member

mtias commented May 16, 2017

Thanks for chiming in. This describes precisely what "blocks" are meant to replace under a coherent UX: discovery (via the inserter), visual display, editable attributes (direct manipulation as much as possible, convenient settings in the toolbar, advanced ones in the sidebar inspector). When you register a new block it'll be added to the inserter as a new item:

image

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
[Type] Question Questions about the design or development of the editor.
Projects
None yet
Development

No branches or pull requests

4 participants