Block Supports: Refactor styles rendering to utility function and add to REST API responses #35450
+95
−50
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
andrewserong
added
[Type] Bug
7 tasks
|
Size Change: +62 B (0%) Total Size: 1.07 MB
ℹ️ View Unchanged
|
andrewserong
force-pushed
the
try/refactor-block-supports-styles-to-render-via-a-utility-function
branch
from
ced222d
to
9385b59
Compare
andrewserong
changed the title
andrewserong
requested review from
ajitbohra,
spacedmonkey and
TimothyBJacobs
as code owners
|
@youknowriad @spacedmonkey — just a heads-up this is where I'm up to with refactoring the block supports styles to be rendered correctly in the site editor. I've gone with Jonny's suggestion to add a separate field to the REST API responses, and then in the Post Content block, we then append those styles in read only mode. I haven't yet added tests (but am happy to, and would like to). I'm keen for feedback on the approach before I continue polishing, whenever you have time to take a look 🙂 |
ellatrix
reviewed
Oct 12, 2021
| { blockSupportsStyles && content?.rendered | ||
| ? content.rendered + blockSupportsStyles | ||
| : content?.rendered } | ||
| </RawHTML> |
There was a problem hiding this comment.
What if layout, duotone etc. is rendered outside of the post content?
There was a problem hiding this comment.
Good question, thanks for taking a look @ellatrix. This particular line just deals with the Post Content block, so grabbing blockSupportsStyles as a field from the posts endpoint currently works, but this PR does assume we're dealing with post content. Outside of the Post Content block within the site editor, the block supports still appear to be rendering okay in my testing so far, but I haven't tested with other REST API based server-rendered blocks, so there are likely still many gaps.
We could also add the field to other resources that need it, e.g. comments, possibly the block renderer, too?
I've struggled a bit with coming up with a clean solution to ensure that the rendered block supports styles are always available and will be used in each potential case. In this PR, we mostly solve for the problem of rendering within the Post Content block in the editor, however I can imagine there will be a number of edge cases where we'll need to be intentional about how we render (and make available) the block supports styles. If this approach looks viable, we can always follow up with each of the edge cases as we encounter them, but I'm aware that approach could be brittle (and not necessarily great for other consumers of the REST API).
Let me know if you can think of a better way to expose the styles that we're currently rendering out to wp_footer, I'm very happy to rework this PR if we can come up with better ways to handle it! 🙂
|
Update: the approach proposed in this PR adds a field to the API responses for the Posts and Pages API endpoints. With a bit more time to think about this over the past couple of weeks, I think in general, how we ship block supports / global styles via API endpoints needs a bit more thought to come up with a generalisable solution. For example, in this PR, we really only deal with posts and pages, but comments or other post types also support blocks, so these would need to be factored in. And in the longer-term, we'd ideally want to think through carefully how developers are supposed to retrieve and combine styles with content. So, as a shorter-term fix for the issue at hand, I've opened up a separate PR to switch the Post Content block over to render its readonly state as live blocks in the editor, instead of raw html. This seems to fix the main issue that inspired this PR (rendering block supports styles in the site editor for the post content block). I'm keen for feedback if anyone gets time to take a look: #35863 If that approach looks viable (to fix the visible bug in time before 5.9) then we could potentially close out this PR, and defer the discussion surrounding returning styles via API endpoints to another time. |
|
Related: https://core.trac.wordpress.org/ticket/48654, https://core.trac.wordpress.org/ticket/46379
This seems ideal. Getting those endpoints right is important and I think too difficult to land in a few weeks. |
Closed
10 tasks
|
Thanks for the links to the prior Trac tickets, Timothy! It looks like we're honing in on a workable approach in #35863 now, so I'm going to close out this PR. Thanks everyone! |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Description
Fixes #35413 and possible fix for #35331
This PR explores an idea (and alternative to) #35413 to render block supports styles via a common utility function. This function adds the styles via the
wp_footeraction, and also registers the styles with a filter that is then used to add the styles to API responses for public post types.Background
Currently the Layout, Duotone, and Elements block supports each feature some form of rendering where either styles or
svgmarkup are appended to the rendered post/page viawp_footer. For these styles to be available within a server rendered block in the editor, they also need to be returned in REST API requests.The goal in this exploration is to see whether we can come up with a common function to render out these styles / markup from block supports, and to also support rendering in a REST API request. The current approach to achieve the latter is by registering an additional REST API field for public post types,
block_supports_styles:The end result is that we fix the bug reported in #35376 where block supports styles are not rendered in the post content block within the site editor, when it is a child of the Query Loop block.
Screenshots
The following screenshots are from the Site Editor, viewing the Post Content block within the Query Loop block. The rendered post content contains:
How has this been tested?
Before applying this PR:
After applying this PR:
<style>.wp-container-615e737c1a8f3 > *) are still rendered in the footer, after script tags, etc.postsAPI endpoint, used to render the Post Content block within the editor. E.g. on my test site, there's a URL like: http://localhost:8888/index.php?rest_route=%2Fwp%2Fv2%2Fposts%2F1105&_locale=userblock_supports_stylesfieldTo-dos
Types of changes
Bug fix (non-breaking change which fixes an issue)
Checklist:
*.native.jsfiles for terms that need renaming or removal).