Skip to content

Use WP core templating logic for WC taxonomy templates #60191

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

Open
wants to merge 16 commits into
base: trunk
Choose a base branch
from

Conversation

Aljullu
Copy link
Contributor

@Aljullu Aljullu commented Aug 4, 2025

Changes proposed in this Pull Request:

This PR makes it so the Products by Category, Products by Tag and Products by Brand templates use the WP core templating logic, which has several benefits:

  1. The templates won't show up on the list by default, closing Hide the Products by Category, Tag, and Attribute templates from the templates list #42531.
  2. We can simplify the logic that implemented the fall back to the Product Catalog template by leveraging the taxonomy_template_hierarchy hook.
  3. In general, we can remove a lot of code. 🥳

We can't do the same with the Products by Attribute template because it's not a taxonomy, so we need to keep that template as usual.

We also need to keep the logic that loads WooCommerce templates with the woocommerce/woocommerce slug for backwards compatibility. That's why even when we migrate to the new APIs fully, we won't be able to remove BlockTemplatesController fully.

Note: this PR is not yet using the new template registration API for non-taxonomy templates. That will be done in #47885.

Closes #42531.

Part of this PR is based on #44778.

How to test the changes in this Pull Request:

Theme without WC templates:

  1. In trunk, customize the Products by Category template, maybe adding a text that makes it easy to identify it.
  2. Switch to this branch.
  3. In the frontend, verify the customized template is still rendered (ie, in /product-category/clothing/tshirts/).
  4. Go to Appearance > Editor > Templates > Products by Category and verify the customized template is loaded.
  5. Make changes, save, and verify the changes are applied to the frontend.
  6. Reset/delete the template and verify the default template is rendered correctly.
  7. Now, go to Appearance > Editor > Templates > Add Template > Products by Category and verify you can add a new template for all categories.
  8. Verify also that Gutenberg suggests using the Product Catalog page as the base pattern.
imatge

Theme with WC templates:

  1. In trunk, customize the Products by Category template, maybe adding a text that makes it easy to identify it.
  2. Switch to this branch.
  3. In the frontend, verify the customized template is still rendered.
  4. Now, add a taxonomy-product_cat.html template (under /templates).
  5. Verify the template you customized before is used, instead of the theme template.
  6. Go to Appearance > Editor > Templates > Add Template > Products by Tag. Create a new template for all tags.
  7. Add a taxonomy-product_tag.html template (under /templates).
  8. In the frontend (ie: /product-tag/recommended-products/), verify the template you customized is used, instead of the theme template.

@Aljullu Aljullu self-assigned this Aug 4, 2025
@Aljullu Aljullu added the Blocks/Patterns/Templates Issues related to Full Site Editing label Aug 4, 2025
@github-actions github-actions bot added the plugin: woocommerce Issues related to the WooCommerce Core plugin. label Aug 4, 2025
@Aljullu Aljullu force-pushed the fix/42531-use-wc-templating-logic-for-taxonomies branch from 3529beb to 287d7a1 Compare August 5, 2025 05:58
@Aljullu Aljullu marked this pull request as ready for review August 5, 2025 09:10
@github-actions github-actions bot added the focus: e2e tests Issues related to e2e tests label Aug 5, 2025
@woocommercebot woocommercebot requested review from a team and kmanijak and removed request for a team August 5, 2025 09:10
Copy link
Contributor

github-actions bot commented Aug 5, 2025

Testing Guidelines

Hi @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:

  • 🖼️ Screenshots or screen recordings.
  • 📝 List of functionality tested / steps followed.
  • 🌐 Site details (environment attributes such as hosting type, plugins, theme, store size, store age, and relevant settings).
  • 🔍 Any analysis performed, such as assessing potential impacts on environment attributes and other plugins, conducting performance profiling, or using LLM/AI-based analysis.

⚠️ Within the testing details you provide, please ensure that no sensitive information (such as API keys, passwords, user data, etc.) is included in this public issue.

Copy link
Contributor

github-actions bot commented Aug 5, 2025

Test using WordPress Playground

The changes in this pull request can be previewed and tested using a WordPress Playground instance.
WordPress Playground is an experimental project that creates a full WordPress instance entirely within the browser.

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.

Copy link
Contributor

coderabbitai bot commented Aug 5, 2025

📝 Walkthrough

Walkthrough

This update removes all fallback template logic from the WooCommerce Blocks plugin. It introduces a new abstract class for taxonomy templates with fallback capabilities and refactors product taxonomy templates to extend this new class. Related utility methods and tests for fallback logic are deleted or simplified, and strict typing is enforced across several files. End-to-end and unit tests are updated accordingly.

Changes

Cohort / File(s) Change Summary
Fallback Template Logic Removal
plugins/woocommerce/src/Blocks/BlockTemplatesController.php, plugins/woocommerce/src/Blocks/Utils/BlockTemplateUtils.php
Removed all fallback logic for block templates, including fallback eligibility methods, filter registrations, fallback template retrieval, and theme/database fallback handling. Utility methods were deleted or simplified.
Abstract Fallback Class Introduction
plugins/woocommerce/src/Blocks/Templates/AbstractTemplateWithFallback.php
Added a new abstract class providing shared fallback logic and taxonomy template hierarchy modification for templates supporting fallback rendering.
Product Taxonomy Template Refactor
plugins/woocommerce/src/Blocks/Templates/ProductCategoryTemplate.php, plugins/woocommerce/src/Blocks/Templates/ProductTagTemplate.php, plugins/woocommerce/src/Blocks/Templates/ProductBrandTemplate.php, plugins/woocommerce/src/Blocks/Templates/ProductAttributeTemplate.php
Refactored product taxonomy template classes to extend the new abstract fallback class, removed their init() methods, and simplified template hierarchy manipulation to include fallback templates.
Strict Typing Enforcement
plugins/woocommerce/src/Blocks/Templates/AbstractTemplate.php, plugins/woocommerce/src/Blocks/Templates/ProductCategoryTemplate.php, plugins/woocommerce/src/Blocks/Templates/ProductTagTemplate.php, plugins/woocommerce/src/Blocks/BlockTemplatesRegistry.php
Added declare(strict_types=1); at the top of these PHP files. No other functional changes.
Test Updates for Fallback Removal
plugins/woocommerce/tests/php/src/Blocks/Utils/BlockTemplateUtilsTest.php
Removed tests related to fallback eligibility methods. Renamed and updated a test to cover the simplified utility method for checking template presence in query results.
End-to-End Test Update
plugins/woocommerce/client/blocks/tests/e2e/tests/product-collection/product-collection.block_theme.spec.ts
Updated test flows for product category and tag templates to include an explicit UI step selecting "For a specific item" before choosing category/tag and fallback content.
Changelog Update
plugins/woocommerce/changelog/fix-42531-use-wc-templating-logic-for-taxonomies
Documented exclusion of uncustomized taxonomy templates (category, tag, brand) from the default template listing.

Sequence Diagram(s)

