Product Template: added blockgap support #59940
Open
Conversation
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
|
It seems like we are using a custom implementation of the grid layout and that makes core's block spacing impossible to use... |
MaggieCabrera
commented
Jul 23, 2025
| @@ -45,7 +45,12 @@ $min-product-width: 150px; | |||
|
|
|||
| &__responsive { | |||
| display: grid; | |||
| grid-gap: $grid-gap; | |||
| gap: $grid-gap; // Use modern 'gap' instead of 'grid-gap' | |||
There was a problem hiding this comment.
this is to be in line with what core is using
|
I made it work for the grid option, but if you select a gap bigger than the 1.5em by default it breaks the columns settings. I'm going on a break so anyone feel free to pick this one up, else I'll have a look at that once I'm back. |
e84834b to
1c130f4
Compare
📝 WalkthroughWalkthroughThe changes introduce enhanced spacing controls for the WooCommerce product-template block. Block configuration, PHP rendering, React component logic, and CSS are updated to support dynamic margin, padding, and block gap spacing. New logic handles CSS custom properties for spacing, and fallback mechanisms are provided for older browsers and default values. Changes
Sequence Diagram(s)sequenceDiagram
participant Editor as Block Editor (React)
participant BlockJSON as block.json
participant PHP as PHP Render
participant CSS as CSS/SCSS
Editor->>BlockJSON: Reads block supports (spacing: margin, padding, blockGap)
Editor->>Editor: User sets spacing in block controls
Editor->>Editor: edit.tsx computes gap value, sets inline style & CSS variable
Editor->>PHP: Saves block attributes (including spacing)
PHP->>PHP: ProductTemplate.php builds wrapper with gap styles/custom property
PHP->>CSS: Outputs HTML with style attributes and CSS variable
CSS->>CSS: Uses --wc-product-template-gap for gap and width calculations
CSS->>CSS: Falls back to default or grid-gap for unsupported browsers
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~15 minutes Note 🔌 MCP (Model Context Protocol) integration is now available in Early Access!Pro users can now connect to remote MCP servers under the Integrations page to get reviews and chat conversations that understand additional development context. 📜 Recent review detailsConfiguration used: .coderabbit.yml 📒 Files selected for processing (1)
✅ Files skipped from review due to trivial changes (1)
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (27)
✨ Finishing Touches🧪 Generate unit tests
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. 🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
SupportNeed help? Create a ticket on our support page for assistance with any issues or questions. CodeRabbit Commands (Invoked using PR comments)
Other keywords and placeholders
Documentation and Community
|
Testing GuidelinesHi @mikejolley @kmanijak , Apart from reviewing the code changes, please make sure to review the testing instructions (Guide) and verify that relevant tests (E2E, Unit, Integration, etc.) have been added or updated as needed. Reminder: PR reviewers are required to document testing performed. This includes:
|
|
Size Change: +244 B (0%) Total Size: 5.92 MB
|
Test using WordPress PlaygroundThe changes in this pull request can be previewed and tested using a WordPress Playground instance. Test this pull request with WordPress Playground. Note that this URL is valid for 30 days from when this comment was last updated. You can update it by closing/reopening the PR or pushing a new commit. |
There was a problem hiding this comment.
Actionable comments posted: 3
🧹 Nitpick comments (3)
plugins/woocommerce/client/blocks/assets/js/blocks/product-template/style.scss (1)
40-41: Variable not reused in grid calculation.
width:is now calculated withvar(--wc-product-template-gap, 1.25em)which is great, but the responsive-grid branch below still hard-codes$grid-gap. Using the same custom property would keep gap values consistent when the user changes the block gap.- $grid-gap: 1.25em; + $grid-gap: var(--wc-product-template-gap, 1.25em);plugins/woocommerce/src/Blocks/Utils/StyleAttributesUtils.php (1)
602-620: Missing custom property for flex math.
get_block_gap_class_and_style()returns onlygap:. For flex layouts the width formula in SCSS relies on--wc-product-template-gap. That variable is later appended inProductTemplate.php, but any other block that re-uses this helper will silently miss it.Expose the variable here to keep utility self-contained:
return array( 'class' => null, 'style' => sprintf( 'gap:%1$s; --wc-product-template-gap:%1$s;', self::get_spacing_value( $block_gap ) ), );plugins/woocommerce/src/Blocks/BlockTypes/ProductTemplate.php (1)
90-98: Flow layout gap not reflected in the editor.The server adds
gap:for list/flow layouts, but the React editor code adds it only for flex. This will cause a WYSIWYG mismatch.Either inject the style here for all layouts or let the editor component handle it consistently.
📜 Review details
Configuration used: .coderabbit.yml
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (5)
plugins/woocommerce/client/blocks/assets/js/blocks/product-template/block.json(1 hunks)plugins/woocommerce/client/blocks/assets/js/blocks/product-template/edit.tsx(2 hunks)plugins/woocommerce/client/blocks/assets/js/blocks/product-template/style.scss(2 hunks)plugins/woocommerce/src/Blocks/BlockTypes/ProductTemplate.php(2 hunks)plugins/woocommerce/src/Blocks/Utils/StyleAttributesUtils.php(2 hunks)
🧰 Additional context used
📓 Path-based instructions (2)
**/*.{php,js,jsx,ts,tsx}
📄 CodeRabbit Inference Engine (.cursor/rules/code-quality.mdc)
**/*.{php,js,jsx,ts,tsx}: Guard against unexpected inputs
Sanitize and validate any potentially dangerous inputs
Ensure code is backwards compatible
Write code that is readable and intuitive
Ensure code has unit or E2E tests where applicable
Files:
plugins/woocommerce/src/Blocks/BlockTypes/ProductTemplate.phpplugins/woocommerce/src/Blocks/Utils/StyleAttributesUtils.phpplugins/woocommerce/client/blocks/assets/js/blocks/product-template/edit.tsx
**/*.{php,js,ts,jsx,tsx}
⚙️ CodeRabbit Configuration File
**/*.{php,js,ts,jsx,tsx}: Don't trust that extension developers will follow the best practices, make sure the code:
- Guards against unexpected inputs.
- Sanitizes and validates any potentially dangerous inputs.
- Is backwards compatible.
- Is readable and intuitive.
- Has unit or E2E tests where applicable.
Files:
plugins/woocommerce/src/Blocks/BlockTypes/ProductTemplate.phpplugins/woocommerce/src/Blocks/Utils/StyleAttributesUtils.phpplugins/woocommerce/client/blocks/assets/js/blocks/product-template/edit.tsx
🧠 Learnings (19)
📓 Common learnings
Learnt from: gigitux
PR: woocommerce/woocommerce#58902
File: plugins/woocommerce/client/blocks/assets/js/blocks/product-specifications/edit.tsx:205-206
Timestamp: 2025-06-17T12:40:54.118Z
Learning: In WordPress blocks, when there's a styling mismatch between editor and frontend, check if the PHP renderer (like in `ProductSpecifications.php`) adds specific classes to the output. If so, add those same classes to the `useBlockProps` className in the editor component (like in `edit.tsx`) to ensure consistent styling. For example, adding `wp-block-table` class to both frontend and editor ensures core table styles and theme customizations apply consistently.
Learnt from: samueljseay
PR: woocommerce/woocommerce#59142
File: plugins/woocommerce/src/Blocks/BlockTypes/MiniCart.php:594-602
Timestamp: 2025-06-25T06:51:41.381Z
Learning: WooCommerce block templates have a predictable structure where each block has one top-level div with wp-block-woocommerce- class containing arbitrary nested content that should be preserved.
Learnt from: samueljseay
PR: woocommerce/woocommerce#58716
File: plugins/woocommerce/client/blocks/assets/js/blocks/mini-cart/iapi-frontend.ts:83-101
Timestamp: 2025-06-17T07:07:53.443Z
Learning: In WooCommerce blocks, when porting existing code patterns that have known issues (like parseInt truncating decimal money values), maintain consistency with existing implementation rather than making isolated fixes. The preference is for systematic refactoring approaches (like broader Dinero adoption) over piecemeal changes.
Learnt from: lysyjan
PR: woocommerce/woocommerce#59070
File: packages/php/email-editor/src/Integrations/Core/class-initializer.php:103-141
Timestamp: 2025-06-23T16:55:58.246Z
Learning: The core/spacer block in the WooCommerce email editor intentionally does not have a dedicated renderer class and is handled by the fallback renderer instead of having an explicit render_email_callback assigned in the switch statement.
Learnt from: lysyjan
PR: woocommerce/woocommerce#59632
File: packages/js/email-editor/src/layouts/flex-email.tsx:116-122
Timestamp: 2025-07-14T10:41:46.200Z
Learning: In WooCommerce projects, formatting suggestions should respect the project's Prettier configuration and linting rules. Changes that would break the lint job should be avoided, even if they appear to improve readability.
Learnt from: Aljullu
PR: woocommerce/woocommerce#59370
File: plugins/woocommerce/client/blocks/assets/js/blocks/product-gallery/style.scss:236-243
Timestamp: 2025-07-03T10:09:20.635Z
Learning: In WooCommerce blocks CSS, prefer using standard CSS properties like `scrollbar-width` over vendor-specific prefixes when the standard property has good browser support. As of late 2024, `scrollbar-width` is widely supported across all major browsers and doesn't require WebKit-specific workarounds.
Learnt from: Aljullu
PR: woocommerce/woocommerce#58809
File: plugins/woocommerce/src/Blocks/BlockTypes/ProductButton.php:222-225
Timestamp: 2025-06-13T17:11:13.732Z
Learning: In `plugins/woocommerce/src/Blocks/BlockTypes/ProductButton.php`, the team intentionally relies on toggling the `disabled` CSS class (via `data-wp-class--disabled`) instead of binding the `disabled` attribute, to mirror the behavior of the classic WooCommerce template.
Learnt from: ralucaStan
PR: woocommerce/woocommerce#58782
File: plugins/woocommerce/client/blocks/assets/js/base/components/cart-checkout/product-details/style.scss:21-26
Timestamp: 2025-06-13T15:24:45.923Z
Learning: In WooCommerce blocks, bold styling for `.wc-block-components-product-details__name` should be scoped only to the Cart block (`.wc-block-cart__main`); on the Checkout block, product names are not bold because prices are highlighted instead.
Learnt from: ralucaStan
PR: woocommerce/woocommerce#58782
File: plugins/woocommerce/client/blocks/assets/js/base/utils/render-frontend.tsx:0-0
Timestamp: 2025-06-16T16:12:12.148Z
Learning: For WooCommerce checkout blocks, lazy loading was removed in favor of direct imports to prevent sequential "popping" effects during component loading. This approach prioritizes user experience over code splitting, with minimal bundle size impact and improved performance (1.7s to 1.1s speed score improvement). The checkout flow benefits from having all components load together rather than incrementally.
Learnt from: nerrad
PR: woocommerce/woocommerce#60176
File: plugins/woocommerce/client/legacy/css/admin.scss:9088-9105
Timestamp: 2025-08-04T00:21:51.440Z
Learning: WooCommerce is currently in the midst of an admin redesign project, so temporary/short-term CSS solutions for admin pages are preferred over long-term refactoring when addressing immediate needs.
Learnt from: kmanijak
PR: woocommerce/woocommerce#60154
File: plugins/woocommerce/client/blocks/assets/js/blocks/next-previous-buttons/edit.tsx:80-80
Timestamp: 2025-08-04T11:58:34.139Z
Learning: In WooCommerce block Edit components (like plugins/woocommerce/client/blocks/assets/js/blocks/next-previous-buttons/edit.tsx), buttons are preview/display elements for the block editor interface and are not meant to be interactive, so accessibility attributes like ARIA labels are not necessary for these non-functional preview buttons.
📚 Learning: 2025-06-25T06:51:41.381Z
Learnt from: samueljseay
PR: woocommerce/woocommerce#59142
File: plugins/woocommerce/src/Blocks/BlockTypes/MiniCart.php:594-602
Timestamp: 2025-06-25T06:51:41.381Z
Learning: WooCommerce block templates have a predictable structure where each block has one top-level div with wp-block-woocommerce- class containing arbitrary nested content that should be preserved.
Applied to files:
plugins/woocommerce/client/blocks/assets/js/blocks/product-template/block.jsonplugins/woocommerce/src/Blocks/BlockTypes/ProductTemplate.phpplugins/woocommerce/client/blocks/assets/js/blocks/product-template/style.scssplugins/woocommerce/src/Blocks/Utils/StyleAttributesUtils.phpplugins/woocommerce/client/blocks/assets/js/blocks/product-template/edit.tsx
📚 Learning: 2025-07-28T07:20:49.002Z
Learnt from: Aljullu
PR: woocommerce/woocommerce#60045
File: plugins/woocommerce/src/Blocks/BlockTypes/ProductGalleryThumbnails.php:68-68
Timestamp: 2025-07-28T07:20:49.002Z
Learning: WordPress block.json files support JSON schema pattern validation for string attributes using the "pattern" property with regular expression syntax, which provides client-side validation in the block editor.
Applied to files:
plugins/woocommerce/client/blocks/assets/js/blocks/product-template/block.json
📚 Learning: 2025-07-24T05:37:00.907Z
Learnt from: dinhtungdu
PR: woocommerce/woocommerce#59900
File: plugins/woocommerce/client/blocks/assets/js/blocks/product-filters/inner-blocks/attribute-filter/inspector.tsx:0-0
Timestamp: 2025-07-24T05:37:00.907Z
Learning: The DisplayStyleSwitcher component in plugins/woocommerce/client/blocks/assets/js/blocks/product-filters/components/display-style-switcher/index.tsx has been updated so that its onChange prop accepts only a string type (not string | number | undefined), eliminating the need for type assertions when using this component.
Applied to files:
plugins/woocommerce/client/blocks/assets/js/blocks/product-template/block.jsonplugins/woocommerce/src/Blocks/BlockTypes/ProductTemplate.phpplugins/woocommerce/client/blocks/assets/js/blocks/product-template/style.scssplugins/woocommerce/client/blocks/assets/js/blocks/product-template/edit.tsx
📚 Learning: 2025-06-13T15:24:45.923Z
Learnt from: ralucaStan
PR: woocommerce/woocommerce#58782
File: plugins/woocommerce/client/blocks/assets/js/base/components/cart-checkout/product-details/style.scss:21-26
Timestamp: 2025-06-13T15:24:45.923Z
Learning: In WooCommerce blocks, bold styling for `.wc-block-components-product-details__name` should be scoped only to the Cart block (`.wc-block-cart__main`); on the Checkout block, product names are not bold because prices are highlighted instead.
Applied to files:
plugins/woocommerce/client/blocks/assets/js/blocks/product-template/block.jsonplugins/woocommerce/src/Blocks/BlockTypes/ProductTemplate.phpplugins/woocommerce/client/blocks/assets/js/blocks/product-template/style.scssplugins/woocommerce/client/blocks/assets/js/blocks/product-template/edit.tsx
📚 Learning: 2025-07-03T10:09:20.635Z
Learnt from: Aljullu
PR: woocommerce/woocommerce#59370
File: plugins/woocommerce/client/blocks/assets/js/blocks/product-gallery/style.scss:236-243
Timestamp: 2025-07-03T10:09:20.635Z
Learning: In WooCommerce blocks CSS, prefer using standard CSS properties like `scrollbar-width` over vendor-specific prefixes when the standard property has good browser support. As of late 2024, `scrollbar-width` is widely supported across all major browsers and doesn't require WebKit-specific workarounds.
Applied to files:
plugins/woocommerce/client/blocks/assets/js/blocks/product-template/block.jsonplugins/woocommerce/src/Blocks/BlockTypes/ProductTemplate.phpplugins/woocommerce/client/blocks/assets/js/blocks/product-template/style.scssplugins/woocommerce/src/Blocks/Utils/StyleAttributesUtils.phpplugins/woocommerce/client/blocks/assets/js/blocks/product-template/edit.tsx
📚 Learning: 2025-06-17T12:40:54.118Z
Learnt from: gigitux
PR: woocommerce/woocommerce#58902
File: plugins/woocommerce/client/blocks/assets/js/blocks/product-specifications/edit.tsx:205-206
Timestamp: 2025-06-17T12:40:54.118Z
Learning: In WordPress blocks, when there's a styling mismatch between editor and frontend, check if the PHP renderer (like in `ProductSpecifications.php`) adds specific classes to the output. If so, add those same classes to the `useBlockProps` className in the editor component (like in `edit.tsx`) to ensure consistent styling. For example, adding `wp-block-table` class to both frontend and editor ensures core table styles and theme customizations apply consistently.
Applied to files:
plugins/woocommerce/client/blocks/assets/js/blocks/product-template/block.jsonplugins/woocommerce/src/Blocks/BlockTypes/ProductTemplate.phpplugins/woocommerce/client/blocks/assets/js/blocks/product-template/style.scssplugins/woocommerce/src/Blocks/Utils/StyleAttributesUtils.phpplugins/woocommerce/client/blocks/assets/js/blocks/product-template/edit.tsx
📚 Learning: 2025-06-17T07:07:53.443Z
Learnt from: samueljseay
PR: woocommerce/woocommerce#58716
File: plugins/woocommerce/client/blocks/assets/js/blocks/mini-cart/iapi-frontend.ts:83-101
Timestamp: 2025-06-17T07:07:53.443Z
Learning: In WooCommerce blocks, when porting existing code patterns that have known issues (like parseInt truncating decimal money values), maintain consistency with existing implementation rather than making isolated fixes. The preference is for systematic refactoring approaches (like broader Dinero adoption) over piecemeal changes.
Applied to files:
plugins/woocommerce/client/blocks/assets/js/blocks/product-template/block.jsonplugins/woocommerce/src/Blocks/BlockTypes/ProductTemplate.phpplugins/woocommerce/client/blocks/assets/js/blocks/product-template/style.scssplugins/woocommerce/client/blocks/assets/js/blocks/product-template/edit.tsx
📚 Learning: 2025-06-13T17:11:13.732Z
Learnt from: Aljullu
PR: woocommerce/woocommerce#58809
File: plugins/woocommerce/src/Blocks/BlockTypes/ProductButton.php:222-225
Timestamp: 2025-06-13T17:11:13.732Z
Learning: In `plugins/woocommerce/src/Blocks/BlockTypes/ProductButton.php`, the team intentionally relies on toggling the `disabled` CSS class (via `data-wp-class--disabled`) instead of binding the `disabled` attribute, to mirror the behavior of the classic WooCommerce template.
Applied to files:
plugins/woocommerce/client/blocks/assets/js/blocks/product-template/block.jsonplugins/woocommerce/src/Blocks/BlockTypes/ProductTemplate.phpplugins/woocommerce/client/blocks/assets/js/blocks/product-template/style.scssplugins/woocommerce/src/Blocks/Utils/StyleAttributesUtils.phpplugins/woocommerce/client/blocks/assets/js/blocks/product-template/edit.tsx
📚 Learning: 2025-08-04T11:58:34.139Z
Learnt from: kmanijak
PR: woocommerce/woocommerce#60154
File: plugins/woocommerce/client/blocks/assets/js/blocks/next-previous-buttons/edit.tsx:80-80
Timestamp: 2025-08-04T11:58:34.139Z
Learning: In WooCommerce block Edit components (like plugins/woocommerce/client/blocks/assets/js/blocks/next-previous-buttons/edit.tsx), buttons are preview/display elements for the block editor interface and are not meant to be interactive, so accessibility attributes like ARIA labels are not necessary for these non-functional preview buttons.
Applied to files:
plugins/woocommerce/client/blocks/assets/js/blocks/product-template/block.jsonplugins/woocommerce/src/Blocks/BlockTypes/ProductTemplate.phpplugins/woocommerce/client/blocks/assets/js/blocks/product-template/edit.tsx
📚 Learning: 2025-06-23T05:47:52.696Z
Learnt from: samueljseay
PR: woocommerce/woocommerce#59051
File: plugins/woocommerce/client/blocks/assets/js/blocks/mini-cart/mini-cart-contents/inner-blocks/mini-cart-footer-block/index.tsx:66-70
Timestamp: 2025-06-23T05:47:52.696Z
Learning: For WooCommerce mini-cart blocks in plugins/woocommerce/client/blocks/assets/js/blocks/mini-cart/, the standardized conditional pattern for experimental features should be `if ( isExperimentalMiniCartEnabled() ) { blockSettings.save = () => <InnerBlocks.Content />; }` - defaulting to the traditional Save component and only overriding when the experimental feature is enabled.
Applied to files:
plugins/woocommerce/client/blocks/assets/js/blocks/product-template/block.jsonplugins/woocommerce/src/Blocks/BlockTypes/ProductTemplate.phpplugins/woocommerce/client/blocks/assets/js/blocks/product-template/edit.tsx
📚 Learning: 2025-06-23T16:55:58.246Z
Learnt from: lysyjan
PR: woocommerce/woocommerce#59070
File: packages/php/email-editor/src/Integrations/Core/class-initializer.php:103-141
Timestamp: 2025-06-23T16:55:58.246Z
Learning: The core/spacer block in the WooCommerce email editor intentionally does not have a dedicated renderer class and is handled by the fallback renderer instead of having an explicit render_email_callback assigned in the switch statement.
Applied to files:
plugins/woocommerce/client/blocks/assets/js/blocks/product-template/block.jsonplugins/woocommerce/src/Blocks/BlockTypes/ProductTemplate.phpplugins/woocommerce/client/blocks/assets/js/blocks/product-template/edit.tsx
📚 Learning: 2025-06-26T14:25:08.421Z
Learnt from: NeosinneR
PR: woocommerce/woocommerce#0
File: :0-0
Timestamp: 2025-06-26T14:25:08.421Z
Learning: In WooCommerce transactional emails, product images have historically had display issues due to lazy loading attributes being applied, which email clients cannot process since they don't execute JavaScript. This issue existed in both old and new email templates, but became more visible with the new email template system. The fix involves preventing lazy loading on attachment images specifically during email generation by adding skip classes and data attributes.
Applied to files:
plugins/woocommerce/src/Blocks/BlockTypes/ProductTemplate.php
📚 Learning: 2025-07-22T09:30:43.528Z
Learnt from: gigitux
PR: woocommerce/woocommerce#59659
File: plugins/woocommerce/client/blocks/assets/js/blocks/add-to-cart-with-options/frontend.ts:136-147
Timestamp: 2025-07-22T09:30:43.528Z
Learning: In WooCommerce blocks TypeScript code, avoid type assertions (`as`) when accessing properties from unified stores. Instead, create proper union types that combine all the different store component types using `Partial<>` wrappers, and export the unified type to help third-party extenders. For example: `type UnifiedStore = BaseStore & Partial<StoreA> & Partial<StoreB>`.
Applied to files:
plugins/woocommerce/src/Blocks/BlockTypes/ProductTemplate.phpplugins/woocommerce/client/blocks/assets/js/blocks/product-template/edit.tsx
📚 Learning: 2025-08-04T14:32:56.289Z
Learnt from: dinhtungdu
PR: woocommerce/woocommerce#60144
File: plugins/woocommerce/client/blocks/assets/js/blocks/product-filters/inner-blocks/taxonomy-filter/edit.tsx:183-184
Timestamp: 2025-08-04T14:32:56.289Z
Learning: In WooCommerce taxonomy filter components like plugins/woocommerce/client/blocks/assets/js/blocks/product-filters/inner-blocks/taxonomy-filter/edit.tsx, taxonomy term objects fetched from WordPress core data APIs via getEntityRecords() have guaranteed structure and don't require additional validation for properties like term.id and term.parent since they come from trusted internal WordPress core data sources.
Applied to files:
plugins/woocommerce/src/Blocks/BlockTypes/ProductTemplate.php
📚 Learning: 2025-07-14T10:41:46.200Z
Learnt from: lysyjan
PR: woocommerce/woocommerce#59632
File: packages/js/email-editor/src/layouts/flex-email.tsx:116-122
Timestamp: 2025-07-14T10:41:46.200Z
Learning: In WooCommerce projects, formatting suggestions should respect the project's Prettier configuration and linting rules. Changes that would break the lint job should be avoided, even if they appear to improve readability.
Applied to files:
plugins/woocommerce/client/blocks/assets/js/blocks/product-template/style.scss
📚 Learning: 2025-06-20T17:38:16.565Z
Learnt from: opr
PR: woocommerce/woocommerce#0
File: :0-0
Timestamp: 2025-06-20T17:38:16.565Z
Learning: WooCommerce legacy JavaScript files in plugins/woocommerce/client/legacy/js/ must use older JavaScript syntax and cannot use modern features like optional chaining (?.) due to browser compatibility requirements. Explicit null checking with && operators should be used instead.
Applied to files:
plugins/woocommerce/client/blocks/assets/js/blocks/product-template/style.scss
📚 Learning: 2025-07-03T10:08:59.936Z
Learnt from: Aljullu
PR: woocommerce/woocommerce#59370
File: plugins/woocommerce/client/blocks/assets/js/blocks/product-gallery/style.scss:206-233
Timestamp: 2025-07-03T10:08:59.936Z
Learning: WooCommerce uses Autoprefixer in their PostCSS configuration (plugins/woocommerce/client/blocks/postcss.config.js) with WordPress' standard browserslist configuration (wordpress/browserslist-config) to automatically add vendor prefixes like -webkit-mask-image based on supported browsers, eliminating the need for manual prefix additions.
Applied to files:
plugins/woocommerce/client/blocks/assets/js/blocks/product-template/style.scss
📚 Learning: 2025-06-13T13:37:35.793Z
Learnt from: ralucaStan
PR: woocommerce/woocommerce#58782
File: plugins/woocommerce/client/blocks/assets/js/blocks/checkout/inner-blocks/checkout-shipping-address-block/customer-address.tsx:76-90
Timestamp: 2025-06-13T13:37:35.793Z
Learning: In plugins/woocommerce/client/blocks/assets/js/blocks/checkout/inner-blocks/checkout-shipping-address-block/customer-address.tsx, the `shouldAnimate` flag is expected to be `false` only on initial render and may remain `true` after the first edit; it does not need to be reset.
Applied to files:
plugins/woocommerce/client/blocks/assets/js/blocks/product-template/edit.tsx
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (27)
- GitHub Check: Blocks e2e tests 6/10 - @woocommerce/plugin-woocommerce [e2e]
- GitHub Check: Blocks e2e tests 10/10 - @woocommerce/plugin-woocommerce [e2e]
- GitHub Check: Blocks e2e tests 9/10 - @woocommerce/plugin-woocommerce [e2e]
- GitHub Check: Metrics - @woocommerce/plugin-woocommerce [performance]
- GitHub Check: Blocks e2e tests 8/10 - @woocommerce/plugin-woocommerce [e2e]
- GitHub Check: Blocks e2e tests 4/10 - @woocommerce/plugin-woocommerce [e2e]
- GitHub Check: Blocks e2e tests 5/10 - @woocommerce/plugin-woocommerce [e2e]
- GitHub Check: Blocks e2e tests 1/10 - @woocommerce/plugin-woocommerce [e2e]
- GitHub Check: Blocks e2e tests 3/10 - @woocommerce/plugin-woocommerce [e2e]
- GitHub Check: Blocks e2e tests 7/10 - @woocommerce/plugin-woocommerce [e2e]
- GitHub Check: Blocks e2e tests 2/10 - @woocommerce/plugin-woocommerce [e2e]
- GitHub Check: Core e2e tests 3/6 - @woocommerce/plugin-woocommerce [e2e]
- GitHub Check: Core API tests - @woocommerce/plugin-woocommerce [api]
- GitHub Check: Core e2e tests 4/6 - @woocommerce/plugin-woocommerce [e2e]
- GitHub Check: Core e2e tests 5/6 - @woocommerce/plugin-woocommerce [e2e]
- GitHub Check: Core e2e tests 6/6 - @woocommerce/plugin-woocommerce [e2e]
- GitHub Check: Core e2e tests 1/6 - @woocommerce/plugin-woocommerce [e2e]
- GitHub Check: Core e2e tests 2/6 - @woocommerce/plugin-woocommerce [e2e]
- GitHub Check: PHP: 7.4 WP: latest - 1 [WP 6.7.3] 1/2 - @woocommerce/plugin-woocommerce [unit:php]
- GitHub Check: PHP: 8.4 WP: latest [WP latest] 1/2 - @woocommerce/plugin-woocommerce [unit:php]
- GitHub Check: PHP: 7.4 WP: latest - 1 [WP 6.7.3] 2/2 - @woocommerce/plugin-woocommerce [unit:php]
- GitHub Check: JavaScript - @woocommerce/block-library [unit]
- GitHub Check: PHP: 8.4 WP: latest [WP latest] 2/2 - @woocommerce/plugin-woocommerce [unit:php]
- GitHub Check: Lint - @woocommerce/block-library
- GitHub Check: Lint - @woocommerce/plugin-woocommerce
- GitHub Check: build
- GitHub Check: Check Asset Sizes
🔇 Additional comments (4)
plugins/woocommerce/client/blocks/assets/js/blocks/product-template/block.json (1)
55-60: Validate JSON comma & WP spacing key.Double-check that the closing brace of
"layout"is followed by a comma before the new"spacing"object (some diff tools omit the trailing comma in previews). A missing comma would break the block registration and white-screen the editor.Also confirm Gutenberg still expects the camel-case key
"blockGap"inside"supports.spacing"for the WordPress version WooCommerce targets (it was added in WP 6.5).plugins/woocommerce/client/blocks/assets/js/blocks/product-template/style.scss (1)
49-54: Redundantgrid-gapfallback can be trimmed.
grid-gapis an alias ofgapin every browser that doesn’t support flex gap; adding it only inside an@supports not (gap…)block is fine, but you can drop the comment-only check – the rule is harmless on modern engines and simplifies the file.plugins/woocommerce/src/Blocks/Utils/StyleAttributesUtils.php (1)
784-785: Order of array keys may override consumer filters.Adding
'block_gap'in the middle of$classes_and_stylescan change CSS specificity if downstream filters relied on order. To stay back-compatible, append it after existing spacing keys (margin/padding).plugins/woocommerce/client/blocks/assets/js/blocks/product-template/edit.tsx (1)
376-380: Type-safety & preset parsing.Casting to
anydefeats TS; the attribute shape is already inBlockEditProps. Add a proper type forattributesand reuse the helper that exists in PHP to parse preset spacing (duplicate logic risk).[ suggest_optional_refactor ]
Comment on lines
+394
to
+399
| ...( hasLayoutFlex && gapValue ? { | ||
| gap: gapValue, | ||
| '--wc-product-template-gap': gapValue // Add CSS custom property for width calculations | ||
| } : {} ), | ||
| }, | ||
| }; |
There was a problem hiding this comment.
Gap missed for list/flow layouts.
hasLayoutFlex guards the gap style, so stack/list mode shows no spacing in the editor even though the front-end applies it. Removing the guard or extending the condition fixes visual parity.
- ...( hasLayoutFlex && gapValue ? {
+ ...( gapValue ? {📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
Suggested change
| ...( hasLayoutFlex && gapValue ? { | |
| gap: gapValue, | |
| '--wc-product-template-gap': gapValue // Add CSS custom property for width calculations | |
| } : {} ), | |
| }, | |
| }; | |
| ...( gapValue ? { | |
| gap: gapValue, | |
| '--wc-product-template-gap': gapValue // Add CSS custom property for width calculations | |
| } : {} ), |
🤖 Prompt for AI Agents
In plugins/woocommerce/client/blocks/assets/js/blocks/product-template/edit.tsx
around lines 394 to 399, the gap style is only applied when hasLayoutFlex is
true, causing no spacing in stack/list layouts in the editor. To fix this,
remove the hasLayoutFlex guard or extend the condition to also include list/flow
layouts so that the gap style and CSS custom property are applied consistently
in the editor and front-end.
| @@ -25,7 +25,7 @@ $min-product-width: 150px; | |||
| flex-direction: row; | |||
| display: flex; | |||
| flex-wrap: wrap; | |||
| gap: 1.25em; | |||
| gap: var(--wc-product-template-gap, 1.25em); | |||
There was a problem hiding this comment.
🛠️ Refactor suggestion
Flex gap lacks legacy fallback.
gap on flex containers isn’t supported in Safari ≤ 14 or some older Chromium builds. Previously we compensated with negative margins; now there’s no fallback, so older browsers will collapse product spacing.
Consider retaining the old margin‐based fallback behind @supports not (gap: 1em) to avoid regressions.
🤖 Prompt for AI Agents
In
plugins/woocommerce/client/blocks/assets/js/blocks/product-template/style.scss
at line 28, the use of the CSS gap property on flex containers lacks a fallback
for older browsers like Safari ≤ 14 that do not support gap. To fix this, wrap
the current gap declaration inside an @supports (gap: 1em) block and add a
fallback using negative margins on the container and corresponding positive
margins on the child elements inside an @supports not (gap: 1em) block to
preserve spacing in legacy browsers.
There was a problem hiding this comment.
This is what core uses to handle gap
There was a problem hiding this comment.
@MaggieCabrera Got it—let’s align with core and keep gap on flex without a negative-margin fallback. Retracting my earlier suggestion. The grid @supports fallback already present looks good.
✏️ Learnings added
Learnt from: MaggieCabrera
PR: woocommerce/woocommerce#59940
File: plugins/woocommerce/client/blocks/assets/js/blocks/product-template/style.scss:28-28
Timestamp: 2025-08-08T10:17:51.893Z
Learning: In WooCommerce blocks, follow WordPress core’s approach for spacing: use the standard CSS gap property on flex containers without adding negative-margin fallbacks. This is acceptable for .wc-block-product-template.is-flex-container in plugins/woocommerce/client/blocks/assets/js/blocks/product-template/style.scss, while grid may include a simple supports fallback (gap → grid-gap). Align with WP’s browserslist baseline and Autoprefixer setup.
Note: Learnings are effective only in the context of similar code segments. To apply general coding guidelines, please configure review instructions. You can manage existing learnings in the app.
🧠 Learnings used
Learnt from: Aljullu
PR: woocommerce/woocommerce#59370
File: plugins/woocommerce/client/blocks/assets/js/blocks/product-gallery/style.scss:236-243
Timestamp: 2025-07-03T10:09:20.635Z
Learning: In WooCommerce blocks CSS, prefer using standard CSS properties like `scrollbar-width` over vendor-specific prefixes when the standard property has good browser support. As of late 2024, `scrollbar-width` is widely supported across all major browsers and doesn't require WebKit-specific workarounds.
Learnt from: ralucaStan
PR: woocommerce/woocommerce#58782
File: plugins/woocommerce/client/blocks/assets/js/base/components/cart-checkout/product-details/style.scss:21-26
Timestamp: 2025-06-13T15:24:45.923Z
Learning: In WooCommerce blocks, bold styling for `.wc-block-components-product-details__name` should be scoped only to the Cart block (`.wc-block-cart__main`); on the Checkout block, product names are not bold because prices are highlighted instead.
Learnt from: Aljullu
PR: woocommerce/woocommerce#58809
File: plugins/woocommerce/src/Blocks/BlockTypes/ProductButton.php:222-225
Timestamp: 2025-06-13T17:11:13.732Z
Learning: In `plugins/woocommerce/src/Blocks/BlockTypes/ProductButton.php`, the team intentionally relies on toggling the `disabled` CSS class (via `data-wp-class--disabled`) instead of binding the `disabled` attribute, to mirror the behavior of the classic WooCommerce template.
Learnt from: samueljseay
PR: woocommerce/woocommerce#59142
File: plugins/woocommerce/src/Blocks/BlockTypes/MiniCart.php:594-602
Timestamp: 2025-06-25T06:51:41.381Z
Learning: WooCommerce block templates have a predictable structure where each block has one top-level div with wp-block-woocommerce- class containing arbitrary nested content that should be preserved.
Learnt from: samueljseay
PR: woocommerce/woocommerce#58716
File: plugins/woocommerce/client/blocks/assets/js/blocks/mini-cart/iapi-frontend.ts:83-101
Timestamp: 2025-06-17T07:07:53.443Z
Learning: In WooCommerce blocks, when porting existing code patterns that have known issues (like parseInt truncating decimal money values), maintain consistency with existing implementation rather than making isolated fixes. The preference is for systematic refactoring approaches (like broader Dinero adoption) over piecemeal changes.
Learnt from: samueljseay
PR: woocommerce/woocommerce#59051
File: plugins/woocommerce/client/blocks/assets/js/blocks/mini-cart/mini-cart-contents/inner-blocks/mini-cart-footer-block/index.tsx:66-70
Timestamp: 2025-06-23T05:47:52.696Z
Learning: For WooCommerce mini-cart blocks in plugins/woocommerce/client/blocks/assets/js/blocks/mini-cart/, the standardized conditional pattern for experimental features should be `if ( isExperimentalMiniCartEnabled() ) { blockSettings.save = () => <InnerBlocks.Content />; }` - defaulting to the traditional Save component and only overriding when the experimental feature is enabled.
Learnt from: kmanijak
PR: woocommerce/woocommerce#59307
File: plugins/woocommerce/client/blocks/assets/js/blocks/product-gallery/frontend.ts:55-84
Timestamp: 2025-07-02T08:03:45.727Z
Learning: In WooCommerce Product Gallery blocks on iOS (Safari and Chrome), scrollIntoView with inline: 'center' option is not supported for horizontal scrolling and requires manual scrollTo calculation, but scrollIntoView with block: 'center' for vertical scrolling works fine and doesn't need replacement.
Learnt from: lysyjan
PR: woocommerce/woocommerce#59632
File: packages/js/email-editor/src/layouts/flex-email.tsx:116-122
Timestamp: 2025-07-14T10:41:46.200Z
Learning: In WooCommerce projects, formatting suggestions should respect the project's Prettier configuration and linting rules. Changes that would break the lint job should be avoided, even if they appear to improve readability.
Learnt from: gigitux
PR: woocommerce/woocommerce#58902
File: plugins/woocommerce/client/blocks/assets/js/blocks/product-specifications/edit.tsx:205-206
Timestamp: 2025-06-17T12:40:54.118Z
Learning: In WordPress blocks, when there's a styling mismatch between editor and frontend, check if the PHP renderer (like in `ProductSpecifications.php`) adds specific classes to the output. If so, add those same classes to the `useBlockProps` className in the editor component (like in `edit.tsx`) to ensure consistent styling. For example, adding `wp-block-table` class to both frontend and editor ensures core table styles and theme customizations apply consistently.
Learnt from: dinhtungdu
PR: woocommerce/woocommerce#59900
File: plugins/woocommerce/client/blocks/assets/js/blocks/product-filters/inner-blocks/attribute-filter/inspector.tsx:0-0
Timestamp: 2025-07-24T05:37:00.907Z
Learning: The DisplayStyleSwitcher component in plugins/woocommerce/client/blocks/assets/js/blocks/product-filters/components/display-style-switcher/index.tsx has been updated so that its onChange prop accepts only a string type (not string | number | undefined), eliminating the need for type assertions when using this component.
Learnt from: opr
PR: woocommerce/woocommerce#0
File: :0-0
Timestamp: 2025-06-20T17:38:16.565Z
Learning: WooCommerce legacy JavaScript files in plugins/woocommerce/client/legacy/js/ must use older JavaScript syntax and cannot use modern features like optional chaining (?.) due to browser compatibility requirements. Explicit null checking with && operators should be used instead.
Learnt from: gigitux
PR: woocommerce/woocommerce#58785
File: plugins/woocommerce/client/blocks/package.json:0-0
Timestamp: 2025-06-17T10:25:36.686Z
Learning: Do not suggest using `cross-env` in the WooCommerce repository as it's deprecated/archived and the team is working to remove it from blocks commands to reduce the dependency tree. Instead, inline environment variables like `WP_EXPERIMENTAL_MODULES=true knip` should work fine in supported environments.
Learnt from: Aljullu
PR: woocommerce/woocommerce#59370
File: plugins/woocommerce/client/blocks/assets/js/blocks/product-gallery/style.scss:206-233
Timestamp: 2025-07-03T10:08:59.936Z
Learning: WooCommerce uses Autoprefixer in their PostCSS configuration (plugins/woocommerce/client/blocks/postcss.config.js) with WordPress' standard browserslist configuration (wordpress/browserslist-config) to automatically add vendor prefixes like -webkit-mask-image based on supported browsers, eliminating the need for manual prefix additions.
Learnt from: Aljullu
PR: woocommerce/woocommerce#59370
File: plugins/woocommerce/client/blocks/assets/js/blocks/product-gallery/style.scss:206-233
Timestamp: 2025-07-03T10:08:59.936Z
Learning: WooCommerce uses Autoprefixer in their PostCSS configuration (plugins/woocommerce/client/blocks/postcss.config.js) with WordPress' standard browserslist configuration (wordpress/browserslist-config) to automatically add vendor prefixes like -webkit-mask-image based on supported browsers, eliminating the need for manual prefix additions.
Learnt from: nerrad
PR: woocommerce/woocommerce#60176
File: plugins/woocommerce/client/legacy/css/admin.scss:9088-9105
Timestamp: 2025-08-04T00:21:51.440Z
Learning: WooCommerce is currently in the midst of an admin redesign project, so temporary/short-term CSS solutions for admin pages are preferred over long-term refactoring when addressing immediate needs.
Learnt from: ralucaStan
PR: woocommerce/woocommerce#58782
File: plugins/woocommerce/client/blocks/assets/js/base/utils/render-frontend.tsx:0-0
Timestamp: 2025-06-16T16:12:12.148Z
Learning: For WooCommerce checkout blocks, lazy loading was removed in favor of direct imports to prevent sequential "popping" effects during component loading. This approach prioritizes user experience over code splitting, with minimal bundle size impact and improved performance (1.7s to 1.1s speed score improvement). The checkout flow benefits from having all components load together rather than incrementally.
Learnt from: lysyjan
PR: woocommerce/woocommerce#59070
File: packages/php/email-editor/src/Integrations/Core/class-initializer.php:103-141
Timestamp: 2025-06-23T16:55:58.246Z
Learning: The core/spacer block in the WooCommerce email editor intentionally does not have a dedicated renderer class and is handled by the fallback renderer instead of having an explicit render_email_callback assigned in the switch statement.
Comment on lines
+82
to
+113
| // Build base attributes that are common to all layouts | ||
| $wrapper_attributes_array = array( | ||
| 'class' => trim( $classnames ), | ||
| 'data-wp-on--scroll' => 'actions.watchScroll', | ||
| 'data-wp-init' => 'callbacks.initResizeObserver', | ||
| ); | ||
|
|
||
| // Apply blockGap styles manually for flow layout | ||
| if ( isset( $block->context['displayLayout']['type'] ) && 'flow' === $block->context['displayLayout']['type'] ) { | ||
| $block_gap_styles = StyleAttributesUtils::get_classes_and_styles_by_attributes( $attributes, [ 'block_gap' ] ); | ||
|
|
||
| // Apply blockGap styles if they exist | ||
| if ( ! empty( $block_gap_styles['styles'] ) ) { | ||
| $wrapper_attributes_array['style'] = $block_gap_styles['styles']; | ||
| } | ||
| } | ||
|
|
||
| // Apply blockGap styles for flex layout to enable dynamic width calculations | ||
| if ( isset( $block->context['displayLayout']['type'] ) && 'flex' === $block->context['displayLayout']['type'] ) { | ||
| $block_gap_styles = StyleAttributesUtils::get_classes_and_styles_by_attributes( $attributes, [ 'block_gap' ] ); | ||
|
|
||
| // Apply blockGap styles if they exist | ||
| if ( ! empty( $block_gap_styles['styles'] ) ) { | ||
| $wrapper_attributes_array['style'] = $block_gap_styles['styles']; | ||
| } | ||
|
|
||
| // Add CSS custom property for width calculations | ||
| $gap_value = StyleAttributesUtils::get_spacing_value( $attributes['style']['spacing']['blockGap'] ?? '1.25em' ); | ||
| $wrapper_attributes_array['style'] = ( $wrapper_attributes_array['style'] ?? '' ) . ' --wc-product-template-gap: ' . $gap_value . ';'; | ||
| } | ||
|
|
||
| $wrapper_attributes = get_block_wrapper_attributes( $wrapper_attributes_array ); |
There was a problem hiding this comment.
Style string overwritten twice – later assignments drop earlier styles.
$wrapper_attributes_array['style'] is set for block gap, then concatenated for the custom property. If another support (e.g. background color) already injected a style earlier in execution, it is lost.
Safer pattern:
$wrapper_attributes_array['style'] = trim(
( $wrapper_attributes_array['style'] ?? '' ) .
( $block_gap_styles['styles'] ?? '' ) .
" --wc-product-template-gap: $gap_value;"
);Prevents clobbering and avoids duplicated whitespace.
🤖 Prompt for AI Agents
In plugins/woocommerce/src/Blocks/BlockTypes/ProductTemplate.php between lines
82 and 113, the style string in $wrapper_attributes_array['style'] is
overwritten multiple times, causing earlier styles to be lost. To fix this,
concatenate all style strings safely by appending new styles to the existing
string instead of overwriting it. Use a pattern that combines the existing style
string, the block gap styles, and the custom property into one trimmed string to
prevent clobbering and duplicated whitespace.
There was a problem hiding this comment.
@scruffian Great — I’ll adjust the style handling to concatenate instead of overwrite. Here’s the minimal change for both branches:
// Apply blockGap styles manually for flow layout
if ( isset( $block->context['displayLayout']['type'] ) && 'flow' === $block->context['displayLayout']['type'] ) {
$block_gap_styles = StyleAttributesUtils::get_classes_and_styles_by_attributes( $attributes, array( 'block_gap' ) );
$wrapper_attributes_array['style'] = trim(
( $wrapper_attributes_array['style'] ?? '' ) .
( ! empty( $block_gap_styles['styles'] ) ? ' ' . $block_gap_styles['styles'] : '' )
);
}
// Apply blockGap styles for flex layout to enable dynamic width calculations
if ( isset( $block->context['displayLayout']['type'] ) && 'flex' === $block->context['displayLayout']['type'] ) {
$block_gap_styles = StyleAttributesUtils::get_classes_and_styles_by_attributes( $attributes, array( 'block_gap' ) );
$gap_value = StyleAttributesUtils::get_spacing_value( $attributes['style']['spacing']['blockGap'] ?? '1.25em' );
$wrapper_attributes_array['style'] = trim(
( $wrapper_attributes_array['style'] ?? '' ) .
( ! empty( $block_gap_styles['styles'] ) ? ' ' . $block_gap_styles['styles'] : '' ) .
' --wc-product-template-gap: ' . $gap_value . ';'
);
}This preserves any pre-existing inline styles and avoids clobbering while ensuring the custom property is always appended for flex.
(＾▽＾)／
🧠 Learnings used
Learnt from: samueljseay
PR: woocommerce/woocommerce#59142
File: plugins/woocommerce/src/Blocks/BlockTypes/MiniCart.php:594-602
Timestamp: 2025-06-25T06:51:41.381Z
Learning: WooCommerce block templates have a predictable structure where each block has one top-level div with wp-block-woocommerce- class containing arbitrary nested content that should be preserved.
Learnt from: MaggieCabrera
PR: woocommerce/woocommerce#59940
File: plugins/woocommerce/client/blocks/assets/js/blocks/product-template/style.scss:28-28
Timestamp: 2025-08-08T10:17:51.893Z
Learning: In WooCommerce blocks, follow WordPress core’s approach for spacing: use the standard CSS gap property on flex containers without adding negative-margin fallbacks. This is acceptable for .wc-block-product-template.is-flex-container in plugins/woocommerce/client/blocks/assets/js/blocks/product-template/style.scss, while grid may include a simple supports fallback (gap → grid-gap). Align with WP’s browserslist baseline and Autoprefixer setup.
Learnt from: Aljullu
PR: woocommerce/woocommerce#58809
File: plugins/woocommerce/src/Blocks/BlockTypes/ProductButton.php:222-225
Timestamp: 2025-06-13T17:11:13.732Z
Learning: In `plugins/woocommerce/src/Blocks/BlockTypes/ProductButton.php`, the team intentionally relies on toggling the `disabled` CSS class (via `data-wp-class--disabled`) instead of binding the `disabled` attribute, to mirror the behavior of the classic WooCommerce template.
Learnt from: gigitux
PR: woocommerce/woocommerce#58902
File: plugins/woocommerce/client/blocks/assets/js/blocks/product-specifications/edit.tsx:205-206
Timestamp: 2025-06-17T12:40:54.118Z
Learning: In WordPress blocks, when there's a styling mismatch between editor and frontend, check if the PHP renderer (like in `ProductSpecifications.php`) adds specific classes to the output. If so, add those same classes to the `useBlockProps` className in the editor component (like in `edit.tsx`) to ensure consistent styling. For example, adding `wp-block-table` class to both frontend and editor ensures core table styles and theme customizations apply consistently.
Learnt from: lysyjan
PR: woocommerce/woocommerce#59070
File: packages/php/email-editor/src/Integrations/Core/class-initializer.php:103-141
Timestamp: 2025-06-23T16:55:58.246Z
Learning: The core/spacer block in the WooCommerce email editor intentionally does not have a dedicated renderer class and is handled by the fallback renderer instead of having an explicit render_email_callback assigned in the switch statement.
Learnt from: ralucaStan
PR: woocommerce/woocommerce#58782
File: plugins/woocommerce/client/blocks/assets/js/base/components/cart-checkout/product-details/style.scss:21-26
Timestamp: 2025-06-13T15:24:45.923Z
Learning: In WooCommerce blocks, bold styling for `.wc-block-components-product-details__name` should be scoped only to the Cart block (`.wc-block-cart__main`); on the Checkout block, product names are not bold because prices are highlighted instead.
Learnt from: Aljullu
PR: woocommerce/woocommerce#59370
File: plugins/woocommerce/client/blocks/assets/js/blocks/product-gallery/style.scss:236-243
Timestamp: 2025-07-03T10:09:20.635Z
Learning: In WooCommerce blocks CSS, prefer using standard CSS properties like `scrollbar-width` over vendor-specific prefixes when the standard property has good browser support. As of late 2024, `scrollbar-width` is widely supported across all major browsers and doesn't require WebKit-specific workarounds.
Learnt from: samueljseay
PR: woocommerce/woocommerce#58716
File: plugins/woocommerce/client/blocks/assets/js/blocks/mini-cart/iapi-frontend.ts:83-101
Timestamp: 2025-06-17T07:07:53.443Z
Learning: In WooCommerce blocks, when porting existing code patterns that have known issues (like parseInt truncating decimal money values), maintain consistency with existing implementation rather than making isolated fixes. The preference is for systematic refactoring approaches (like broader Dinero adoption) over piecemeal changes.
Learnt from: lysyjan
PR: woocommerce/woocommerce#59632
File: packages/js/email-editor/src/layouts/flex-email.tsx:116-122
Timestamp: 2025-07-14T10:41:46.200Z
Learning: In WooCommerce projects, formatting suggestions should respect the project's Prettier configuration and linting rules. Changes that would break the lint job should be avoided, even if they appear to improve readability.
Learnt from: dinhtungdu
PR: woocommerce/woocommerce#59900
File: plugins/woocommerce/client/blocks/assets/js/blocks/product-filters/inner-blocks/attribute-filter/inspector.tsx:0-0
Timestamp: 2025-07-24T05:37:00.907Z
Learning: The DisplayStyleSwitcher component in plugins/woocommerce/client/blocks/assets/js/blocks/product-filters/components/display-style-switcher/index.tsx has been updated so that its onChange prop accepts only a string type (not string | number | undefined), eliminating the need for type assertions when using this component.
Learnt from: NeosinneR
PR: woocommerce/woocommerce#0
File: :0-0
Timestamp: 2025-06-26T14:25:08.421Z
Learning: In WooCommerce transactional emails, product images have historically had display issues due to lazy loading attributes being applied, which email clients cannot process since they don't execute JavaScript. This issue existed in both old and new email templates, but became more visible with the new email template system. The fix involves preventing lazy loading on attachment images specifically during email generation by adding skip classes and data attributes.
Learnt from: ralucaStan
PR: woocommerce/woocommerce#58782
File: plugins/woocommerce/client/blocks/assets/js/base/utils/render-frontend.tsx:0-0
Timestamp: 2025-06-16T16:12:12.148Z
Learning: For WooCommerce checkout blocks, lazy loading was removed in favor of direct imports to prevent sequential "popping" effects during component loading. This approach prioritizes user experience over code splitting, with minimal bundle size impact and improved performance (1.7s to 1.1s speed score improvement). The checkout flow benefits from having all components load together rather than incrementally.
scruffian
reviewed
Aug 8, 2025
| @@ -37,15 +37,21 @@ $min-product-width: 150px; | |||
| @include break-small { | |||
| @for $i from 2 through 6 { | |||
| &.is-flex-container.columns-#{ $i } > li { | |||
| width: calc((100% / #{$i}) - 1.25em + (1.25em / #{$i})); | |||
| // Use CSS custom property with fallback for dynamic width calculation | |||
| width: calc((100% / #{$i}) - var(--wc-product-template-gap, 1.25em) + (var(--wc-product-template-gap, 1.25em) / #{$i})); | |||
There was a problem hiding this comment.
Is it worth saving var(--wc-product-template-gap, 1.25em) to a variable, just so this is a bit easier to grok?
scruffian
reviewed
Aug 8, 2025
| gap: $grid-gap; // Use modern 'gap' instead of 'grid-gap' | ||
|
|
||
| // Fallback for older browsers if needed | ||
| @supports not (gap: 1em) { |
scruffian
reviewed
Aug 8, 2025
| ); | ||
|
|
||
| // Apply blockGap styles manually for flow layout |
There was a problem hiding this comment.
Why do we need to apply it manually, rather than letting Gutenberg handle it? Will it apply the attributes to the wrong element otherwise?
There was a problem hiding this comment.
because Woo does layout on this block differently and it doesn't work out of the box in this specific case. I looked into changing that but it's a much more complicated effort and the core way doesn't cover all the cases the current implementation does
There was a problem hiding this comment.
Product Collection initially handled Stack and Grid layout "manually" the same way as Query Loop did back then. Then our use cases evolved to include responsiveness with some custom constraints while n the meantime Gutenberg introduced supports.layout. But like @MaggieCabrera said it didn't cover fully our use case.
To be fair, there was a huge effort to migrate the layout to Gutenberg (#46255) which turned out to be impossible back then. However, @ObliviousHarmony wrote this comment:
WordPress/gutenberg#62777 was merged at the end of July containing a change allowing minimumColumnWidth to be set alongside columnCount. This supports our current requirements and will be releasing in WordPress 6.7. Unfortunately, due to our L-1 WordPress version support policy, we won't be able to take advantage of these changes until WordPress 6.8 releases next year.
I didn't have a chance to verify this but if that's the case we should actually migrate to supports.layout to leverage native blockGap. Let's keep in mind that merging this PR means even more complex migration to supports.layout in the future. So I'd like us to be really certain Gutenberg doesn't cover our use case before proceeding with this approach.
I think I should be able to spend some time on this next week (cc: @sunyatasattva, letting you know we're discussing the block gap in Product Collection which I know you wanted to tackle for a long time! And let me know if you see any objections for me to take a look given "AJAX Add to Cart" thing is paused.)
There was a problem hiding this comment.
@kmanijak thanks for tagging me. Yes please, do spend some time in seeing if supports.layout now satisfies our use-cases before adding any more custom complexity. We should try to think Core-first as much as possible.
|
Curious. Is it possible to use the core grid/block gap, rather than extending the custom one? This does everything the core functionality supports, no? |
Quoting maggie above:
|
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.
Submission Review Guidelines:
Changes proposed in this Pull Request:
Closes #43307
This adds support for blockgap on the Product Template. I didn't change the way we do the layout since that seemed like a very complex endeavor. This PR leverages the core implementation applied to the way Woo does the layout for this block. We can revisit when we have a clear path to change the way we do layouts but this should bring value to users that want to control the spacing between products as of today.
Screenshots or screen recordings:
Stack
Grid
Carousel
How to test the changes in this Pull Request:
Using the WooCommerce Testing Instructions Guide, include your detailed testing instructions:
Testing that has already taken place:
Changelog entry
Changelog Entry Details
Significance
Type
Message
Changelog Entry Comment
Comment