WooCommerce templates only load when user is logged in (Sage 11 + generoi/sage-woocommerce)

I’m updating a site to Sage 11 and integrating WooCommerce (version 9.9.4).

I’m using the generoi/sage-woocommerce package to handle WooCommerce template overrides via Blade.

Everything seems to work fine — but only if I’m logged in. When not logged in, WooCommerce seems to fall back to its block-based templates instead of using my custom Blade files.


:white_check_mark: When logged in

The correct template loads:

resources/views/woocommerce/archive-product.blade.php

My log (using Acorn’s logging system) confirms:


[2025-06-22 14:33:32] development.DEBUG: 🟢 archive-product.blade.php loaded

Logged-in view (custom layout loaded):

:cross_mark: When not logged in

The template is ignored. The rendered page lacks the theme’s header/footer/layout.

It appears WooCommerce is using its block-based fallback (likely the cart/checkout block layout).

Anonymous view (unstyled block layout, missing header/footer):


➤ What I’ve checked

  • I have no content inside the Shop page (no shortcodes, no blocks).

  • The page is correctly set as the Shop page under WooCommerce → Settings → Products.

  • I’m using theme.json (it’s a classic theme, not a block theme).

  • generoi/sage-woocommerce is installed, discovered, and published.

  • The file resources/views/woocommerce/archive-product.blade.php exists.

  • I’m using Trellis + Bedrock + Sage 11.

  • I’m logging output via Log::debug() in archive-product.blade.php.


➤ Context and References

In this thread:

A similar issue was reported, and the solution was to replace blocks with shortcodes inside the WooCommerce pages (like Cart or Checkout) to force WooCommerce to use classic templates.

Also related:

https://github.com/woocommerce/woocommerce-blocks/issues/891

In WooCommerce 9.x+, the default pages (shop, cart, checkout) are created with block-based content by default. These do not use classic templates.


➤ My question

Is there a reliable way in Sage 11 (with generoi/sage-woocommerce) to force WooCommerce to use the Blade template for the Shop page?

Any workaround to disable the block-based fallback in WooCommerce 9.9.4 for the Shop page?

Thanks in advance!

Is this behavior occurring on a live environment or locally? The fact that it works, but only if you’re logged in, leads me to believe there may be something cache related causing issues, as typical behavior of a lot of caching solutions is to bypass the cache if the user is logged in.

If you’re using any caching I would try purging it completely or even disabling it and see if the problem resolves itself.

Thanks for the suggestion. FastCGI cache is enabled on the staging environment but disabled in development — and yet both environments present the same issue.

You can compare the following pages on staging:

The issue does not happen in another project using the same stack (Trellis, Bedrock, Sage 11, WooCommerce, and generoi/sage-woocommerce), so it seems related to something specific in this theme or how WooCommerce handles block rendering in this context.

Do you have your shop disabled unless the user is logged in? I see a “coming soon” page at /shop so I wonder if the issue is not logged in vs not logged in but instead an issue with how the coming soon page template is rendered?

1 Like

Thank you for your question — it actually gave me the key to solving the issue. When you asked whether I had the shop disabled for non-logged-in users, I double-checked the WooCommerce setup and realized that the final step in the setup checklist — “Publish your store” — hadn’t been completed yet.

That missing step was the root cause. Until it’s done, WooCommerce keeps the Shop page in a special unpublished state that behaves differently depending on whether you’re logged in or not:

  • Logged-in users see the correct template (in my case, archive-product.blade.php, rendered via generoi/sage-woocommerce)
  • Logged-out users are shown a block-based fallback, ignoring the theme’s templates entirely.

This behavior makes the issue particularly confusing, since it looks like a template override problem or a caching issue — but it’s simply a hidden state tied to the setup wizard. Completing the checklist immediately fixed the problem.

Thanks again for pointing me in the right direction.

3 Likes

Great topic y’all. I just published a guide for the Sage docs since things have gotten a lot more complicated with both the WooCommerce blocks and their new live mode. Credited @aitor @YourRightWebsite, along with @csorrentino and @strarsis who have helped out in other topics:

https://roots.io/sage/docs/woocommerce/

4 Likes

A question that is missing from the guide:

Is installing this officially necessary if the user wants to use WooCommerce at all? Or only if they want to modify the templates?

I’m asking because we’re using WooCommerce on Sage 10 and on Sage 9 beforehand and all we added was some CSS and it works just fine.