Add editor shortcode-button hook about classicpress

[viktorix]

This petition had a related proof of concept done by @joyously. Discussion can be found here:
https://forums.classicpress.net/t/what-do-you-think-about-enhancing-shortcode-usage/1880/9

And a relevant PoC plugin here:
https://github.com/joyously/shortcode-lister/tree/feature-standalone

[ClassyBot]

This issue has been mentioned on ClassicPress Forums. There might be relevant details there:

https://forums.classicpress.net/t/add-editor-shortcode-button-hook/3673/9

[ClassyBot]

This issue has been mentioned on ClassicPress Forums. There might be relevant details there:

https://forums.classicpress.net/t/what-do-you-think-about-enhancing-shortcode-usage/1880/13

[smileBeda]

I have created such plugins and it would no way be possible to satisfy my needs of GUI (that is basically what Core would have to provide in this case), and the need of anyone else at the same time.

Adding a button that opens a popup where plugins can add their bunch of shortcode buttons is also not really improving the "mess", rather, it makes it worse IMO. You will end up with "that gallery shortcode button" and "the amazing page builder shortcode buttons" all in one thing.

What really would help thou (correct me if it exists already) is something else than media_buttons action, where the plugins can hook their main buttons (adding too many single buttons is absolute bad practice anyway and should be handled by that plugin, not by core)
This would be helpful, because right now to get buttons into the area above the editor (which is really where such buttons should live) you have to hook into action add_action( 'media_buttons', 'your_callback'), which will append your button to the existing "Add media" button. And that, is 💩 - because this area is controlled by access rules bound to the media upload capacity.
So an area just after or even inline with the same - but not hooked to media_buttons that allows a plugin to add their buttons, this could help.
And wrapped in a filter that allows a webmaster to either remove the entire section, or single particular buttons, would round it up.
That needs no hacks, it just needs one simple new action and one simple new filter.

However it would have to be clear that access control, in this case, needs to be performed by the plugin (which is also what would be the right thing to do anyway)

This new action and filter would have to be added somewhere after the https://core.trac.wordpress.org/browser/tags/6.0/src/wp-includes/class-wp-editor.php#L216 section.

[joyously]

The petition called for a shortcode menu, which was what was implemented to see how it could work. The PoC shows all parameters for all registered shortcodes, with their default values, instead of relying on the dev to supply a button.
But any actual implementation in core would need to be on a hook that is run regardless of media or any other capability checks.

[smileBeda]

Providing any such "catch all" shortcode menu is impossible.
Look at these 2 possible implementation of shortcodes.

TukuToi ShortCodes
Hooks into the only available hook to add one proper button, with one button that opens the GUI to manage shortcodes.

Media Button

ShortCodes Menu

Specific ShortCode Settings

Toolset ShortCodes
Hooks into the only available hook to add several proper buttons (one for each "domain"), with several buttons that opens the GUI to manage shortcodes.

Media Button

ShortCodes Menu

Specific ShortCode Settings

Believe me you would not want those shortcodes in a dropdown, or single mega-thing.
These 4 plugins together alone provide about 200 shortcodes for sure, each with at least 2 options, up to several tabs of options.

The only we could improve is provide a hook detached from the current media_buttons hook, and ask/educate developers to not add 200 buttons in the editor area, instead, create a smart GUI.
Anything else IMO does not consider the broader picture of massively powerful ShortCode-providing plugins that have more than just a few attributes, but actual shortcodes with dynamic options, even nested shortcodes or offer GUIs to actually insert values for attributes.

[joyously]

Providing any such "catch all" shortcode menu is impossible.

It's not impossible. I did it. It was what was asked for... however, it is likely not the best solution since there are plugins that provide a large number of shortcodes.
Because of how shortcodes work, plugin authors have had to invent various ways to help the user insert them. I don't know how to override all of those ways, except something like the block editor, which ignores shortcodes altogether.

We could make the consolidation menu more elaborate, but it assumes that the plugin author is cooperating. My approach was to use the existing register_shortcode as the only cooperation needed. There could obviously be some additional checks made for limits, to make the menu usable.

[smileBeda]

I have downloaded your plugin and installed it.
This is what I got:

That is a nice list of shortcodes, but it does not help at all to insert them with the gazillion of attributes, which can be of any nature
For example, when I inserted wpv-search-term using the dropdown I got - as expected - [wpv-search-term]
That shortcode will not even work like this.
It needs attributes set, like so [wpv-search-term param="this-term" separator="-"]

And that is only a very simple shortcode with 2 text attributes.
There are shortcodes they have attributes you can populate with all kinds of things, from simple post data to complex relationships, form attributes, user data, if/else conditions, math operations, and what not.

That, only a GUI that is created by the plugin developer, who knows the shortcode nature, can resolve.

It is like with custom fields. There was a petition to "finish the custom fields api" so "plugins do not have to create a new GUI each time"
That is... blocks. A standardised, powerless and restricted set of options that you have to use and cannot give any choice anymore neither to developer, nor to user.

The massive amount of guessing, and/or filters that core would have to provide if it where to add a full GUI interface for devs is almost a full blown CMS. And it would still not satisfy all use cases. We can see that very well in blocks and its provided "native inputs", actually. A total loss of power, with the only win of having the same "mess" as you have in "each plugins GUI" now unified in one big bulk sidebar.

I see 2 options here:

1. You (the user) does not like the "mess of buttons" => Do uninstall those plugins
2. Core provides a hook that is independent from media_buttons so it can be easier to unhook some buttons

Actually, every serious developer of such big shortcode bundles already provides such hook to unhook their own buttons if need be.
I am not opposed to a new hook. Unifying the GUI is too blocky for me.

[joyously]

That is a nice list of shortcodes, but it does not help at all to insert them with the gazillion of attributes, which can be of any nature

Well, it is proof of concept, and it does work on normal shortcodes. If the dev doesn't use the core functions provided, then it doesn't work, just as adding new hooks wouldn't solve anything for old code.
I am certainly not advocating any kind of UI like blocks or even the Shortcake plugin (which requires the dev to use those new functions).
The existing state of wondering "what is the name of the shortcode and what attributes it has" is difficult to use. That is the problem being addressed.

[smileBeda]

The existing state of wondering "what is the name of the shortcode and what attributes it has" is difficult to use. That is the problem being addressed.

That problem is already addressed - by the gui provided by the developer who adds the shortcode

all those short codes are crafted with only core functionality, they even apply third parameter of shortcode atts function to filter the attributes
I don’t think this problem needs a solution, since it’s only a problem if the developer basically just drops in a function that registers a shortcode without any sort of gui.

that is a UI issue the developer should solve, not core, imo.

[viktorix]

I think there could be potentially 2 items that we could address:

1. @smileBeda suggestion to add a new hook in addition to media_buttons such as secondary_buttons or utility_buttons.
2. Using part of @joyously plugin to create a page, maybe under Tools, that "shows all parameters for all registered shortcodes, with their default values." But this also could be a plugin.

[joyously]

That problem is already addressed

Apparently not enough, since there was a petition. And there are core shortcodes that are inserted by some UI, but can be done manually if you have a menu. There are a lot of plugins that don't provide any UI.

they even apply third parameter of shortcode atts function to filter the attributes

Perhaps this is why my code is not working with those, since that's the filter it uses to get the attributes. So it's a bug in my code.

suggestion to add a new hook in addition to media_buttons

This has pros and cons. The media button interfaces with the editor, but it initiates its own flow. That is similar to what a plugin's UI for a shortcode is doing too, but everything else that interacts with the editor is in the editor toolbar. I can see both sides.
I am saying that a way to insert a shortcode is different than a way to edit that same shortcode. I also didn't completely finish the PoC plugin since I didn't do anything about visual mode for the shortcode.

Using part of @joyously plugin to create a page, maybe under Tools, that "shows all parameters for all registered shortcodes

I'm against this since the information is needed in the editor, not in a separate page. There is a plugin already that helps you find what shortcodes you are using and where, which is much more useful and is info that "should" be provided by core.

[smileBeda]

The original petition wanted this:

What annoys me, and certainly others, is the chaos in the post editor with the shortcodes. Each plugin sets an extra shortcode button. Wouldn’t it be possible, even sensible, to implement a hook in which ClassicPress plugins can hang in order to display their button in a central “shortcode buttons” menu?

I don’t understand it as a “I don’t know what shortcodes I have available”, rather “there’s too many buttons”

And in my opinion that’s not the plugins fault!
It’s the webmasters fault of adding darn to many plugins.

A “central” button (let’s call it “shortcodes”) solves nothing. What does this button do? Open a very messy central shortcodes gui where each plugin adds its shortcodes, without any sort of organization

If you’d want to remove shortcode button for one plugin you’d end up removing all shortcodes, unless… that plugin offers a hook to remove single shortcodes or core would offer such.

Having a “central page” also doesn’t do much more than adding a dead page that few only will use. And as @joyously mentions, not useful because it’s not where “it’s needed”, which is in the editor, where we insert those shortcodes.

There is a further thing I didn’t mention earlier.
Both those examples I made offer nested shortcodes, shortcodes as HTML attributes and html in shortcode attributes.
For that to work careful apostrophing is required and only the plugin knows when to use single, or double apostrophe. Further it’s a security issue, which again only the plugin knows when to allow or deny. Handling that is basically only possible in the plugin, and if a user has other methods to insert those it’ll end in either broken output or insecure output (they already have too much of that “power” by manually tampering with the shortcode, but this can’t be avoided).

I do - from experience crafting and working with such plugins - agree that the media button hook is the wrong place because it’s bound to media access caps. So I’d appreciate a new hook adding a row either below or above or next to the media button for “arbitrary third party buttons, control access on your own”

Although, a new row imo adds more “mess”. It would have to be next to the media button breaking to new rows only if there’s too many buttons to span on one row.

Everything else results in an attempt of “standardized ui”. And that simply won’t work.
A list alone of all plugins with their attributes can be useful of course, yet I stand with the opinion that if a plugin offers shortcodes and doesn’t offer a gui that helps the user using them, is done half, and the users feedback should encourage those developers in doing better. This includes core shortcodes, which are at best a few only, and admittedly are as hidden as it gets.

We had the security page trying something very similar, remove clutter of security setting pages and so on, and yet it never got used.

[viktorix]

I also didn't completely finish the PoC plugin since I didn't do anything about visual mode for the shortcode.

@joyously do you plan to continue working on this PoC or should we close this feature request?

It would be nice to standardize shortcode insertion/generation process, just like media insertion or link insertion process. But that's different from what this request wants and a lot more complex project.