Skip to content
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

Section styles are stripped out of query loops #65644

Closed
jasmussen opened this issue Sep 25, 2024 · 11 comments
Closed

Section styles are stripped out of query loops #65644

jasmussen opened this issue Sep 25, 2024 · 11 comments
Assignees
Labels
[Block] Query Loop Affects the Query Loop Block [Type] Bug An existing feature does not function as intended

Comments

@jasmussen
Copy link
Contributor

If you create and apply a section style to a pattern or group of blocks, this section style shows up in post and page editors, and on the frontend, correctly:

pattern with section style

However in the site editor when viewing the post through a query loop in the Blog Home template, the section style is not applied:

pattern with section style in site editor

This is the query loop:

Screenshot 2024-09-25 at 13 26 30

In the "Content" block I would expect the section style to not be stripped away.

@jasmussen jasmussen added the [Type] Bug An existing feature does not function as intended label Sep 25, 2024
@ndiego ndiego added the [Block] Query Loop Affects the Query Loop Block label Sep 25, 2024
@ndiego ndiego moved this to 📥 Todo in WordPress 6.7 Editor Tasks Sep 25, 2024
@ndiego
Copy link
Member

ndiego commented Sep 25, 2024

I added this to the 6.7 board as it feels important to fix this before the release.

@aaronrobertshaw
Copy link
Contributor

I've started digging into this one but don't yet have a full explanation or possible solution.

It appears the issue has been around for quite a while and also impacts block instance element and layout styles in addition to section styles.

Here's an earlier issue where the problem with element styles was raised: #63606.

If looking at the right area, the problem is that posts to be displayed by the Query Loop (and therefore Post Template) are retrieved via a REST API call. The response for that includes rendered content that has already had filters for the_content and render_block etc applied.

Those filters are what the element, layout, and block style variation (section styles) supports use to apply classnames and enqueue additional stylesheets. The additional stylesheets aren't included in the API response and as such aren't loaded on the editor page.

If the content received and rendered within Post Template isn't treated as blocks, then the editor's JS hooks also won't run and create appropriate style overrides.

While I can partially explain the bug I'm coming up empty on an appropriate solution. I'm happy to explore any ideas people might have 🙏

@peterwilsoncc
Copy link
Contributor

This was raised during the dev-chat earlier. Would someone be able to post some reproduction steps for the issue?

Until recently, Global Styles weren't shown in the post editor -- see https://core.trac.wordpress.org/ticket/62042 -- so I am wondering if this is a similar problem.

@carolinan
Copy link
Contributor

carolinan commented Oct 9, 2024

element, layout, and block style variation

Yes, related to this and the problem with the element styles is that the group block grid is also missing CSS when displayed in the post content.
It has display: grid; applied but not the grid-template-columns

@jasmussen
Copy link
Contributor Author

Would someone be able to post some reproduction steps for the issue?

Check out Twenty Twenty-Five, or use the version bundled with the beta. Now author some content that uses section styles. Example in a GIF, steps outlined below:

Image

  • Add new post
  • Insert a pattern
  • Select the pattern itself (the container group)
  • Apply a section style in the block inspector, the Styles tab
  • Publish

Now you can go to the site editor, or any place with a query loop, and you'll see the section style missing:

Image

@aaronrobertshaw
Copy link
Contributor

Thanks for weighing in @peterwilsoncc 👍

Until recently, Global Styles weren't shown in the post editor -- see https://core.trac.wordpress.org/ticket/62042 -- so I am wondering if this is a similar problem.

I don't think this is related. That was a problem with non-admin users not having access to the Global Styles CPT data. This is an issue for all users due to the Post Content block only rendering the rendered HTML value received for the post entity via the REST API.


After some further digging today and conversations with @andrewserong, here's what I've found.

There was a previous attempt to solve this issue in #35863. That approach was blocked due to some concerns rendering the raw blocks in previews might expose private block data that shouldn't be.

One short-term idea for 6.7 could be to compromise here and render the raw blocks when the current user has the edit_posts caps for the post in question. It might help mitigate the issue somewhat, even if it's not a fix, while we iterate on a more holistic solution.

I'll try and at least get a PoC up for this compromise tomorrow unless better ideas surface before then.

FWIW hacking around bringing in changes from #35863 shows it does still render block support styles correctly.

From: #35863 (comment)
That's correct: previews need to use the rendered version as the raw version may not be available to all users

Regarding the concerns on exposing private content, I'm not sure I fully understand the issue enough. The Post Content block retrieves a post's content prop via useEntityProp. It appears that regardless of what user permissions I have for the logged in user, the returned content.raw value is always present. I tested this with users possessing either the author or contributor roles.

Is the problem that there could be a filter running server side that would normally block a user's access to a particular post or something within it? If that's the case, shouldn't that also be applied to the content returned in the REST API response?

The only other alternative would appear to be retrieving block support styles from the style engine context/store as well as WP_Styles registry for the block-style-variation-styles handle and sending them back in the REST API response. That sounds a bit iffy hence the current focus on whether we can just render proper blocks and let the editor's block supports hooks do their thing.

cc/ @ntsekouras and @youknowriad in case you have any thoughts, or buried memories, given your involvement on #35863

@aaronrobertshaw
Copy link
Contributor

Would someone be able to post some reproduction steps for the issue?

In addition to @jasmussen's steps for section styles, you can also encounter the problem by applying element styles or using a Row block.

  1. Create a new post
  2. Insert a container block of some description and then a Row block within that
  3. Add multiple paragraphs within the row block
  4. Create links within the paragraphs and add a custom link color for each of them
  5. Publish the post
  6. Visit the site editor and any template with a query loop that displays the post content
  7. Note that the Row block is actually stacked and the links don't have the correct colors
Example block markup for post when testing with TT5
<!-- wp:group {"className":"is-style-section-4","style":{"spacing":{"padding":{"right":"var:preset|spacing|40","left":"var:preset|spacing|40","top":"var:preset|spacing|40","bottom":"var:preset|spacing|40"}}},"layout":{"type":"flex","flexWrap":"nowrap"}} -->
<div class="wp-block-group is-style-section-4" style="padding-top:var(--wp--preset--spacing--40);padding-right:var(--wp--preset--spacing--40);padding-bottom:var(--wp--preset--spacing--40);padding-left:var(--wp--preset--spacing--40)"><!-- wp:group {"style":{"layout":{"columnSpan":1,"rowSpan":1}},"layout":{"type":"constrained"}} -->
<div class="wp-block-group"><!-- wp:group {"layout":{"type":"flex","flexWrap":"nowrap"}} -->
<div class="wp-block-group"><!-- wp:paragraph {"style":{"elements":{"link":{"color":{"text":"#29c8f8"}}}}} -->
<p class="has-link-color">Welcome to <a href="http://www.wordpress.org">WordPress</a>. This is your first post. Edit or delete it, then start writing! Welcome to WordPress. </p>
<!-- /wp:paragraph -->

<!-- wp:paragraph {"style":{"elements":{"link":{"color":{"text":"#3ee732"}}}}} -->
<p class="has-link-color">Welcome to WordPress. This is your first post. Edit or delete it, then start writing! Welcome to <a href="http://wordpress.org">WordPress</a>. </p>
<!-- /wp:paragraph --></div>
<!-- /wp:group -->

<!-- wp:buttons {"style":{"layout":{"columnSpan":2,"rowSpan":1}},"layout":{"type":"flex","justifyContent":"center"}} -->
<div class="wp-block-buttons"><!-- wp:button -->
<div class="wp-block-button"><a class="wp-block-button__link wp-element-button">Button</a></div>
<!-- /wp:button --></div>
<!-- /wp:buttons --></div>
<!-- /wp:group -->

Using the above example:

Editing Post Query Loop in Site Editor
Image Image

@aaronrobertshaw
Copy link
Contributor

I have a tentative short-term fix up in #66003.

While it might not be perfect, it definitely minimises this issue for WP6.7 and TT5's release. If there's consensus that it is safe enough, it would be good to land sooner rather than later so it can get some broader testing during the beta/RC phase.

@jasmussen
Copy link
Contributor Author

Thanks Aaron, will test now. I would encourage anyone else subscribed to take a look at the PR to see if it threads the needle. It would be very good for Twenty Twenty-Five that this land in 6.7, as it comes with 6 section styles for patterns, and having those work only in permalinks makes it lose a lot of the flavor.

@aaronrobertshaw
Copy link
Contributor

The fix in #66003 has been merged so I'll close this one out.

@github-project-automation github-project-automation bot moved this from 🏗️ In Progress to ✅ Done in WordPress 6.7 Editor Tasks Oct 11, 2024
@annezazu
Copy link
Contributor

Excellent follow up here!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
[Block] Query Loop Affects the Query Loop Block [Type] Bug An existing feature does not function as intended
Projects
Status: Done
Development

No branches or pull requests

6 participants