Product Collection Layout Control Changes #47437
Replies: 2 comments 4 replies
-
|
We have previously dealt with this problem in Composite Products and Product Bundles, where product collections are often embedded in wrappers that are themselves nested in columns. We know from end-users, site builders and theme creators that they need enough control to:
When users make this request, there is an important piece of information that is implied: In many scenarios, a solution based on screen breakpoints will fail, because it's the container of our grid that provides the constraints; and its width cannot be known. Minimum and maximum column sizes are only meaningful relative to some container width thresholds (top and bottom). To directly serve the user/developer needs we've identified, I believe that the most intuitive approach would be to surface two options
....which users understand intuitively. For example:
All that said...
I agree with this. Rolling out a custom solution for Woo does not seem tenable to me. What's crucial here is that we help Gutenberg developers better understand user needs, and help them implement a more flexible solution that doesn't require theme developers and site builders to write custom CSS -- or maintain it. Until we solve the problem at the block level, and for any type of grid (not just products!) the burden of it will be shifted to developers and builders. |
Beta Was this translation helpful? Give feedback.
-
Absolutely, and imo, I don't actually feel like manual mode really serves a purpose beyond "existing" for the sake of it.
As noted though, there is a draft PR adding that feature so this wouldn't be a permanent limitation. Given our L-2 WordPress compatibility policy, even if it was added to Gutenberg ahead of WordPress 6.6, we wouldn't be able to acknowledge it as the "default" until next year. (We can still utilize it we'd just be in a middle-ground where it didn't work in all WordPress versions we support.)
With that in mind, how would you proceed moving forward? Should we just not support block spacing as a configuration option until we can support the same responsive columns that we have now? |
Beta Was this translation helpful? Give feedback.
-
What do you mean with “predefined, hardcoded, but filterable”?
I might be misunderstanding here, but I'm not too sure I entirely agree with that. Given the recent proposal by @joshuatf (pcShBQ-1LM-p2), I think it is acceptable for us to move forward with having the cake and eat it too. Like @ObliviousHarmony has said, we are bound by the L-2 compatibility policy, and we might feel like we have to decide whether we want the block spacing (and all the other nice things that come with it) and renounce to responsiveness, or the responsiveness and fall behind in Gutenberg standards. My suggestion here is that we follow the process proposed by @joshuatf: we align as much as possible with Gutenberg and core folks on how the feature will look like (given that there seems to be interest in adding such a feature), and duplicate the code in Woo in a compatibility layer that can be removed when the support policy expires. In this specific case, it would be also interesting to see if we can somehow accelerate the process: I suppose there is some kind of public API (e.g. the attribute ids, I think?), but I wonder if we necessarily have to wait for merge, or can just get away with waiting for consensus on those. Don't have a strong opinion about that, but my 2c are just that this doesn't have to be an either/or kind of situation. |
Beta Was this translation helpful? Give feedback.
-
|
I'm with @sunyatasattva on this one. At least in theory we should be able to finalise the migration and have a missing feature (max number of columns). Obviously, the prerequisite would be to agree on and finalise the upstream contribution so we can use exactly same API agreed upstream (for easier switch from "local" implementation to Gutenberg's one in a year or so). In practice though, I'm not exactly sure how hard (or easy) it is to extend the Gutenberg's layout support in our repo, so it does provide the required feature. Would we use a But in any case I see a sentiment from @manospsyx that the ability to set max number of columns is a must (and I tend to agree!). Having said that, I think we should explore option provided by @sunyatasattva. In ideal scenario we don't introduce any regression and that means I vote for this issue not to be included in "Remove Beta Label" epic. |
Beta Was this translation helpful? Give feedback.
-
= defined in code, not exposed as a UI option, but override-able by developers. wow... cc @xristos3490 |
Beta Was this translation helpful? Give feedback.
-
Yes. Work towards this for sure.
Will this impact stores that have already implemented custom styling targeting these CSS classes? If so, it's not necessarily a blocker but does need to be accounted for. |
Beta Was this translation helpful? Give feedback.
-
Background
In WordPress/gutenberg#49050 Gutenberg's Query Loop block migrated from the custom
displayLayoutattribute tosupports.layoutto support block spacing. Thelayoutfeature has a number of different display modes and utilizing this allows the Query Loop block to automatically benefit from future improvements. Thegridtype, for example, powers the Grid block and all of the neat features that come with it.Someone requested that the Product Collection block also support block spacing, and as a result, I took a look at making the same change as Gutenberg in #46255. I discovered that
supports.layoutdoes not currently provide the same kind of responsiveness that the Product Collection block does and as a result we need to make a decision about how to move forward.Design Change
The
gridlayout type only supports two (mutually exclusive) configuration options:While there is support for responsiveness, the Product Collection block currently uses a maximum column count with a hard-coded minimum width of 150px. I do, however, want to highlight that there is a draft PR open that adds support for setting a maximum column count. While this means in the future we would have support for this automatically re-introduced, for now, we would be removing that feature from the Product Collection block.
As an added bonus, by using
supports.layout, all of the built-in supported layout theme features would work with the Product Collection block!Alternatives
Before continuing I would like to highlight the alternatives I've looked at:
Custom Block Spacing Support
One thing worth noting is that supporting block spacing means we can't use CSS classes for column divisions anymore. A caveat to CSS Grid is that the
gapproperty is not excluded when setting the width. You need to explicitly subtract it from the column width yourself. As a consequence we need to generate runtime styles for the template block. We should also be thinking about theme support and add any necessary options for that as well.At that point we are essentially just reinventing the wheel and doing the same work that
supports.layoutdoes. This seems heavy-handed just to have this one small difference. I haven't dove too far down this route, however, there also looks like there might be problems with inner block layouts which can inherit some options from their parents. We could see this as a polyfill but this is the only block we would use it with.Custom Style Overrides
We could inject our own styles to override the column count. This would let us use
supports.layoutwhile still having the same style of responsiveness. The danger here though is that it means future changes tolayoutmight break our custom styles. Personally, I think usingsupports.layoutis an all-or-nothing situation.Requested Feedback
In the interest of moving this forward, the only real point of contention is around the change in responsiveness. The goal of a "responsive" Product Collection is to have the number of columns change based on the size of the container. In my opinion, it doesn't really matter whether or not there is a maximum that you can set. With that said, it does look like this would be a feature coming in the future from Gutenberg (ergo, a future WordPress version).
What do you folks think?
Beta Was this translation helpful? Give feedback.
All reactions