-
Notifications
You must be signed in to change notification settings - Fork 4.2k
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
Layout block support: Append layout styles to post content in REST API requests #35413
Layout block support: Append layout styles to post content in REST API requests #35413
Conversation
@youknowriad and @ellatrix, I've just added you both as reviewers since you've worked on the layout support before. Please let me know if you think there's another way we should handle this instead 🙂 |
Interesting issue, I agree we need to find a consistent solution here but the proposed one is rather too specific for me. I think there might be other block supports (duotone and maybe others?) that have the same behavior as layout and we should try to find something baked into the framework and avoid moving the responsibility to handle this to the block supports them selves. |
This works well for me @andrewserong Thanks for getting a fix in so quickly 🙇
✅ Layout block CSS is appended to the post content in the REST API response. It looks good to me, but keen to hear other's opinion on the approach. |
That sounds very reasonable 👍 I can confirm that the duotone render block callback is also affected:
Is there an obvious place to relocate the logic to handle this, or to start looking? I was thinking, because I don't know any better, that we could roll out a helper method/filter that will do the |
To be honest, I don't know. I think @ellatrix moved these styles to the footer initially so she might know better. |
Thanks for the feedback, folks!
Very much agreed, it does feel quite brittle if each of the block supports has to worry about how and where they're injecting styles. It'd be nice to have a helper method or two that abstracts the behaviour away. Let me know if anyone thinks of other ways to approach this, I'm happy to do further digging, too. While I was hacking around with this PR, I tried a few different ideas, including hooking into filtering the REST API response, and ironically the solution using an extra filter and I suppose ultimately we need to come up with a consistent approach for block supports that:
|
That makes sense. It makes me wonder about global styles styles though, some of the global styles are also necessary for post content to show up properly and sometimes the distinction about what should be in post content or not is hard to draw. |
Note that after #35425 the link color styles will also be impacted by this bug. |
I'm wrapping up for the week, but out of curiosity, I thought I'd explore the idea of whether the approach in this PR could be generalised and made applicable for the three block supports that currently render either I've made a start with a draft PR in #35450, which currently refactors the Layout support a bit to make this possible. I think the approach can be wrangled to also factor in the Duotone and Elements implementations, but the whole concept could still be a bit of hack. I'm curious to see whether I can get it to technically work, but I'm more than happy to get early feedback if anyone thinks it isn't worth pursuing further. Otherwise, I'll keep hacking around / digging in that draft PR next week! 😀 |
A common function sounds good like explored in #35450 but I didn't understand why you had to include the "placeholder" logic there, it could receive the "output" directly? |
Thanks for taking a look!
I was curious to explore the idea of seeing if we could abstract away the unique id generation to the function, too, instead of the block supports having to worry about it. But it's probably doing a bit too much to add that in at the same time (and then adds the complexity of the "placeholder" logic). I'll rework it on Monday to simplify. Cheers! |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hey, I am maintainer of the REST API, so want to chime here.
First, I don't like the format of this PR, the_content
is used for every post type, even hidden ones, like menu items. Using it here, is overkill and will fire on many post types that do not need it. Also, the check for REST API, could be improved, as it will not load in preloading middleware.
Instead of adding to new field the REST API, using a function like register_rest_field. Why does this data need to live in the content field?
If adding a new field doesn't make sense, can I recommend using, rest_prepare_{$this->post_type}.
Let me know, when you have made the changes and I will re-review
Thanks for taking a look @spacedmonkey, much appreciated!
That's a great idea. Preferably we wouldn't be rendering these I'll do some exploration either in this PR or in #35450 to see what's possible and will be sure to give you a ping when it's ready for another review! |
I'm going to close this PR out now, as I've progressed further in moving to a generic utility function approach in #35450, so let's move the discussion over there. Thanks! |
Description
Fixes #35376
This PR updates the Layout block support to render the layout styles in REST API requests by appending the styles to the end of post content.
In requests to endpoints like the posts endpoint,
wp_footer
isn't output, so in certain circumstances (like rendering the Post Content block in the site editor) blocks depending on the layout styles render incorrectly. The approach in this PR attempts to be as consistent as we can with the approach introduced in #32083, which moved the rendering of the styles from the end of the individual block's content towp_footer
.How has this been tested?
Manually.
Before applying this PR:
After applying this PR:
<style>.wp-container-615e737c1a8f3 > *
) are still rendered in the footer, after script tags, etc.posts
API 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=usercontent.rendered
string, you should see the layout styles are now renderedScreenshots
Types of changes
Bug fix (non-breaking change which fixes an issue)
Checklist:
*.native.js
files for terms that need renaming or removal).