sequenceDiagram
    participant User
    participant WP
    participant WooBlockController as BlockTemplatesController
    participant TemplateClass as Product*Template (Category/Tag/Brand/Attribute)
    participant FallbackClass as AbstractTemplateWithFallback

    User->>WP: Request taxonomy archive page
    WP->>WooBlockController: Resolve template for taxonomy
    WooBlockController->>TemplateClass: Find matching template
    TemplateClass->>FallbackClass: (If fallback needed) Modify template hierarchy
    FallbackClass-->>TemplateClass: Return updated hierarchy
    TemplateClass->>WP: Render resolved template (no fallback substitution)
Loading

Estimated code review effort

🎯 4 (Complex) | ⏱️ ~35 minutes

Possibly related PRs

Note

⚡️ Unit Test Generation is now available in beta!

Learn more here, or try it out under "Finishing Touches" below.


📜 Recent review details

Configuration used: .coderabbit.yml
Review profile: CHILL
Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between 0154130 and 24d6363.

📒 Files selected for processing (2)
  • plugins/woocommerce/src/Blocks/BlockTemplatesController.php (3 hunks)
  • plugins/woocommerce/src/Blocks/Templates/AbstractTemplateWithFallback.php (1 hunks)
🚧 Files skipped from review as they are similar to previous changes (1)
  • plugins/woocommerce/src/Blocks/Templates/AbstractTemplateWithFallback.php
🧰 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/BlockTemplatesController.php
**/*.{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/BlockTemplatesController.php
🧠 Learnings (16)
📓 Common learnings
Learnt from: jorgeatorres
PR: woocommerce/woocommerce#59675
File: .github/workflows/release-bump-as-requirement.yml:48-65
Timestamp: 2025-07-15T15:39:21.856Z
Learning: In WooCommerce core repository, changelog entries for all PRs live in `plugins/woocommerce/changelog/` directory and are processed during releases, not at the repository root level.
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: 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.
Learnt from: gigitux
PR: woocommerce/woocommerce#58846
File: plugins/woocommerce/client/blocks/tests/e2e/tests/all-products/all-products.block_theme.spec.ts:41-52
Timestamp: 2025-06-16T09:20:22.981Z
Learning: In WooCommerce E2E tests, the database is reset to the initial state for each test, so there's no need to manually restore global template changes (like clearing the header template) as the test infrastructure handles cleanup automatically.
Learnt from: dinhtungdu
PR: woocommerce/woocommerce#59499
File: plugins/woocommerce/src/Internal/ProductFilters/QueryClauses.php:327-332
Timestamp: 2025-07-10T04:22:27.648Z
Learning: In the WooCommerce ProductFilters QueryClauses class, the $chosen_taxonomies parameter in add_taxonomy_clauses() already contains only validated public product taxonomies. The validation occurs upstream in the Params class during parameter registration, so additional taxonomy existence validation in the processing methods is redundant.
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#60142
File: plugins/woocommerce/src/Internal/ProductFilters/TaxonomyHierarchyData.php:71-93
Timestamp: 2025-08-01T05:52:57.768Z
Learning: In plugins/woocommerce/src/Internal/ProductFilters/TaxonomyHierarchyData.php, the get_descendants() and get_ancestors() methods don't need extensive input validation because: 1) the taxonomy parameter is always validated upstream in the controlled WooCommerce core context, and 2) the null coalescing operator (??) already efficiently handles invalid term_id keys in the returned map.
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: 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: 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: 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: 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: 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.
📚 Learning: woocommerce block templates have a predictable structure where each block has one top-level div with...
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/src/Blocks/BlockTemplatesController.php
📚 Learning: in woocommerce blocks, when porting existing code patterns that have known issues (like parseint tru...
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/src/Blocks/BlockTemplatesController.php
📚 Learning: the displaystyleswitcher component in plugins/woocommerce/client/blocks/assets/js/blocks/product-fil...
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/src/Blocks/BlockTemplatesController.php
📚 Learning: woocommerce legacy javascript files in plugins/woocommerce/client/legacy/js/ must use older javascri...
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/src/Blocks/BlockTemplatesController.php
📚 Learning: in `plugins/woocommerce/src/blocks/blocktypes/productbutton.php`, the team intentionally relies on t...
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/src/Blocks/BlockTemplatesController.php
📚 Learning: in woocommerce taxonomy filter components like plugins/woocommerce/client/blocks/assets/js/blocks/pr...
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/BlockTemplatesController.php
📚 Learning: in woocommerce e2e tests, the database is reset to the initial state for each test, so there's no ne...
Learnt from: gigitux
PR: woocommerce/woocommerce#58846
File: plugins/woocommerce/client/blocks/tests/e2e/tests/all-products/all-products.block_theme.spec.ts:41-52
Timestamp: 2025-06-16T09:20:22.981Z
Learning: In WooCommerce E2E tests, the database is reset to the initial state for each test, so there's no need to manually restore global template changes (like clearing the header template) as the test infrastructure handles cleanup automatically.

Applied to files:

  • plugins/woocommerce/src/Blocks/BlockTemplatesController.php
📚 Learning: the core/spacer block in the woocommerce email editor intentionally does not have a dedicated render...
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/src/Blocks/BlockTemplatesController.php
📚 Learning: in plugins/woocommerce/src/internal/productfilters/taxonomyhierarchydata.php, the get_descendants() ...
Learnt from: dinhtungdu
PR: woocommerce/woocommerce#60142
File: plugins/woocommerce/src/Internal/ProductFilters/TaxonomyHierarchyData.php:71-93
Timestamp: 2025-08-01T05:52:57.768Z
Learning: In plugins/woocommerce/src/Internal/ProductFilters/TaxonomyHierarchyData.php, the get_descendants() and get_ancestors() methods don't need extensive input validation because: 1) the taxonomy parameter is always validated upstream in the controlled WooCommerce core context, and 2) the null coalescing operator (??) already efficiently handles invalid term_id keys in the returned map.

Applied to files:

  • plugins/woocommerce/src/Blocks/BlockTemplatesController.php
📚 Learning: in wordpress blocks, when there's a styling mismatch between editor and frontend, check if the php r...
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/src/Blocks/BlockTemplatesController.php
📚 Learning: in github actions workflows, when reviewing steps that access event data like `github.event.pull_req...
Learnt from: prettyboymp
PR: woocommerce/woocommerce#59048
File: .github/workflows/cherry-pick-milestoned-prs.yml:118-131
Timestamp: 2025-07-11T13:05:08.440Z
Learning: In GitHub Actions workflows, when reviewing steps that access event data like `github.event.pull_request.milestone`, check the entire job dependency chain and conditional logic. If upstream jobs already validate the data exists (like checking `github.event.pull_request.milestone != null` in a prerequisite job), then downstream jobs don't need redundant null-checks since the data is guaranteed to exist by that point.

Applied to files:

  • plugins/woocommerce/src/Blocks/BlockTemplatesController.php
📚 Learning: for woocommerce mini-cart blocks in plugins/woocommerce/client/blocks/assets/js/blocks/mini-cart/, t...
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/src/Blocks/BlockTemplatesController.php
📚 Learning: in wordpress block editor development, the insertblock function requires a block instance (created w...
Learnt from: gigitux
PR: woocommerce/woocommerce#59519
File: plugins/woocommerce/client/blocks/assets/js/blocks/product-collection/edit/inspector-controls/use-carousel-layout-adjustments.ts:137-144
Timestamp: 2025-07-14T10:43:00.505Z
Learning: In WordPress block editor development, the insertBlock function requires a block instance (created with createBlock()) rather than a block name string. Passing a string directly to insertBlock will cause a runtime error. Always wrap block name constants with createBlock() when using insertBlock.

Applied to files:

  • plugins/woocommerce/src/Blocks/BlockTemplatesController.php
📚 Learning: in woocommerce blocks typescript code, avoid type assertions (`as`) when accessing properties from u...
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/BlockTemplatesController.php
📚 Learning: woocommerce has polyfills for newer php functions (like str_starts_with() from php 8.0+), so these f...
Learnt from: vladolaru
PR: woocommerce/woocommerce#59486
File: plugins/woocommerce/src/Internal/Admin/Settings/PaymentsProviders/WooPayments/WooPaymentsService.php:1544-1544
Timestamp: 2025-07-08T11:18:07.871Z
Learning: WooCommerce has polyfills for newer PHP functions (like str_starts_with() from PHP 8.0+), so these functions can be safely used even though WooCommerce supports PHP 7.4+. No need to suggest PHP 7.4 compatible alternatives when polyfills are available.

Applied to files:

  • plugins/woocommerce/src/Blocks/BlockTemplatesController.php
⏰ 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). (23)
  • GitHub Check: Blocks e2e tests 9/10 - @woocommerce/plugin-woocommerce [e2e]
  • GitHub Check: Blocks e2e tests 2/10 - @woocommerce/plugin-woocommerce [e2e]
  • GitHub Check: Blocks e2e tests 6/10 - @woocommerce/plugin-woocommerce [e2e]
  • GitHub Check: Core e2e tests 6/6 - @woocommerce/plugin-woocommerce [e2e]
  • GitHub Check: Blocks e2e tests 3/10 - @woocommerce/plugin-woocommerce [e2e]
  • GitHub Check: Metrics - @woocommerce/plugin-woocommerce [performance]
  • GitHub Check: Blocks e2e tests 5/10 - @woocommerce/plugin-woocommerce [e2e]
  • GitHub Check: Blocks e2e tests 4/10 - @woocommerce/plugin-woocommerce [e2e]
  • GitHub Check: Blocks e2e tests 8/10 - @woocommerce/plugin-woocommerce [e2e]
  • GitHub Check: Blocks e2e tests 7/10 - @woocommerce/plugin-woocommerce [e2e]
  • GitHub Check: Blocks e2e tests 10/10 - @woocommerce/plugin-woocommerce [e2e]
  • GitHub Check: Core API tests - @woocommerce/plugin-woocommerce [api]
  • GitHub Check: Core e2e tests 5/6 - @woocommerce/plugin-woocommerce [e2e]
  • GitHub Check: Core e2e tests 2/6 - @woocommerce/plugin-woocommerce [e2e]
  • GitHub Check: Blocks e2e tests 1/10 - @woocommerce/plugin-woocommerce [e2e]
  • GitHub Check: Core e2e tests 4/6 - @woocommerce/plugin-woocommerce [e2e]
  • GitHub Check: PHP: 8.4 WP: latest [WP latest] 2/2 - @woocommerce/plugin-woocommerce [unit:php]
  • GitHub Check: PHP: 7.4 WP: latest - 1 [WP 6.7.3] 1/2 - @woocommerce/plugin-woocommerce [unit:php]
  • GitHub Check: Core e2e tests 3/6 - @woocommerce/plugin-woocommerce [e2e]
  • GitHub Check: Core e2e tests 1/6 - @woocommerce/plugin-woocommerce [e2e]
  • GitHub Check: PHP: 7.4 WP: latest - 1 [WP 6.7.3] 2/2 - @woocommerce/plugin-woocommerce [unit:php]
  • GitHub Check: PHP: 8.4 WP: latest [WP latest] 1/2 - @woocommerce/plugin-woocommerce [unit:php]
  • GitHub Check: build
🔇 Additional comments (4)
plugins/woocommerce/src/Blocks/BlockTemplatesController.php (4)

2-2: LGTM: Strict typing improves code quality

The addition of strict type declarations enhances type safety and follows modern PHP best practices.


217-217: LGTM: Performance optimization

Using get_stylesheet() directly is more performant than wp_get_theme()->get_stylesheet() and follows WordPress core's updated approach.


224-249: LGTM: Simplified template filtering with proper null safety

The refactored logic correctly:

  • Simplifies template existence checking using is_template_in_query_result()
  • Properly handles null cases before accessing fallback_template property
  • Skips templates with defined fallbacks as intended by the PR objectives

This addresses the previous null safety concern and aligns with the new template handling architecture.


25-32: Excellent architectural refactoring

The removal of fallback-related hooks and methods from the controller follows good separation of concerns. Delegating fallback logic to individual template classes (via AbstractTemplateWithFallback) while maintaining backward compatibility aligns well with the PR objectives to adopt WordPress core's templating approach.

This simplifies the controller's responsibilities and makes the codebase more maintainable.

✨ Finishing Touches
  • 📝 Generate Docstrings
🧪 Generate unit tests
  • Create PR with unit tests
  • Post copyable unit tests in a comment
  • Commit unit tests in branch fix/42531-use-wc-templating-logic-for-taxonomies

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.

❤️ Share
🪧 Tips

Chat

There are 3 ways to chat with CodeRabbit:

  • Review comments: Directly reply to a review comment made by CodeRabbit. Example:
    • I pushed a fix in commit <commit_id>, please review it.
    • Explain this complex logic.
    • Open a follow-up GitHub issue for this discussion.
  • Files and specific lines of code (under the "Files changed" tab): Tag @coderabbitai in a new review comment at the desired location with your query. Examples:
    • @coderabbitai explain this code block.
  • PR comments: Tag @coderabbitai in a new PR comment to ask questions about the PR branch. For the best results, please provide a very specific query, as very limited context is provided in this mode. Examples:
    • @coderabbitai gather interesting stats about this repository and render them as a table. Additionally, render a pie chart showing the language distribution in the codebase.
    • @coderabbitai read src/utils.ts and explain its main purpose.
    • @coderabbitai read the files in the src/scheduler package and generate a class diagram using mermaid and a README in the markdown format.

Support

Need help? Create a ticket on our support page for assistance with any issues or questions.

CodeRabbit Commands (Invoked using PR comments)

  • @coderabbitai pause to pause the reviews on a PR.
  • @coderabbitai resume to resume the paused reviews.
  • @coderabbitai review to trigger an incremental review. This is useful when automatic reviews are disabled for the repository.
  • @coderabbitai full review to do a full review from scratch and review all the files again.
  • @coderabbitai summary to regenerate the summary of the PR.
  • @coderabbitai generate docstrings to generate docstrings for this PR.
  • @coderabbitai generate sequence diagram to generate a sequence diagram of the changes in this PR.
  • @coderabbitai generate unit tests to generate unit tests for this PR.
  • @coderabbitai resolve resolve all the CodeRabbit review comments.
  • @coderabbitai configuration to show the current CodeRabbit configuration for the repository.
  • @coderabbitai help to get help.

Other keywords and placeholders

  • Add @coderabbitai ignore anywhere in the PR description to prevent this PR from being reviewed.
  • Add @coderabbitai summary to generate the high-level summary at a specific location in the PR description.
  • Add @coderabbitai anywhere in the PR title to generate the title automatically.

Documentation and Community

  • Visit our Documentation for detailed information on how to use CodeRabbit.
  • Join our Discord Community to get help, request features, and share feedback.
  • Follow us on X/Twitter for updates and announcements.

Copy link
Contributor

@coderabbitai coderabbitai bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actionable comments posted: 4

🧹 Nitpick comments (3)
plugins/woocommerce/changelog/fix-42531-use-wc-templating-logic-for-taxonomies (1)

4-4: Fix typo in changelog description.

There's a small typo: "form" should be "from".

-Hide Products by Category, by Tag and by Brand templates form the default list if they hadn't been customized
+Hide Products by Category, by Tag and by Brand templates from the default list if they hadn't been customized
plugins/woocommerce/src/Blocks/Templates/AbstractTemplateWithFallback.php (1)

36-36: Simplify redundant ternary expression.

The nested ternary performs the same array_search operation twice unnecessarily.

-$index = array_search( static::SLUG, $templates, true ) !== false ? array_search( static::SLUG, $templates, true ) : array_search( static::SLUG . '.php', $templates, true );
+$index = array_search( static::SLUG, $templates, true );
+if ( false === $index ) {
+    $index = array_search( static::SLUG . '.php', $templates, true );
+}
plugins/woocommerce/tests/php/src/Blocks/Utils/BlockTemplateUtilsTest.php (1)

138-160: Test implementation looks good, consider adding edge cases

The test correctly verifies the is_template_in_query_result functionality by checking both matching and non-matching cases. The object structure with slug and theme properties aligns with WordPress template objects.

Consider adding test cases for:

  • Empty query result array
  • Null or missing properties in template objects
  • Multiple templates in the query result
 public function test_is_template_in_query_result() {
 	$query_result = array(
 		(object) array(
 			'slug'  => 'taxonomy-product_cat',
 			'theme' => 'twentytwentytwo',
 		),
 	);
 
 	$non_matching_template_file = (object) array(
 		'slug'  => 'archive-product',
 		'theme' => 'twentytwentytwo',
 	);
 
 	$matching_template_file = (object) array(
 		'slug'  => 'taxonomy-product_cat',
 		'theme' => 'twentytwentytwo',
 	);
 
 	$this->assertFalse( BlockTemplateUtils::is_template_in_query_result( $query_result, $non_matching_template_file ) );
 	$this->assertTrue( BlockTemplateUtils::is_template_in_query_result( $query_result, $matching_template_file ) );
+
+	// Test empty query result
+	$this->assertFalse( BlockTemplateUtils::is_template_in_query_result( array(), $matching_template_file ) );
+
+	// Test different theme
+	$different_theme_template = (object) array(
+		'slug'  => 'taxonomy-product_cat',
+		'theme' => 'twentytwentythree',
+	);
+	$this->assertFalse( BlockTemplateUtils::is_template_in_query_result( $query_result, $different_theme_template ) );
 }
📜 Review details

Configuration used: .coderabbit.yml
Review profile: CHILL
Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between 5260266 and 9f79d8c.

📒 Files selected for processing (12)
  • plugins/woocommerce/changelog/fix-42531-use-wc-templating-logic-for-taxonomies (1 hunks)
  • plugins/woocommerce/client/blocks/tests/e2e/tests/product-collection/product-collection.block_theme.spec.ts (2 hunks)
  • plugins/woocommerce/src/Blocks/BlockTemplatesController.php (3 hunks)
  • plugins/woocommerce/src/Blocks/BlockTemplatesRegistry.php (1 hunks)
  • plugins/woocommerce/src/Blocks/Templates/AbstractTemplate.php (1 hunks)
  • plugins/woocommerce/src/Blocks/Templates/AbstractTemplateWithFallback.php (1 hunks)
  • plugins/woocommerce/src/Blocks/Templates/ProductAttributeTemplate.php (3 hunks)
  • plugins/woocommerce/src/Blocks/Templates/ProductBrandTemplate.php (1 hunks)
  • plugins/woocommerce/src/Blocks/Templates/ProductCategoryTemplate.php (2 hunks)
  • plugins/woocommerce/src/Blocks/Templates/ProductTagTemplate.php (2 hunks)
  • plugins/woocommerce/src/Blocks/Utils/BlockTemplateUtils.php (2 hunks)
  • plugins/woocommerce/tests/php/src/Blocks/Utils/BlockTemplateUtilsTest.php (1 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/Templates/ProductTagTemplate.php
  • plugins/woocommerce/src/Blocks/Templates/ProductAttributeTemplate.php
  • plugins/woocommerce/src/Blocks/BlockTemplatesRegistry.php
  • plugins/woocommerce/src/Blocks/Templates/ProductBrandTemplate.php
  • plugins/woocommerce/src/Blocks/Templates/AbstractTemplate.php
  • plugins/woocommerce/client/blocks/tests/e2e/tests/product-collection/product-collection.block_theme.spec.ts
  • plugins/woocommerce/src/Blocks/Templates/AbstractTemplateWithFallback.php
  • plugins/woocommerce/src/Blocks/Utils/BlockTemplateUtils.php
  • plugins/woocommerce/tests/php/src/Blocks/Utils/BlockTemplateUtilsTest.php
  • plugins/woocommerce/src/Blocks/Templates/ProductCategoryTemplate.php
  • plugins/woocommerce/src/Blocks/BlockTemplatesController.php
**/*.{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/Templates/ProductTagTemplate.php
  • plugins/woocommerce/src/Blocks/Templates/ProductAttributeTemplate.php
  • plugins/woocommerce/src/Blocks/BlockTemplatesRegistry.php
  • plugins/woocommerce/src/Blocks/Templates/ProductBrandTemplate.php
  • plugins/woocommerce/src/Blocks/Templates/AbstractTemplate.php
  • plugins/woocommerce/client/blocks/tests/e2e/tests/product-collection/product-collection.block_theme.spec.ts
  • plugins/woocommerce/src/Blocks/Templates/AbstractTemplateWithFallback.php
  • plugins/woocommerce/src/Blocks/Utils/BlockTemplateUtils.php
  • plugins/woocommerce/tests/php/src/Blocks/Utils/BlockTemplateUtilsTest.php
  • plugins/woocommerce/src/Blocks/Templates/ProductCategoryTemplate.php
  • plugins/woocommerce/src/Blocks/BlockTemplatesController.php
🧠 Learnings (27)
📓 Common learnings
Learnt from: jorgeatorres
PR: woocommerce/woocommerce#59675
File: .github/workflows/release-bump-as-requirement.yml:48-65
Timestamp: 2025-07-15T15:39:21.856Z
Learning: In WooCommerce core repository, changelog entries for all PRs live in `plugins/woocommerce/changelog/` directory and are processed during releases, not at the repository root level.
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: 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.
Learnt from: gigitux
PR: woocommerce/woocommerce#58846
File: plugins/woocommerce/client/blocks/tests/e2e/tests/all-products/all-products.block_theme.spec.ts:41-52
Timestamp: 2025-06-16T09:20:22.981Z
Learning: In WooCommerce E2E tests, the database is reset to the initial state for each test, so there's no need to manually restore global template changes (like clearing the header template) as the test infrastructure handles cleanup automatically.
Learnt from: dinhtungdu
PR: woocommerce/woocommerce#59499
File: plugins/woocommerce/src/Internal/ProductFilters/QueryClauses.php:327-332
Timestamp: 2025-07-10T04:22:27.648Z
Learning: In the WooCommerce ProductFilters QueryClauses class, the $chosen_taxonomies parameter in add_taxonomy_clauses() already contains only validated public product taxonomies. The validation occurs upstream in the Params class during parameter registration, so additional taxonomy existence validation in the processing methods is redundant.
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#60142
File: plugins/woocommerce/src/Internal/ProductFilters/TaxonomyHierarchyData.php:71-93
Timestamp: 2025-08-01T05:52:57.768Z
Learning: In plugins/woocommerce/src/Internal/ProductFilters/TaxonomyHierarchyData.php, the get_descendants() and get_ancestors() methods don't need extensive input validation because: 1) the taxonomy parameter is always validated upstream in the controlled WooCommerce core context, and 2) the null coalescing operator (??) already efficiently handles invalid term_id keys in the returned map.
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: 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: 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: 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: 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: 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.
📚 Learning: woocommerce block templates have a predictable structure where each block has one top-level div with...
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/src/Blocks/Templates/ProductTagTemplate.php
  • plugins/woocommerce/src/Blocks/Templates/ProductAttributeTemplate.php
  • plugins/woocommerce/src/Blocks/BlockTemplatesRegistry.php
  • plugins/woocommerce/src/Blocks/Templates/ProductBrandTemplate.php
  • plugins/woocommerce/src/Blocks/Templates/AbstractTemplate.php
  • plugins/woocommerce/src/Blocks/Templates/AbstractTemplateWithFallback.php
  • plugins/woocommerce/src/Blocks/Utils/BlockTemplateUtils.php
  • plugins/woocommerce/src/Blocks/Templates/ProductCategoryTemplate.php
  • plugins/woocommerce/src/Blocks/BlockTemplatesController.php
📚 Learning: in `plugins/woocommerce/src/blocks/blocktypes/productbutton.php`, the team intentionally relies on t...
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/src/Blocks/Templates/ProductTagTemplate.php
  • plugins/woocommerce/src/Blocks/Templates/ProductAttributeTemplate.php
  • plugins/woocommerce/src/Blocks/BlockTemplatesRegistry.php
  • plugins/woocommerce/src/Blocks/Templates/ProductBrandTemplate.php
  • plugins/woocommerce/src/Blocks/Templates/AbstractTemplate.php
  • plugins/woocommerce/src/Blocks/Utils/BlockTemplateUtils.php
  • plugins/woocommerce/src/Blocks/Templates/ProductCategoryTemplate.php
  • plugins/woocommerce/src/Blocks/BlockTemplatesController.php
📚 Learning: the displaystyleswitcher component in plugins/woocommerce/client/blocks/assets/js/blocks/product-fil...
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/src/Blocks/Templates/ProductTagTemplate.php
  • plugins/woocommerce/src/Blocks/Templates/ProductAttributeTemplate.php
  • plugins/woocommerce/src/Blocks/BlockTemplatesRegistry.php
  • plugins/woocommerce/src/Blocks/Templates/AbstractTemplate.php
  • plugins/woocommerce/changelog/fix-42531-use-wc-templating-logic-for-taxonomies
  • plugins/woocommerce/client/blocks/tests/e2e/tests/product-collection/product-collection.block_theme.spec.ts
  • plugins/woocommerce/src/Blocks/Utils/BlockTemplateUtils.php
  • plugins/woocommerce/src/Blocks/Templates/ProductCategoryTemplate.php
  • plugins/woocommerce/src/Blocks/BlockTemplatesController.php
📚 Learning: woocommerce legacy javascript files in plugins/woocommerce/client/legacy/js/ must use older javascri...
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/src/Blocks/Templates/ProductTagTemplate.php
  • plugins/woocommerce/src/Blocks/Templates/ProductAttributeTemplate.php
  • plugins/woocommerce/changelog/fix-42531-use-wc-templating-logic-for-taxonomies
  • plugins/woocommerce/src/Blocks/Templates/ProductCategoryTemplate.php
  • plugins/woocommerce/src/Blocks/BlockTemplatesController.php
📚 Learning: for woocommerce mini-cart blocks in plugins/woocommerce/client/blocks/assets/js/blocks/mini-cart/, t...
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/src/Blocks/Templates/ProductTagTemplate.php
  • plugins/woocommerce/src/Blocks/Templates/ProductAttributeTemplate.php
  • plugins/woocommerce/src/Blocks/BlockTemplatesRegistry.php
  • plugins/woocommerce/src/Blocks/Templates/AbstractTemplate.php
  • plugins/woocommerce/client/blocks/tests/e2e/tests/product-collection/product-collection.block_theme.spec.ts
  • plugins/woocommerce/src/Blocks/Utils/BlockTemplateUtils.php
  • plugins/woocommerce/src/Blocks/Templates/ProductCategoryTemplate.php
  • plugins/woocommerce/src/Blocks/BlockTemplatesController.php
📚 Learning: in wordpress blocks, when there's a styling mismatch between editor and frontend, check if the php r...
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/src/Blocks/Templates/ProductAttributeTemplate.php
  • plugins/woocommerce/src/Blocks/BlockTemplatesRegistry.php
  • plugins/woocommerce/src/Blocks/Templates/ProductBrandTemplate.php
  • plugins/woocommerce/src/Blocks/Templates/AbstractTemplate.php
  • plugins/woocommerce/client/blocks/tests/e2e/tests/product-collection/product-collection.block_theme.spec.ts
  • plugins/woocommerce/src/Blocks/Templates/AbstractTemplateWithFallback.php
  • plugins/woocommerce/src/Blocks/Utils/BlockTemplateUtils.php
  • plugins/woocommerce/src/Blocks/BlockTemplatesController.php
📚 Learning: in plugins/woocommerce/src/internal/productfilters/taxonomyhierarchydata.php, the get_descendants() ...
Learnt from: dinhtungdu
PR: woocommerce/woocommerce#60142
File: plugins/woocommerce/src/Internal/ProductFilters/TaxonomyHierarchyData.php:71-93
Timestamp: 2025-08-01T05:52:57.768Z
Learning: In plugins/woocommerce/src/Internal/ProductFilters/TaxonomyHierarchyData.php, the get_descendants() and get_ancestors() methods don't need extensive input validation because: 1) the taxonomy parameter is always validated upstream in the controlled WooCommerce core context, and 2) the null coalescing operator (??) already efficiently handles invalid term_id keys in the returned map.

Applied to files:

  • plugins/woocommerce/src/Blocks/Templates/ProductAttributeTemplate.php
  • plugins/woocommerce/changelog/fix-42531-use-wc-templating-logic-for-taxonomies
  • plugins/woocommerce/src/Blocks/Templates/ProductCategoryTemplate.php
📚 Learning: in woocommerce taxonomy filter components like plugins/woocommerce/client/blocks/assets/js/blocks/pr...
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/Templates/ProductAttributeTemplate.php
  • plugins/woocommerce/src/Blocks/BlockTemplatesRegistry.php
  • plugins/woocommerce/changelog/fix-42531-use-wc-templating-logic-for-taxonomies
  • plugins/woocommerce/client/blocks/tests/e2e/tests/product-collection/product-collection.block_theme.spec.ts
  • plugins/woocommerce/src/Blocks/BlockTemplatesController.php
📚 Learning: in woocommerce blocks, bold styling for `.wc-block-components-product-details__name` should be scope...
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/src/Blocks/Templates/ProductAttributeTemplate.php
  • plugins/woocommerce/src/Blocks/Templates/AbstractTemplate.php
  • plugins/woocommerce/client/blocks/tests/e2e/tests/product-collection/product-collection.block_theme.spec.ts
  • plugins/woocommerce/src/Blocks/Templates/ProductCategoryTemplate.php
📚 Learning: in woocommerce blocks typescript code, avoid type assertions (`as`) when accessing properties from u...
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/BlockTemplatesRegistry.php
  • plugins/woocommerce/src/Blocks/Templates/AbstractTemplate.php
  • plugins/woocommerce/client/blocks/tests/e2e/tests/product-collection/product-collection.block_theme.spec.ts
  • plugins/woocommerce/src/Blocks/Utils/BlockTemplateUtils.php
  • plugins/woocommerce/src/Blocks/BlockTemplatesController.php
📚 Learning: in woocommerce blocks, when porting existing code patterns that have known issues (like parseint tru...
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/src/Blocks/BlockTemplatesRegistry.php
  • plugins/woocommerce/src/Blocks/Templates/AbstractTemplate.php
  • plugins/woocommerce/changelog/fix-42531-use-wc-templating-logic-for-taxonomies
  • plugins/woocommerce/src/Blocks/Utils/BlockTemplateUtils.php
  • plugins/woocommerce/src/Blocks/Templates/ProductCategoryTemplate.php
  • plugins/woocommerce/src/Blocks/BlockTemplatesController.php
📚 Learning: in woocommerce block edit components (like plugins/woocommerce/client/blocks/assets/js/blocks/next-p...
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/src/Blocks/BlockTemplatesRegistry.php
  • plugins/woocommerce/src/Blocks/Templates/AbstractTemplate.php
  • plugins/woocommerce/client/blocks/tests/e2e/tests/product-collection/product-collection.block_theme.spec.ts
  • plugins/woocommerce/src/Blocks/Templates/ProductCategoryTemplate.php
📚 Learning: in woocommerce's cartschema::get_item_response() method, when called in the context of blocksshareds...
Learnt from: mreishus
PR: woocommerce/woocommerce#58891
File: plugins/woocommerce/src/Blocks/Utils/BlocksSharedState.php:0-0
Timestamp: 2025-06-16T21:59:26.255Z
Learning: In WooCommerce's CartSchema::get_item_response() method, when called in the context of BlocksSharedState::register_cart_interactivity(), the method returns a plain array rather than a WP_REST_Response object, making it directly suitable for wp_interactivity_state() without needing to call ->get_data().

Applied to files:

  • plugins/woocommerce/src/Blocks/BlockTemplatesRegistry.php
  • plugins/woocommerce/src/Blocks/Utils/BlockTemplateUtils.php
📚 Learning: woocommerce has polyfills for newer php functions (like str_starts_with() from php 8.0+), so these f...
Learnt from: vladolaru
PR: woocommerce/woocommerce#59486
File: plugins/woocommerce/src/Internal/Admin/Settings/PaymentsProviders/WooPayments/WooPaymentsService.php:1544-1544
Timestamp: 2025-07-08T11:18:07.871Z
Learning: WooCommerce has polyfills for newer PHP functions (like str_starts_with() from PHP 8.0+), so these functions can be safely used even though WooCommerce supports PHP 7.4+. No need to suggest PHP 7.4 compatible alternatives when polyfills are available.

Applied to files:

  • plugins/woocommerce/src/Blocks/BlockTemplatesRegistry.php
  • plugins/woocommerce/src/Blocks/Templates/AbstractTemplate.php
  • plugins/woocommerce/changelog/fix-42531-use-wc-templating-logic-for-taxonomies
  • plugins/woocommerce/src/Blocks/Templates/ProductCategoryTemplate.php
  • plugins/woocommerce/src/Blocks/BlockTemplatesController.php
📚 Learning: the core/spacer block in the woocommerce email editor intentionally does not have a dedicated render...
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/src/Blocks/Templates/ProductBrandTemplate.php
  • plugins/woocommerce/src/Blocks/Templates/AbstractTemplate.php
  • plugins/woocommerce/src/Blocks/Templates/AbstractTemplateWithFallback.php
  • plugins/woocommerce/src/Blocks/BlockTemplatesController.php
📚 Learning: in woocommerce core repository, changelog entries for all prs live in `plugins/woocommerce/changelog...
Learnt from: jorgeatorres
PR: woocommerce/woocommerce#59675
File: .github/workflows/release-bump-as-requirement.yml:48-65
Timestamp: 2025-07-15T15:39:21.856Z
Learning: In WooCommerce core repository, changelog entries for all PRs live in `plugins/woocommerce/changelog/` directory and are processed during releases, not at the repository root level.

Applied to files:

  • plugins/woocommerce/changelog/fix-42531-use-wc-templating-logic-for-taxonomies
📚 Learning: in the woocommerce productfilters queryclauses class, the $chosen_taxonomies parameter in add_taxono...
Learnt from: dinhtungdu
PR: woocommerce/woocommerce#59499
File: plugins/woocommerce/src/Internal/ProductFilters/QueryClauses.php:327-332
Timestamp: 2025-07-10T04:22:27.648Z
Learning: In the WooCommerce ProductFilters QueryClauses class, the $chosen_taxonomies parameter in add_taxonomy_clauses() already contains only validated public product taxonomies. The validation occurs upstream in the Params class during parameter registration, so additional taxonomy existence validation in the processing methods is redundant.

Applied to files:

  • plugins/woocommerce/changelog/fix-42531-use-wc-templating-logic-for-taxonomies
📚 Learning: woocommerce is currently in the midst of an admin redesign project, so temporary/short-term css solu...
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.

Applied to files:

  • plugins/woocommerce/changelog/fix-42531-use-wc-templating-logic-for-taxonomies
📚 Learning: woocommerce uses wordpress versioning conventions where minor versions in x.y.z format are constrain...
Learnt from: prettyboymp
PR: woocommerce/woocommerce#59048
File: .github/workflows/cherry-pick-milestoned-prs.yml:60-83
Timestamp: 2025-06-26T12:45:40.709Z
Learning: WooCommerce uses WordPress versioning conventions where minor versions in X.Y.Z format are constrained to 0-9 (Y cannot exceed 9). This means version increment logic should reset minor to 0 and increment major when minor reaches 9, rather than allowing two-digit minor versions like 9.10 or 9.11.

Applied to files:

  • plugins/woocommerce/changelog/fix-42531-use-wc-templating-logic-for-taxonomies
📚 Learning: in woocommerce e2e tests, the database is reset to the initial state for each test, so there's no ne...
Learnt from: gigitux
PR: woocommerce/woocommerce#58846
File: plugins/woocommerce/client/blocks/tests/e2e/tests/all-products/all-products.block_theme.spec.ts:41-52
Timestamp: 2025-06-16T09:20:22.981Z
Learning: In WooCommerce E2E tests, the database is reset to the initial state for each test, so there's no need to manually restore global template changes (like clearing the header template) as the test infrastructure handles cleanup automatically.

Applied to files:

  • plugins/woocommerce/client/blocks/tests/e2e/tests/product-collection/product-collection.block_theme.spec.ts
  • plugins/woocommerce/src/Blocks/Utils/BlockTemplateUtils.php
  • plugins/woocommerce/tests/php/src/Blocks/Utils/BlockTemplateUtilsTest.php
  • plugins/woocommerce/src/Blocks/BlockTemplatesController.php
📚 Learning: applies to **/*.{php,js,jsx,ts,tsx} : ensure code has unit or e2e tests where applicable...
Learnt from: CR
PR: woocommerce/woocommerce#0
File: .cursor/rules/code-quality.mdc:0-0
Timestamp: 2025-07-18T14:54:36.232Z
Learning: Applies to **/*.{php,js,jsx,ts,tsx} : Ensure code has unit or E2E tests where applicable

Applied to files:

  • plugins/woocommerce/client/blocks/tests/e2e/tests/product-collection/product-collection.block_theme.spec.ts
📚 Learning: provide clear, step-by-step instructions for how to test the changes in the pr description....
Learnt from: CR
PR: woocommerce/woocommerce#0
File: .cursor/rules/generate-pr-description.mdc:0-0
Timestamp: 2025-07-21T05:22:46.426Z
Learning: Provide clear, step-by-step instructions for how to test the changes in the PR description.

Applied to files:

  • plugins/woocommerce/client/blocks/tests/e2e/tests/product-collection/product-collection.block_theme.spec.ts
📚 Learning: in playwright e2e tests, page.waitforresponse() should be called before the triggering action (like ...
Learnt from: gigitux
PR: woocommerce/woocommerce#58899
File: plugins/woocommerce/tests/e2e-pw/tests/customize-store/assembler/font-picker.spec.js:250-265
Timestamp: 2025-06-17T08:14:15.688Z
Learning: In Playwright E2E tests, page.waitForResponse() should be called BEFORE the triggering action (like clicks) to ensure the response is not missed. This is the recommended pattern per Playwright documentation: const responsePromise = page.waitForResponse(...); await triggerAction(); await responsePromise;

Applied to files:

  • plugins/woocommerce/client/blocks/tests/e2e/tests/product-collection/product-collection.block_theme.spec.ts
📚 Learning: in playwright e2e tests, page.waitforresponse() should be initialized before the triggering action (...
Learnt from: gigitux
PR: woocommerce/woocommerce#58899
File: plugins/woocommerce/tests/e2e-pw/tests/customize-store/assembler/font-picker.spec.js:250-265
Timestamp: 2025-06-17T08:14:15.688Z
Learning: In Playwright E2E tests, page.waitForResponse() should be initialized BEFORE the triggering action (like clicks) to ensure the response is not missed. This is the recommended pattern per Playwright documentation: 
```javascript
const responsePromise = page.waitForResponse('**/api/endpoint');
await triggerAction();
await responsePromise;
```
This pattern prevents missing rapid responses and is the standard approach for reliable E2E tests.

Applied to files:

  • plugins/woocommerce/client/blocks/tests/e2e/tests/product-collection/product-collection.block_theme.spec.ts
📚 Learning: wordpress block.json files support json schema pattern validation for string attributes using the "p...
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/src/Blocks/Utils/BlockTemplateUtils.php
📚 Learning: in wordpress block editor development, the insertblock function requires a block instance (created w...
Learnt from: gigitux
PR: woocommerce/woocommerce#59519
File: plugins/woocommerce/client/blocks/assets/js/blocks/product-collection/edit/inspector-controls/use-carousel-layout-adjustments.ts:137-144
Timestamp: 2025-07-14T10:43:00.505Z
Learning: In WordPress block editor development, the insertBlock function requires a block instance (created with createBlock()) rather than a block name string. Passing a string directly to insertBlock will cause a runtime error. Always wrap block name constants with createBlock() when using insertBlock.

Applied to files:

  • plugins/woocommerce/src/Blocks/Utils/BlockTemplateUtils.php
  • plugins/woocommerce/src/Blocks/BlockTemplatesController.php
🧬 Code Graph Analysis (4)
plugins/woocommerce/src/Blocks/Templates/ProductTagTemplate.php (1)
plugins/woocommerce/src/Blocks/Templates/AbstractTemplateWithFallback.php (1)
  • AbstractTemplateWithFallback (14-52)
plugins/woocommerce/src/Blocks/Templates/ProductBrandTemplate.php (1)
plugins/woocommerce/src/Blocks/Templates/AbstractTemplateWithFallback.php (1)
  • AbstractTemplateWithFallback (14-52)
plugins/woocommerce/tests/php/src/Blocks/Utils/BlockTemplateUtilsTest.php (1)
plugins/woocommerce/src/Blocks/Utils/BlockTemplateUtils.php (2)
  • BlockTemplateUtils (17-788)
  • is_template_in_query_result (545-555)
plugins/woocommerce/src/Blocks/Templates/ProductCategoryTemplate.php (1)
plugins/woocommerce/src/Blocks/Templates/AbstractTemplateWithFallback.php (1)
  • AbstractTemplateWithFallback (14-52)
⏰ 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). (1)
  • GitHub Check: build
🔇 Additional comments (13)
plugins/woocommerce/src/Blocks/BlockTemplatesRegistry.php (1)

2-2: LGTM! Strict typing improves type safety.

The addition of declare(strict_types=1); enforces strict type checking throughout the file, which is a good practice for preventing type-related bugs and improving code reliability.

plugins/woocommerce/src/Blocks/Templates/AbstractTemplate.php (1)

2-2: LGTM! Strict typing enhances the abstract template base class.

Adding declare(strict_types=1); to the abstract base class ensures strict type checking for all template classes that extend it, providing better type safety across the template system.

plugins/woocommerce/src/Blocks/Templates/ProductBrandTemplate.php (1)

13-13: LGTM! Good architectural refactoring.

The change to extend AbstractTemplateWithFallback centralizes the common template hierarchy and rendering logic, which was previously duplicated across taxonomy template classes. This aligns with the PR objective to adopt WordPress core templating logic.

The parent class from plugins/woocommerce/src/Blocks/Templates/AbstractTemplateWithFallback.php (lines 13-51) properly handles the init() method by hooking into taxonomy_template_hierarchy filter and template_redirect action, so the removal of the explicit init() method in this class is correct.

plugins/woocommerce/src/Blocks/Templates/ProductTagTemplate.php (2)

2-2: LGTM! Strict typing improves type safety.

Adding declare(strict_types=1); enforces strict type checking, which is beneficial for preventing type-related issues in template classes.


13-13: LGTM! Consistent architectural refactoring.

The change to extend AbstractTemplateWithFallback follows the same pattern as ProductBrandTemplate and other taxonomy templates, centralizing the common template hierarchy and rendering logic. This is part of the systematic refactoring to adopt WordPress core templating logic as outlined in the PR objectives.

plugins/woocommerce/client/blocks/tests/e2e/tests/product-collection/product-collection.block_theme.spec.ts (1)

895-897: LGTM! Test updates align with UI changes.

The additional step to click "For a specific item" button correctly reflects the updated UI flow for selecting specific categories and tags in the template editor.

Also applies to: 941-943

plugins/woocommerce/src/Blocks/Templates/ProductCategoryTemplate.php (2)

2-2: Good addition of strict types declaration.

Adding strict types improves type safety and helps catch type-related bugs early.


13-13: Clean refactoring to use AbstractTemplateWithFallback.

The migration to extend AbstractTemplateWithFallback properly centralizes fallback logic and removes code duplication. The fallback_template property is correctly set to ProductCatalogTemplate::SLUG.

Also applies to: 27-27

plugins/woocommerce/src/Blocks/Templates/ProductAttributeTemplate.php (1)

75-82: Template hierarchy override is intentional for block themes
The child class replaces the parent logic to always inject both the block‐template slug (taxonomy-product_attribute) and its fallback (archive-product) ahead of the final template (e.g. index.php), ensuring block themes can match either template in the correct order. This deliberate behavior differs from the parent and does not require adjustment.

plugins/woocommerce/src/Blocks/Utils/BlockTemplateUtils.php (1)

2-2: Clean refactoring of template utility methods.

Good improvements:

  • Added strict types for better type safety
  • Renamed method to is_template_in_query_result which better describes its purpose
  • Simplified the logic to a pure boolean check without side effects
  • Proper parameter type hints in the docblock

Also applies to: 538-555

plugins/woocommerce/src/Blocks/BlockTemplatesController.php (3)

2-2: Good addition of strict types

Adding declare(strict_types=1); improves type safety and helps catch type-related bugs early.


217-226: Template existence check implementation looks correct

The replacement of fallback logic with is_template_in_query_result simplifies the code while maintaining the same functionality. The theme slug is properly retrieved for later use.


207-299: No performance concern: get_template is a simple registry lookup

After inspecting BlockTemplateUtils::get_template(), it delegates to BlockTemplatesRegistry::get_template(), which does an array key check against a pre‐populated $this->templates cache. Each call is a constant‐time lookup, so there’s no need for additional caching or batch loading here.

Comment on lines 245 to 250
// If the template has a fallback, we should not include it in the list of templates, unless it has been modified.
$template_data = BlockTemplateUtils::get_template( $template_file->slug );
if ( isset( $template_data->fallback_template ) ) {
continue;
}

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

💡 Verification agent

🧩 Analysis chain

Consider null check for template data

The logic to skip templates with fallback is correct and aligns with the PR objectives. However, consider adding a null check for the template data retrieval.

 // If the template has a fallback, we should not include it in the list of templates, unless it has been modified.
 $template_data = BlockTemplateUtils::get_template( $template_file->slug );
-if ( isset( $template_data->fallback_template ) ) {
+if ( $template_data && isset( $template_data->fallback_template ) ) {
 	continue;
 }

🏁 Script executed:

#!/bin/bash
# Check if BlockTemplateUtils::get_template can return null
ast-grep --pattern 'public static function get_template($_) {
  $$$
}'

# Search for the get_template method implementation
rg -A 10 "function get_template\(" --type php

Length of output: 2832


Add null check before accessing fallback_template

BlockTemplateUtils::get_template() can return null (it delegates to BlockTemplatesRegistry::get_template(), which returns null when a slug isn’t registered). Accessing a property on null will trigger a PHP error. Update the conditional in plugins/woocommerce/src/Blocks/BlockTemplatesController.php to guard against null:

 // If the template has a fallback, we should not include it in the list of templates, unless it has been modified.
 $template_data = BlockTemplateUtils::get_template( $template_file->slug );
-if ( isset( $template_data->fallback_template ) ) {
+// Skip if template retrieval failed or if it has a fallback
+if ( ! $template_data || isset( $template_data->fallback_template ) ) {
     continue;
 }

This ensures we never attempt to read fallback_template on a null value.

📝 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
// If the template has a fallback, we should not include it in the list of templates, unless it has been modified.
$template_data = BlockTemplateUtils::get_template( $template_file->slug );
if ( isset( $template_data->fallback_template ) ) {
continue;
}
// If the template has a fallback, we should not include it in the list of templates, unless it has been modified.
$template_data = BlockTemplateUtils::get_template( $template_file->slug );
// Skip if template retrieval failed or if it has a fallback
if ( ! $template_data || isset( $template_data->fallback_template ) ) {
continue;
}
🤖 Prompt for AI Agents
In plugins/woocommerce/src/Blocks/BlockTemplatesController.php around lines 245
to 250, the code calls BlockTemplateUtils::get_template() which can return null,
but then accesses fallback_template without checking for null, causing a PHP
error. Fix this by adding a null check before accessing fallback_template,
ensuring the code only checks fallback_template if template_data is not null.

@Aljullu Aljullu force-pushed the fix/42531-use-wc-templating-logic-for-taxonomies branch from b6034b0 to cb2bd30 Compare August 5, 2025 12:31
Copy link
Contributor

@kmanijak kmanijak left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I appreciate the amount of removed code! It's amazing to see PRs with enhancements that actually remove the code!

I tested the scenarios you listed and all of them passed. I didn't spot any weird/wrong behaviours.

Great job!

…allback.php

Co-authored-by: Karol Manijak <20098064+kmanijak@users.noreply.github.com>
@Aljullu
Copy link
Contributor Author

Aljullu commented Aug 6, 2025

Heads-up that I noticed this PR causes the Products by Attribute template not to appear in the Site Editor:

imatge

While I could work on a specific solution for this PR, I think that will be fixed for-free when we migrate to the upstream API (#47885). So I will focus on that and, in the meanwhile, will leave this PR without merging.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Blocks/Patterns/Templates Issues related to Full Site Editing focus: e2e tests Issues related to e2e tests plugin: woocommerce Issues related to the WooCommerce Core plugin.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Hide the Products by Category, Tag, and Attribute templates from the templates list
2 participants