Custom product taxonomy Archive Layout: condition not matching / empty product loop

Hi,

I’m trying to build a WooCommerce Archive Layout for a custom product taxonomy called “Subject” (registered via ACF Pro, public and publicly queryable, attached to the product post type). I’ve hit two related but distinct issues and would appreciate help isolating the cause.

Setup:

  • Custom taxonomy: Subject (slug: ew_subject or similar, ACF Pro, public and publicly_queryable both true, correctly registered and confirmed working via is_tax() and body classes in Query Monitor)
  • Archive Layout built in Cornerstone/Pro, containing a title, breadcrumb, and a product grid (Looper Consumer set on the product column, same structure used successfully on every other archive layout on this site, no explicit Looper Provider added, consistent with your documentation stating Archive Layouts use the default WordPress Query)
  • 156 products correctly assigned the “Bird” term within this taxonomy
  • WordPress: [version], WooCommerce: [version], Pro theme: [version], Cornerstone: [version]

Issue 1: “Product Taxonomy is Subject” condition doesn’t trigger the Archive Layout at all

With the Archive Layout’s condition set to “Product Taxonomy is Subject”, visiting any Subject term archive (e.g. /subject/bird/ ) shows the plain default WooCommerce archive template, no Cornerstone styling, no custom title or breadcrumb, just the stock grid. Adjusting Assignment Priority (tested 0, 10, -10) made no difference.

Using Query Monitor, I confirmed:

  • Template File used: wp-content/plugins/woocommerce/templates/archive-product.php (loaded directly from the WooCommerce plugin, not the theme)
  • Template Hierarchy correctly listed taxonomy-specific templates for this term ( taxonomy-ew_subject-bird.php , taxonomy-ew_subject-28.php , etc.) and included framework/legacy/templates/archive.php further down the chain
  • Body classes confirmed tax-ew_subject , term-28 , term-bird , confirming WordPress correctly recognises the archive context

This suggests WooCommerce’s own template_include hook is claiming the request before Cornerstone’s Archive Layout system evaluates the “Product Taxonomy” condition, or that condition is scoped to a singular-product context (checking whether a specific product has a term) rather than an archive context, and therefore never matches on an archive page. Deactivating two custom plugins that also hook pre_get_posts made no difference, ruling those out.

Issue 2: “Product Subject: [specific term]” condition does trigger the layout, but the product grid is empty

As a diagnostic test, I changed the condition to “Product Subject: Bird” (the term-specific condition). This did successfully engage the Archive Layout, the custom title (“BIRD”), breadcrumb (“Home → Bird”), and overall Cornerstone styling all rendered correctly on the front end. However, the product grid itself showed no results.

Confirmed via testing:

  • Disabling/unassigning the Archive Layout entirely reverts to the default WooCommerce template, which correctly displays all 156 Bird products, confirming the underlying WP_Query for this taxonomy archive is correct
  • The Looper Consumer is placed on the product column exactly as on our other (working) archive layouts, no explicit Provider, per your documentation on Archive Layouts using the default WordPress Query
  • No custom plugins were interfering (tested with two candidate plugins deactivated, no change)

Questions:

  1. Is there a supported, dynamic “any term” Archive condition for custom product taxonomies (equivalent to “Product Category Archive”, which does exist in our condition picker), or is “Product Taxonomy” intended to serve that role and this is a bug?
  2. Given Issue 2, once a layout is correctly triggered for a custom product taxonomy archive, is there a known reason the built-in main-query Looper would return zero results despite the underlying WP_Query / WC_Query being confirmed correct outside of Cornerstone’s rendering?

Login details in the Secure Note!

Many thanks,
Christopher

Hey Christopher,

Thank you for reaching out. I understand the “Product Taxonomy is Subject” condition does not apply your WooCommerce Archive Layout on your ACF-registered “Subject” term archives, and that the term-specific condition applies the layout, but the product grid renders empty. Please review the steps below to isolate the cause.

  1. Test whether the main query is empty on that request – “Product Taxonomy is Subject” is the dynamic any-term condition you are looking for. It differs from “Product Subject: Bird” in one respect: it first checks that the posts returned for the request resolve as Products, then checks the Subject archive. The term-specific condition checks the term only. When the first passes and the second fails on the same URL, the request is not returning Product posts at the time the layout is chosen. To confirm this without code, add the condition “Has Posts – Yes” to your working “Product Subject: Bird” condition group and reload /subject/bird/. If the layout stops applying, the main query on that URL is empty, which also explains the empty grid, since the archive product grid reads the same main query. Please also unassign the layout temporarily and confirm whether the default WooCommerce template actually lists the 156 products on /subject/bird/.

  2. Review the ACF taxonomy registration – In ACF > Taxonomies > Subject, confirm Post Types is set to Product only, and that Public, Publicly Queryable and Query Var are all enabled with the rewrite slug set to “subject”. A taxonomy attached to a second post type can return that type first on a term archive, which fails the Product check. After any change, save WordPress Settings > Permalinks once to flush rewrite rules.

  3. Review product visibility and the grid’s provider – The archive grid skips any product WooCommerce reports as not visible. Open one “Bird” product and confirm Catalog Visibility is “Shop and search results” and the product is in stock, and check WooCommerce > Settings > Products > Inventory for “Hide out of stock items”. Then select the grid’s container in the layout and confirm the Looper Provider is the default current query (Shop) rather than a Query Builder or Query String provider filtered to Product Categories, which would exclude Subject terms.

By the way, the password in the secure note seems incorrect. I cannot log in. Please double-check it so I can check your archive layout.

Best Regards.

Hi @Ruenel,

Thanks for the detailed reply. I have resaved the login details and they should work for you now.

Point 2 above is where you gave me the clue. The taxonomy is registered to Products and a CPT called Artwork. This website is more complex than a standard eCommerce site, as we are are planning for the future where new collections and product types will be added, but we want to avoid duplication of core data. Therefore, a series of CPTs and Taxonomies have been created and been interlinked using a bespoke plugin. The addition of the below resolved the problem instantly:

/* =============================================================================
STEP 12: FORCE post_type ON SUBJECT TERM ARCHIVES

ew_subject is registered on both product and ew_artwork, so its own term archive query (/subject/bird/) has no reason to return only Products: WordPress has nothing telling it to prefer one post type over the other on that URL.

This matters because Cornerstone's Archive Layout's built-in Looper reads the same main query, and the "Product Taxonomy is Subject" condition (per Themeco support) checks that the query resolves as Products before checking the Subject term, so an unfiltered, mixed query causes both the condition to fail to apply the layout at all, and, on the one condition that does apply it ("Product Subject: [term]", which does not run that Product check), an empty grid. WooCommerce's own default archive-product.php template was already working around this by forcing post_type => product itself via WC_Query->pre_get_posts(), which is why the plain WooCommerce  template correctly showed all 156 Bird products throughout  troubleshooting even though the underlying main query was ambiguous. 

Scoped narrowly to is_tax( EW_TAX_SUBJECT ) on the front-end main query only, so this has no effect on Artwork's own admin screens or  any other query on the site.
============================================================================ */

    add_action( 'pre_get_posts', function ( $query ) {

    	if ( is_admin() || ! $query->is_main_query() ) {
    		return;
    	}

    	if ( is_tax( EW_TAX_SUBJECT ) ) {
    		$query->set( 'post_type', 'product' );
    	}
    } );

Thanks for pointing me in the right direction!
Christopher

Hello Christopher,

Good to know that your issues have been resolved. We really appreciate for letting us know.

Cheers.

This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.