-
Notifications
You must be signed in to change notification settings - Fork 4.3k
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
Server-side rendering for inline content #14694
Comments
Howdy @dangerbarber this seems like a very niche, albeit very interesting!, use case. How else, other than your particular type of project would this be useful? I ask because at first read it sounds as if this kind of |
@draganescu We actually do have a custom plugin that has a quick and dirty workaround that uses shortcodes. What I'm asking for is not niche, but rather extremely general-purpose. Simply put, I want a gutenberg replacement (or perhaps, just a UI) for shortcodes that generate inline content. This could be used for literally anything that generates content that's intended to be part of a paragraph. Our use case is rendering info about credit cards that we store in a custom post type, and then we can pick which card ID and which field from that card we want to display as part of a sentence we wrote, that way the information in our blog post gets automatically updated when, say, the APR changes. A similar use case could be applied if you wanted to display the up-to-date display name for a given user that you've mentioned in your post, or maybe to show the average rating of a chosen item from your site's store, or to link the most popular blog post with a given tag. This could be applied to literally anything that changes often and the server knows about in real time. (and notice that all of those problems can be solved by creating a shortcode, but all of them would require manually editing it) The solution could be to keep shortcodes as the way to serialize this functionality, it just needs a frontend on top of it. All we want is a nice UI to generate and edit them, instead of telling my content writers to go type out something like |
@draganescu Also, to more directly address the suggestion for a RichText + dynamic text block for the specific purpose, I think I can see what you mean, but unfortunately we don't know where or how many times these will appear in any given paragraph. I can't think of any way to implement that customizability without modifying the richtext editor itself. |
Thank you for the detailed use case; this is overlaps with #10235 and which would cover your use and you can follow along progress to implementation in that issue. |
The Problem
I have a few shortcodes that were created to provide the ability to display data that cannot be saved in the markup itself because it comes from a database that is regularly changing. Because we don't want to have to rewrite all of the content that uses this information whenever it changes on the backend, we need to render it on the server side.. This information is usually only 2-5 words in length, and they are designed to be displayed seamlessly as part of a sentence, so the shortcodes only print raw text without any HTML markup.
Because there is not a way (to my knowledge) to create a Gutenberg block that can be added inline in a paragraph block, I cannot solve this using the Blocks API, and because the RichText formats (to my knowledge) do not get registered in PHP, and therefore have no render_callback property, I cannot achieve this with them either.
Proposed Solution
I feel that there should be an equivalent API to the blocks for use with elements that are supposed to be inline. It appears that the RichText/Formats API could be the intended solution to this, although I also see it as a more lightweight API meant for adding simple styling/semantic changes to spans of text, which doesn't really fit my use case either.
One idea is that creating a format should be done via a
register_format_type
function in PHP, which would be able to accept a render_callback function. This seems like it might not be the lightweight text-formatting solution that was originally intended for the Formats API.Another proposed solution would be to create a method of creating some kind of "Inline Block" which can be added to rich text elements, which would have the same API as the regular Gutenberg blocks, but would specifically be aimed at placing them inside rich text.
Considered Alternatives
Using a normal block for this purpose does not work, because a normal block cannot be placed inside of a paragraph, and thus the 2-5 words of content returned would not flow nicely with the content. CSS could likely be altered to fix this, but that would be quite hacky and wouldn't follow the intended semantics of paragraph tags.
Another thought was to create a format that represents an inline element of some sort (the content of which would be meaningless), and then write a JavaScript app that could find this element, lookup the value from an API, and then insert the returned content into the element. This seems like incorrect usage of formats, it requires me to expose a lot of data via a publicly accessible API (which I would prefer not to do), and it would mean that the markup of our pages don't have the information we want before running JavaScript and making several additional HTTP requests, which might have negative effects on our SEO.
Current Workarounds
As of now, what we're trying to do is achievable using shortcodes, and then adding a button to the editor that allows us to easily insert this shortcode into the content. If this is the intended solution, we can certainly continue using this solution, but I was under the impression that Gutenberg was intended to replace all use cases of shortcodes. It would also be nice to use the React-based editor to create visual apps for editing the parameters of such inline elements.
I hope this request makes sense, and I'm happy to provide any additional clarification if not. I'm also happy to try to (slowly) work on a merge request if you think either of my suggestions are a reasonable solution.
Thanks for your time!
The text was updated successfully, but these errors were encountered: