Allow post template responsive grid styles to be unset in the UI#76714
Closed
tellthemachines wants to merge 3 commits intotrunkfrom
Closed
Allow post template responsive grid styles to be unset in the UI#76714tellthemachines wants to merge 3 commits intotrunkfrom
tellthemachines wants to merge 3 commits intotrunkfrom
Conversation
tellthemachines
requested review from
ajitbohra,
fabiankaegy and
juanmaguitar
as code owners
tellthemachines
added
[Type] Enhancement
|
Size Change: +377 B (0%) Total Size: 7.75 MB 📦 View Changed
ℹ️ View Unchanged
|
|
Flaky tests detected in b59c48e. 🔍 Workflow run URL: https://github.com/WordPress/gutenberg/actions/runs/24494820736
|
ramonjd
reviewed
Mar 20, 2026
Member
ramonjd
left a comment
ramonjd
left a comment
There was a problem hiding this comment.
I can't think of a better way of ensuring the fallback styles are present for back compat while not being there for new or edited blocks
How much of a pain would it be to deprecate? Or is it even possible?
Only asking coz if the attribute is only to flag whether the user has explicitly touched the layout options, then it smells like deprecation territory to me.
But I'm not really sure.
I'll wait for @andrewserong's keen layout eye.
Aside from that, it's doing what it say in the PR description 👍🏻
| // Temporary specificity bump until "wp-container" layout specificity is revisited. | ||
| .wp-block-post-template-is-layout-grid.wp-block-post-template-is-layout-grid.wp-block-post-template-is-layout-grid.wp-block-post-template-is-layout-grid { | ||
| // Legacy fallback for older grid layouts before responsive behaviour was implemented. | ||
| @media (max-width: $break-small) { |
Member
There was a problem hiding this comment.
Nit: reinstate spaces @media ( max-width: $break-small )
Contributor
Author
There was a problem hiding this comment.
We don't use spaces in scss files though. If there's anywhere we do it's an accident.
Comment on lines
+299
to
+301
| const hasLayoutChanged = | ||
| JSON.stringify( previousLayoutRef.current ) !== | ||
| JSON.stringify( layout ); |
Member
There was a problem hiding this comment.
I don't know if it matters, but this will return false if the order of properties ever changes.
fastDeepEqual is in the package I think. It compares values.
fastDeepEqual( previous, current )
| "postType" | ||
| ], | ||
| "attributes": { | ||
| "hasOptionalResponsiveGrid": { |
Member
There was a problem hiding this comment.
Just so I understand, when true, this attribute means something like "this block should not use the old behavior" (adds :not(.has-optional-responsive-grid))?
Is hasOptionalResponsiveGrid purely for internal/backwards compatibility, or will it relate to a user-facing toggle later?
If for the latter, I think the naming makes sense since it sounds like user facing controls. 👍🏻
If not, maybe hasCustomizedGridLayout to described the state?
Contributor
Author
There was a problem hiding this comment.
Purely internal but it is linked to an added classname so best if they both match. Not sure where we should classify classnames as user facing though 😄
Ideally the name describes the purpose of the attribute/class but I'm pretty terrible at naming lol. hasUpdatedResponsiveGrid may be better? I doubt we'll use this attribute in any other block because the problem is specific to post template.
| } | ||
|
|
||
| previousLayoutRef.current = layout; | ||
| }, [ hasOptionalResponsiveGrid, layout, layoutType, setAttributes ] ); |
Member
There was a problem hiding this comment.
A bit weird that exhaustive-deps required layoutType when it's a prop of layout anyway.
Oh well
|
|
||
| if ( | ||
| hasLayoutChanged && | ||
| layoutType === 'grid' && |
Member
There was a problem hiding this comment.
So if I change my columns count from 3 to 4 or interact with the grid in any way, I'm flipped from the legacy behaviour, right?
|
The following accounts have interacted with this PR and/or linked issues. I will continue to update these lists as activity occurs. You can also manually ask me to refresh this list by adding the If you're merging code through a pull request on GitHub, copy and paste the following into the bottom of the merge commit message. To understand the WordPress project's expectations around crediting contributors, please review the Contributor Attribution page in the Core Handbook. |
Contributor
Author
I don't think it would be possible to deprecate in this case, because it's a CSS declaration that we want to remove. We can't simply remove it because of back compat, but we need to make sure it doesn't apply to new or edited blocks. |
Member
Oh dang. I was thinking the new version could add a classname or something that overrode the deprecated block's styles. |
Contributor
Author
It does! But we don't want to change things for old blocks unless people edit their layout explicitly. |
Contributor
andrewserong
left a comment
andrewserong
left a comment
There was a problem hiding this comment.
Apologies for the very late reply, I must have missed this PR while travelling!
This might be a naive thought, but I'm wondering if we could avoid introducing the attribute and useEffect entirely if we dynamically inject the classname based on the presence of both columnCount and minimumColumnWidth. Would something like that work?
Basically, I'm wondering if there's a combination of attributes present in the layout object that we can use as an implicit signal that the utility-like classname should be present 🤔
Contributor
Author
Ooooh that would be a neater approach! I'll look into it, thanks! |
Contributor
Author
|
I did a new PR: #77411 so we can compare both approaches. |
Contributor
Author
|
Closing in favour of #77411. |
This file contains hidden or 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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
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.
What?
In order to solve #34145 we should be able to use the existing grid controls to enabled or disable responsive behaviour. The problem is that, at the time Post Template was switched to using grid layout, grid wasn't responsive by default, so a CSS fallback was added to preserve the previous behaviour (which was based on a custom flex implementation).
Ideally, we'd remove that CSS fallback and just use grid controls going forward.
However, this raises back compat issues, namely for websites using a Post template with a specific
columnCountand relying on those fallback styles for their responsive behaviour, given that grids defined withcolumnCountweren't previously responsive by default.In this PR I'm addressing that problem by way of a new attribute that flags a newly-added Post template block with grid layout or a block where the grid layout has been adjusted and contains a
columnCount.If that attribute doesn't exist and the layout contains a
columnCount, the fallback styles will be applied. This way nothing should change for existing websites, while newly-added blocks, or editing the layout of existing blocks will unlock the new responsive possibilities.This will solve #34145 by ensuring newly-added or edited blocks with
columnCountdon't have the fallback styles, so they aren't forced to be responsive.Testing Instructions
columnCountis defined.minimumColumnWidthto 0px while maintaining thecolumnCountdefined.has-optional-responsive-gridis now added to the Post template.While I don't love adding a new attribute and classname just to ensure that layout works sensibly in this block, I can't think of a better way of ensuring the fallback styles are present for back compat while not being there for new or edited blocks 🤷