Better handling of unrecognized shortcodes.

[joelworsham]

This stems off of a lengthy discussion I had with @BigActual.

Basically, it's not clear that "Other" shortcodes don't belong to Render, and that they don't really work well. I'm going to try to accomplish 2 things.

1. Better generic message to the end-user that the given shortcodes are NOT supported by Render, and they should refer to some plugin documentation.

2. Render should ping RBP for information on available extensions, and which shortcodes those extensions integrate. SO this way we can actually present information to the user on which plugin the shortcode is from, that we have an extension to better integrate it, and a direct link to do so.

[brashrebel]

I'm with you, although it doesn't seem like a remote request to RBP would be efficient or practical. Couldn't we just have a check in the plugin itself that examines $shortcode_tags and identifies shortcodes we've addressed in known extensions?

[BigActual]

Is a library of known extensions too heavy to include with core? Couldn't we run a comparison on the clients server between a list of known extensions and the list of existing plugins, without pinging RBP? Just update the list of known extensions when core is updated. Then present the results of that query to the to the End User in a relevant way. So the logic would be as follows:
Run a query of plugins and render extensions installed on the server and compare it against the library of know extensions in Core and the shortcodes known to come with each plugin.

1. If a plugin on the known list is not installed there would be no shortcode to worry about in the "Other" category so I believe that is an irrelevant situation
2. If a plugin on the known list is installed but the extension is not, display methods to implement the extension next to the relevant shortcode in the "Other" section. and write some copy above all of the shortcodes in this section that explains what happens in the "Other" section.
3. If a plugin provides shortcodes but is not recognized as having an extension then an alternative generic statement will have to suffice. Such as refer to the manufacturers website to properly use these shortcodes. Of course this needs to be edited for actual use...

Alternatively, Is it a better use case to, upon clicking an unrecognized shortcode within the "Other" tab,open a new modal window, much like the way column content editing has been reconstructed , to allow an end user to edit the "unrecognized" shortcode and apply attributes.
To clarify, the program presents the shortcode in it's raw format within a WYSIWYG editor of a new modal window, and prompts the End User to edit it with the Title, "Edit Shortcode for Use". Perhaps a sub heading or hint could be employed above the WYSIWYG editor that tells the End User to refer to the manufacturers site for information on how to edit their shortcode.

I believe this standardizes the workflow of known and unknown shortcodes and facilitates the use of extensions when they are relevant.

Is it possible that the tab is mislabeled? Other may not provide the right expected outcome?

Could it be a bettter use case to have a new tab show up for each extension? Installing an extension truly removes a shortcode from the "Unknown" category anyway.

[joelworsham]

@brashrebel What you're asking is what I'm suggesting. I believe it's very practical and efficient to ping RBP every so often, and the most reliable way to get up-to-date information on available extensions.

$shortcode_tags is already the method for gathering all of the site's shortcodes. The issue is knowing A) What plugin the shortcode is from, and B) Do we have an extension available for that?

@BigActual I think including a list of extensions within core isn't very good practice. It just adds a level of maintainability to core that I think doesn't need to exist in core. And I agree we need to re-think how the "unrecognized" shortcodes are presented to the end-user. More clarity on what they are and how to use them.

[joelworsham]

After a conversation with @brashrebel, we've decided to put all of the pieces into play to accomplish this, but forgo the remote calls and use static data implemented into core for now.