WordPress.org

Make WordPress Core

Opened 4 years ago

Closed 2 years ago

#42618 closed defect (bug) (wontfix)

wp.mce.views API not using registered shortcode functions

Reported by: netsurfer2705 Owned by:
Milestone: Priority: normal
Severity: normal Version:
Component: TinyMCE Keywords:
Focuses: Cc:

Description

This is a follow-up to #21812.

Hi @all!
Not sure if this is the right place to post, but could not find a better one. Just a few words why I am posting here: I write a plugin that extends the default/ core gallery shortcode (by remove/add_shortcode ('gallery')).
So one of the "problems" with the whole 'wp.mce.views' API is, that it completly ignores/ bypass any shortcode functions (registered with WP). So to say it establishes its own shortcode functions, which imho cannot be useful. As a user I would expect, that every view represents the correct output of any shortcode in the content, which is currently not the case.
Unfortunately I am not the Javascript Guru to correct these "inappropriate" behaviour. So I am hoping that people with the needed knowledge will find a proper solution for this, espacially @koopersmith who seems to have invented this "system".
Beside this hope I would be glad if anyone could give me some advice/ hint, how to circumvent this problem and make views use of the proper shortcode function.
Many thanks in advance!

Change History (8)

#1 @swissspidy
4 years ago

Hey there

It seems like what you're looking for is https://wordpress.org/plugins/shortcode-ui/.

Shortcake is one of many Beta Plugins that might get integrated into WordPress core in the future. However, with Shortcake this is probably not going to happen because of Gutenberg. wp.mce.views is not exactly a priority because of that project either.

#2 @netsurfer2705
4 years ago

@swissspidy
Thanks for the tip. I just had a quick look, and basically the plugin does what I am trying to achieve. But AFAIS it is doing this for any kind of "newly added" post elements via shortcode. This case is not that problematic. But if you extend/ replace a shortcode which exists by default (e.g. the [gallery] shortcode) then you are running into problems, because instead of using the (newly) registered shortcode function(s), the views use their own (and simplified) shortcode function.
So what is needed, is to make the views functions use the correct shortcode functions. Otherwise the visual editor shows "incorrect" content for replaced shortcodes, which is not exceptable in any way.
So I cannot see how the Shortcake plugin could/ should solve this problem? If I overlooked, or misunderstood something, please let me know - thanks!

#3 @swissspidy
4 years ago

Shortcake renders all shortcodes via Ajax and therefore „sees“ the changes you made to the gallery shortcode.

wp.mce.views does only replicate the gallery shortcode functionality. If you change the shortcode, you‘d have to manually change the JS side as well. Shortcake is an easier alternative in that scenario.

#4 @netsurfer2705
4 years ago

Please correct me, if I got it wrong, but Shortcake adds an entry (Insert Post Element) to the modal window where you then can insert any of your former registered UI's.
That means, that I would have to implement a new [gallery] shortcode (handling) via Shortcake, instead of just replacing/ extending the default one.
Also Shortcake would not replace all the other elements belonging to the media library that deal with image attachments and galleries.
In my opinion it cannot be a solution for anyone to have to install a plugin to correct faulty core behaviour!

Shortcake renders all shortcodes via Ajax and therefore „sees“ the changes you made to the gallery shortcode.

So does the current core code, too. It uses the admin-ajax action "query-attachments". The problem lies in not using the registered shortcode function to evaluate the correct content. This is (mainly) caused by creating the query only on a (hardcoded) subset of the shortcode attributes.

wp.mce.views does only replicate the gallery shortcode functionality.

No! And that's exactly the point, as said before. Instead of using the registered shortcode function, it uses its own reduced version of the core/default shortcode function(ality), without paying respect to the actually registered shortcode function!
That is what I am complaining about.
Just to make things (perhaps) clearer: I added taxonomies for (image) attachments. So the user may generate a gallery based on these taxonomies. Therefor I added the respective attributes to the [gallery] shortcode. My intention is to make use of the default/ core [gallery] shortcode and not to add another shortcode (for many reasons)!
And in my humble opinion it is a "bug" in WP core, that views use a hardcoded version for evaluating a shortcode's content, instead of using the registered shortcode functions!

If you change the shortcode, you‘d have to manually change the JS side as well.

I do not agree. There should be no need to change any JS (functions) if one correctly registered a valid and functioning shortcode!
BTW: Even if I am willing to do so, the affected functions are spread all over the core, none of them intended to be overwritten. And there is also nearly no documentation, although the "basic system" was already introduced with version 3.5!

Last edited 4 years ago by netsurfer2705 (previous) (diff)

#5 follow-up: @azaozz
4 years ago

  • Milestone Awaiting Review deleted
  • Resolution set to invalid
  • Status changed from new to closed

I do not agree. There should be no need to change any JS (functions) if one correctly registered a valid and functioning shortcode!
BTW: Even if I am willing to do so, the affected functions are spread all over the core, none of them intended to be overwritten. And there is also nearly no documentation, although the "basic system" was already introduced with version 3.5!

I'm not exactly sure what you're saying here. You seem to be changing core's functionality (how galleries look/work) but don't want to change the functions that implement that functionality?

Editor "views" have nothing to do with shortcodes. They can be used to show a preview of a rendered shortcode inside the editor, that's all. If you want to change how gallery previews work, you will have to write the code for the previews yourself :)

Swissspidy pointed you at the proper direction already, there are plugins that do the things you want to do, have a look at their code, that's how open source works (assuming your plugin will be open source too).

#6 in reply to: ↑ 5 @netsurfer2705
4 years ago

  • Resolution invalid deleted
  • Status changed from closed to reopened

Replying to azaozz:

I do not agree. There should be no need to change any JS (functions) if one correctly registered a valid and functioning shortcode!
BTW: Even if I am willing to do so, the affected functions are spread all over the core, none of them intended to be overwritten. And there is also nearly no documentation, although the "basic system" was already introduced with version 3.5!

I'm not exactly sure what you're saying here. You seem to be changing core's functionality (how galleries look/work)

No, I changed the [gallery] shortcode function (functionality) ...

but don't want to change the functions that implement that functionality?

Sure, I will. I deregistered the core function and registered my own new one (for the shortcode). So far no problem. But as you may know, there are a lot of other (mainly JS) functions/ functionalities that belong to the gallery shortcode.

Editor "views" have nothing to do with shortcodes. They can be used to show a preview of a rendered shortcode inside the editor, that's all.

Sorry, I do not understand the logic behind your statement!?
As the shortcode itself keeps the same (unchanged), but the functions /functionality) is changed, the editor "views" either

  • needs to be replaced by another one (self scripted), or
  • should use the correctly registered shortcode function(s).

Unfortunately none of the two options are possible. At least I did not find an option (without changing core files, which is to avoid under all circumstances).

This is one of my problems I currently faced with - couldn't even find a way to "deregister/ unload" the MCE view. I have already sripted my own gallery preview(s) in a meta box. And I also managed to replace the shortcode in the content with a "placeholder text". But user can still click on the gallery (for inline editing) which "messes up" everything.

If you want to change how gallery previews work, you will have to write the code for the previews yourself :)

Yes, I am willing to do so. ;-)
But how to replace/ get ride of the existing view? Tips and help would be very much appreciated!

Swissspidy pointed you at the proper direction already, there are plugins that do the things you want to do, have a look at their code, that's how open source works (assuming your plugin will be open source too).

Sorry, but if I am not totally mistaken, Swissspidy's tip is helpful if one would "add a new feature". But not if one wants to chnage an existing feature (like the gallery shortcode).

I am working on this for months now. The "problem" is, that the whole gallery thing, including the shortcode) is not scripted in a way, that it could properly be replaced/ overwritten! There are lots of functions without any hooks, some parts of the database statements are hardcoded and the AJAX request for getting the image IDs for a gallery is lecking an info about the gallery number (in case there is more than one gallery).
And these are just some of the "problems" you are confronted with when trying to change the gallery shortcode functionality.

I was able to "solve/ circumvent" most of these problems. But with the editor I got stuck. So I would be very thankful if you could help me, or give me some advice/ tipps, how to "handle" the view/ preview thing in the editor. :-)

#7 follow-up: @SergeyBiryukov
4 years ago

  • Milestone set to Awaiting Review

Gutenberg would likely change things here, but moving out of an empty milestone for now.

#8 in reply to: ↑ 7 @azaozz
2 years ago

  • Milestone Awaiting Review deleted
  • Resolution set to wontfix
  • Status changed from reopened to closed

Replying to SergeyBiryukov:

Right. This is now superseded by the block editor. Galleries work in a completely different way there.

Closing as wontfix. Feel free to reopen with a patch if this still needs fixing in the classic editor.

Note: See TracTickets for help on using tickets.