A developer picks up a new theme for a client’s store, opens the theme’s README, sees “WooCommerce compatible” in the plugin-compatibility list, and stops reading right there. That checkbox answers the wrong question. “Does this theme support WooCommerce” sounds binary, yes or no, but almost no theme actually answers it that way, because WooCommerce compatibility isn’t one thing. It’s a stack of separate, independently gradable layers: does the theme declare the right add_theme_support flags, does it override any of WooCommerce’s own template files, does it ship CSS for product grids and cart tables, does it style the checkout form, does it touch the mini-cart. A theme can be fully honest about “WooCommerce compatible” while doing real work on exactly one of those layers and nothing on the rest.

Brndle is a free, open-source WordPress theme built on Sage, Acorn, Blade templates, Tailwind v4, and Vite, a developer-facing stack rather than a page-builder product. Its own README lists WooCommerce under Plugin Compatibility, same line format as Yoast and WPML. That’s exactly the kind of one-line claim that deserves a source check rather than a nod, especially because our own earlier coverage of moving an Elementor build over to a block theme leaned on that same compatibility line without unpacking what it actually covers. This piece goes and checks, directly in the brndle-themes/brndle repository, what Brndle’s WooCommerce support really is: a real but narrow PHP-level integration, not a Blade-based template override system, and not something that reaches the product loop, single product page, cart, or checkout at all.

Brndle’s entire WooCommerce integration is one compatibility class, around 30 lines, that flips three gallery feature flags and swaps one wrapper <div>. There is no woocommerce/ override folder, no Blade view for a product page, and no CSS anywhere in the repo that targets a WooCommerce class. Everything past this line is the evidence and what it means for the pages you’ll actually have to style yourself.

In This Article

Why “does it support WooCommerce” is the wrong question

WooCommerce compatibility, for a theme, isn’t a single switch. It’s a checklist, and every item on it can be true or false independently of every other item:

  • Theme support flags. add_theme_support('woocommerce') and the gallery sub-flags (zoom, lightbox, slider) tell WooCommerce the theme has opted in to its default markup and JS behaviors. This is table stakes, a few lines of PHP, and most themes that claim any WooCommerce compatibility at least have this.
  • Layout wrapper integration. WooCommerce’s own templates print a content wrapper (woocommerce_before_main_content / woocommerce_after_main_content) so the shop content sits inside something. A theme can leave WooCommerce’s default wrapper alone, or replace it with classes that match its own grid system.
  • Template overrides. A theme can ship its own copies of WooCommerce’s PHP templates (traditionally in a woocommerce/ folder, or as Blade/block-template equivalents in a modern stack) to fully control the markup of the shop archive, single product page, cart, and checkout.
  • CSS styling. Independent of templates, a theme can ship CSS that targets WooCommerce’s own default markup, .woocommerce ul.products, .woocommerce-cart-form, .woocommerce-checkout, and so on, without touching a single template file.
  • Header/nav integrations. Mini-cart icons, cart fragment AJAX updates in the header, account dropdown slots. These live outside the main WooCommerce templates entirely, usually in the theme’s own header markup.
  • Block-based store support. WooCommerce has shipped its own block-based Cart, Checkout, and Mini-Cart blocks for several years now, which render independently of the classic PHP template system and have their own separate compatibility bar (block supports, theme.json alignment).

A theme that’s genuinely “WooCommerce compatible” by any reasonable reading could tick the first two boxes and nothing else, and that’s still an honest claim, not a lie by omission, provided nobody’s pretending it’s more than that. The problem isn’t that themes under-deliver on WooCommerce; it’s that “compatible” gets read by developers as “fully integrated,” and those are very different amounts of work. This matters more, not less, for a theme built on Blade, because Blade is unfamiliar enough to most theme reviewers that the natural assumption swings the wrong way: “it’s a modern templating stack, surely it reaches into WooCommerce’s templates too.” It doesn’t follow, and the only way to know for a specific theme is to read its specific code.

What we checked, and how

We cloned the brndle-themes/brndle repository directly from the main branch and grepped the entire tree, case-insensitively, for every occurrence of “woocommerce,” then followed each hit to its file and read the surrounding code. We also searched specifically for add_theme_support('woocommerce'), for a woocommerce/ template-override directory, for any Blade view file with a product/cart/checkout-shaped name, and for CSS selectors targeting WooCommerce’s own classes anywhere in the theme’s source (Tailwind input files, compiled public CSS, and theme.json). Below, everything is labeled by how we know it:

  • Confirmed, we read the exact file and the exact lines.
  • Confirmed absent, we searched specifically for it (filename patterns, grep for the relevant selector or hook) and found nothing.
  • Open question, it depends on runtime behavior we didn’t execute against a live WooCommerce install, flagged clearly as something to test yourself rather than asserted either way.

This is the same read-the-source-first method we used for Brndle’s WPML and Polylang compatibility, confirmed/inferred/untested labels and all, just pointed at a different compatibility class this time. Two hits came back from the case-insensitive search across the whole repository: app/Compatibility/WooCommerce.php and a one-line reference to it in app/Providers/ThemeServiceProvider.php. That’s the entire codebase footprint. README.md and readme.txt both mention WooCommerce once each, in their plugin-compatibility lists, and the theme’s own internal planning document for its mega-menu feature mentions WooCommerce twice, both times to explicitly say a WooCommerce-specific feature (a mini-cart slot in the header) was dropped from scope. We’ll get to that.

Confirmed from the source: what Brndle’s WooCommerce compatibility class actually does

Here is app/Compatibility/WooCommerce.php in its entirety:

namespace Brndle\Compatibility;

class WooCommerce
{
    public static function boot(): void
    {
        add_action('after_setup_theme', function () {
            if (! class_exists('WooCommerce')) {
                return;
            }

            add_theme_support('woocommerce');
            add_theme_support('wc-product-gallery-zoom');
            add_theme_support('wc-product-gallery-lightbox');
            add_theme_support('wc-product-gallery-slider');
        });

        // Wrap WooCommerce content in Brndle layout
        remove_action('woocommerce_before_main_content', 'woocommerce_output_content_wrapper');
        remove_action('woocommerce_after_main_content', 'woocommerce_output_content_wrapper_end');

        add_action('woocommerce_before_main_content', function () {
            echo '<div class="max-w-7xl mx-auto px-6 py-16">';
        });

        add_action('woocommerce_after_main_content', function () {
            echo '</div>';
        });
    }
}

And the registration, confirmed in app/Providers/ThemeServiceProvider.php:

if (class_exists('WooCommerce')) {
    \Brndle\Compatibility\WooCommerce::boot();
}

Read that closely, because every line earns its keep and nothing extra is happening. Two things are real, and they’re both real in the sense that they change WooCommerce’s actual rendered output on a live site, not just a documentation claim:

1. Theme support flags, confirmed

add_theme_support('woocommerce') opts the theme into WooCommerce’s structural defaults (the content wrapper actions this same class immediately overrides, breadcrumb hooks, sidebar behavior on shop pages). The three gallery flags, wc-product-gallery-zoom, wc-product-gallery-lightbox, and wc-product-gallery-slider, are WooCommerce’s own built-in product-image features: pinch/hover zoom, a click-to-expand lightbox, and a touch-swipeable slider for a product with multiple images. These flags don’t add any Brndle-authored code, they tell WooCommerce’s own JS (zoom.js, photoswipe, flexslider, all bundled inside the WooCommerce plugin itself) to initialize on the product gallery markup WooCommerce already renders. The theme’s entire contribution here is three boolean switches; the feature itself ships with WooCommerce, not with Brndle.

2. The content wrapper swap, confirmed, and this is the only genuinely Brndle-authored piece

This is the one real, custom piece of integration in the entire file, and it’s worth being precise about what it does and doesn’t touch. WooCommerce’s default behavior, before any theme touches it, is to wrap the main shop/product content in a generic <div class="col-full"> via two actions it fires around that content: woocommerce_before_main_content and woocommerce_after_main_content. Brndle’s compatibility class removes WooCommerce’s own wrapper callbacks from both actions and re-adds its own, printing <div class="max-w-7xl mx-auto px-6 py-16"> before the content and </div> after it, plain Tailwind utility classes that match the max-width, padding, and vertical rhythm Brndle uses for its own page layouts elsewhere.

That’s a real, working piece of theme-consistent styling, and it’s exactly as narrow as it looks: it changes the outer wrapper’s width and padding so a WooCommerce page doesn’t look like it’s sitting in a different theme’s layout grid. It does not touch anything inside that wrapper. The product loop markup, the single product gallery and summary, the cart table, the checkout form fields, none of that is rendered by this hook or affected by it in any way. Whatever classes WooCommerce’s own default templates print inside that wrapper, print unchanged.

Confirmed absent: no template overrides, no WooCommerce CSS, no mini-cart

This is the half of the picture that a one-line README claim doesn’t surface, and it’s the half that actually determines how much work a developer has ahead of them on a real store build.

No woocommerce/ template override directory

We searched the entire repository for a directory named woocommerce, the conventional location (yourtheme/woocommerce/) where a theme overrides WooCommerce’s bundled PHP templates. It doesn’t exist. We also checked for individual override files by name, archive-product.php, single-product.php, cart.php, checkout.php, anywhere in the theme, classic PHP or otherwise. None exist.

No Blade views for any WooCommerce page type

Brndle’s resources/views/ directory, the same place we mapped out when walking through which GeneratePress hooks become Blade views, holds the theme’s actual Blade templates: index.blade.php, page.blade.php, single.blade.php, search.blade.php, 404.blade.php, plus a set of custom page templates (template-homepage.blade.php, template-landing.blade.php, template-canvas.blade.php, template-transparent.blade.php) and a large library of partials for blog archive and single-post layouts. There is no archive-product.blade.php, no single-product.blade.php, no cart.blade.php, no checkout.blade.php, no generic woocommerce.blade.php catch-all. If Brndle had built a Blade-based override layer for WooCommerce the way it built one for blog posts and pages, this is exactly where it would live, and it isn’t there.

No CSS anywhere targeting WooCommerce’s own markup

We grepped the Tailwind source files, the theme’s theme.json, and every compiled stylesheet for any selector referencing WooCommerce’s class names, .woocommerce, .products, .single-product, .woocommerce-cart-form, .woocommerce-checkout, and so on. Zero matches. The product grid, the single product layout, the cart table, and the checkout form all render with whatever default appearance comes bundled inside the WooCommerce plugin itself, which is deliberately plain and unopinionated so any theme can style over it. Brndle doesn’t.

No mini-cart, and the theme’s own planning doc says why

Brndle’s public repository includes a planning document for its mega-menu feature, and it’s unusually candid about this exact scope decision. Item 28 on that plan’s feature table reads, struck through: “Mini-cart slot, Dropped, Brndle is not WooCommerce-focused; not in scope. WC sites can use Max Mega Menu or a WC-specific theme.” That’s the theme’s own maintainers, in their own working notes, drawing the line explicitly. A separate line in the theme’s AI usage guide repeats the same position for product grids: “E-commerce product grids, Brndle isn’t WooCommerce-focused. Use WooCommerce blocks for product UI.” Neither of those is marketing copy walking back a claim after the fact; they’re internal planning notes that happen to be public because the whole repository is open source, and they match exactly what the code shows.

This is the part worth flagging honestly rather than guessing at, because it’s a real architectural wrinkle specific to Blade-based themes and it’s the kind of thing a developer should verify on a live install before promising a client anything about shop pages.

Brndle doesn’t render its header and footer the classic WordPress way, through standalone header.php and footer.php files that WooCommerce’s own templates call via the core get_header() and get_footer() functions. We checked: Brndle ships neither file, anywhere in the theme. Instead, the header and footer markup is included directly inside the theme’s main Blade layout, confirmed in resources/views/layouts/app.blade.php:

@unless($hideHeader ?? false)
  @include('sections.header')
  @include('partials.header.search')
@endunless

<main id="main" class="main">
  @yield('content')
@endyield

@unless($hideFooter ?? false)
  @include('sections.footer')
@endunless

Every page that gets rendered through this layout, every post, every page, every custom Brndle template, gets the real header and footer this way, because they’re part of the same Blade file as the rest of the page shell. The theme does also fire do_action('get_header') and do_action('get_footer') inside that layout, but on inspection those are just exposing the standard WordPress hook points so that other plugins (analytics snippets, tracking pixels) that expect to attach to get_header/get_footer still fire correctly. They’re not how Brndle renders its own chrome.

The open question is what happens for a WooCommerce page specifically. WooCommerce’s default archive-product, single-product, cart, and checkout templates are classic PHP files that WooCommerce itself serves (via its own template_include filter) when a theme hasn’t overridden them, exactly the situation here since Brndle has no override directory. Those WooCommerce-supplied templates call WordPress’s standard, file-based get_header() and get_footer() functions directly, the functions that look for a literal header.php or footer.php in the active theme. Since Brndle ships neither, we can’t confirm from source alone whether those calls render Brndle’s header and footer, render nothing, or get bridged some other way we didn’t find evidence of in the repository. We found no header.php/footer.php stub file anywhere in the theme that would normally exist specifically to cover this case for classic-template plugins.

To be direct about what this means practically: don’t take either outcome on faith. Install WooCommerce on a Brndle site, visit /shop/, and look. If the nav and footer are missing or visually broken on that page while they’re fine on every normal post and page, that confirms the gap described above and tells you exactly where to start (a header.php/footer.php bridge file, covered in the practical guide below). If they render fine, something in WooCommerce’s own template loading or in the active WooCommerce version’s output is doing more than the static source alone suggested. Either way, this is a five-minute check, not a theoretical risk, and it’s the single most important thing to verify before you promise a client anything about how their shop pages will look.

Practical guide: styling and customizing WooCommerce pages in Brndle

Given everything above, here’s what actually has to happen if you’re building a real store on Brndle, in the order you’ll hit it.

Step 1: Verify the header/footer render on a live WooCommerce page first

Before touching any styling, install WooCommerce, visit the shop archive and a single product page, and confirm Brndle’s nav and footer are actually present. If they aren’t, you need a bridge before anything else matters. A minimal fix is a theme-root header.php and footer.php that each render the same Blade partials the main layout uses:

<?php
// header.php
echo view('sections.header')->render();
echo view('partials.header.search')->render();
<?php
// footer.php
echo view('sections.footer')->render();

This gives WooCommerce’s classic get_header()/get_footer() calls something real to find, without touching Brndle’s own Blade routing for every other page type. Treat it as a starting point to test against your actual WooCommerce version, not a guaranteed drop-in, since you’re bridging two rendering systems that weren’t designed to talk to each other.

Step 2: Decide whether to override WooCommerce’s templates or just style the defaults

Because there’s no existing override layer to extend or fight with, you’re choosing cleanly between two paths with no leftover theme code in the way either direction:

  • Style the defaults. Fastest path. WooCommerce’s bundled markup is plain but semantic (real <ul>/<li> product lists, a real <table> for the cart, labeled form fields on checkout), so a focused Tailwind stylesheet targeting .woocommerce selectors gets you most of the way without touching a single PHP template. This is the path most Brndle store builds should take.
  • Override templates. Copy the specific WooCommerce plugin template you need to change into a woocommerce/ folder in the theme (the standard WooCommerce convention, independent of Brndle), and either leave it as plain PHP or convert it to call a Blade view you write yourself. Reach for this only when you need structural changes the CSS path can’t reach, a different product card layout, a custom checkout field order, not for visual polish alone.

Step 3: Scope a WooCommerce stylesheet the way Brndle scopes its own CSS

Add a dedicated resources/css/woocommerce.css Tailwind entry, enqueued only on WooCommerce pages (is_woocommerce(), is_cart(), is_checkout()), rather than folding WooCommerce overrides into the theme’s main app.css. This keeps the baseline, zero-WooCommerce-CSS footprint intact for every Brndle site that doesn’t run a store, which matches how the theme already scopes its optional JS (mega menu, dark mode, view transitions all load conditionally). At minimum, plan to style: the product grid (ul.products, li.product), price and sale-badge markup, the add-to-cart button, the single product gallery and summary columns, the cart table and totals block, and the checkout form’s field groups and order-review table.

Step 4: Match the content wrapper’s rhythm, don’t fight it

Remember that max-w-7xl mx-auto px-6 py-16 wrapper is already in place around every WooCommerce page’s main content. Whatever you build inside it should use the same spacing scale (Brndle’s Tailwind tokens, not ad hoc pixel values) so a product grid doesn’t look like it was dropped in from a different design system. If you need a different max-width for the shop archive specifically (common for a wider product grid), override the wrapper with your own hook callback at a later priority rather than fighting the existing one with CSS overrides.

Step 5: If you want the block-based Cart/Checkout, test that path separately

Everything above describes WooCommerce’s classic PHP template path, which is what actually runs by default with no theme override present. If you instead build your cart and checkout pages from WooCommerce’s own Cart and Checkout blocks (through the block editor, not the classic shortcode pages), you’re on an entirely different rendering path, one governed by block supports and theme.json alignment rather than anything in app/Compatibility/WooCommerce.php. Brndle’s theme.json wasn’t found to contain any WooCommerce-block-specific configuration during this check, so treat the block-based store flow as its own, separately-untested path, not something covered by the compatibility class this piece is about. If you want to see how a theme built specifically for that block-based store path handles it, our teardown of Purple, WooCommerce’s own starter block theme, is a useful comparison for what a ground-up block-first approach looks like next to Brndle’s much narrower classic-template compatibility.

Step 6: Wire a mini-cart yourself if you need one

Since Brndle’s own maintainers deliberately dropped a mini-cart header slot from scope, a cart icon with a live item count in the header is a build-it-yourself feature: hook into woocommerce_add_to_cart_fragments for the AJAX-refreshed count, add the markup inside sections.header, and style it with the same utility classes the rest of the header uses. It’s a well-documented WooCommerce pattern independent of any theme; there’s just nothing in Brndle today that does it for you.

FAQ

Does Brndle officially support WooCommerce?

Brndle’s README lists WooCommerce under Plugin Compatibility with the description “Gallery zoom/lightbox/slider, theme-consistent wrappers,” and that description is accurate; it’s exactly what the code does, no more. There’s a real, working compatibility class in the repository. What it does not mean is that Brndle overrides WooCommerce’s templates or ships WooCommerce-specific CSS, because it doesn’t do either.

Does Brndle use Blade templates for WooCommerce pages?

No. We checked resources/views/ directly and there is no Blade view for a product archive, single product page, cart, or checkout. WooCommerce’s own classic PHP templates render those pages by default, with Brndle’s compatibility class only affecting the surrounding content wrapper and three gallery feature flags.

Will my shop pages look like the rest of my Brndle site out of the box?

Partially. The outer content wrapper will match Brndle’s own max-width and padding, because that specific swap is real and confirmed in the source. Everything inside that wrapper, the product grid, single product layout, cart table, and checkout form, renders with WooCommerce’s own plain default styling, not Brndle’s design system, until you write CSS for it yourself.

Is there a dedicated WooCommerce template folder in Brndle, like other themes ship?

No. We searched specifically for a woocommerce/ directory, the standard location a theme uses to override WooCommerce’s bundled templates, and it doesn’t exist anywhere in the repository. If you need to override a specific WooCommerce template, you’re creating that folder and those files yourself, following WooCommerce’s own standard override convention, not a Brndle-specific one.

Yes, confirmed in app/Compatibility/WooCommerce.php: the theme declares wc-product-gallery-zoom, wc-product-gallery-lightbox, and wc-product-gallery-slider support. These three features are built into WooCommerce itself and activate on the standard product gallery markup once a theme opts in; Brndle doesn’t add any of its own gallery code on top.

This is the one open question in this assessment. Brndle renders its header and footer through Blade includes inside its main layout file, not through classic header.php/footer.php files, and WooCommerce’s default templates call the classic, file-based versions directly. We found no bridge file in the theme covering this. Test it on a live install before assuming either outcome; it’s a two-page check and it’s the first thing to confirm before building anything else.

Is there a mini-cart or header cart icon built into Brndle?

No, and the theme’s own public planning document says so directly: a mini-cart header slot was deliberately dropped from the mega-menu feature’s scope because “Brndle is not WooCommerce-focused.” You’ll need to wire this yourself with WooCommerce’s standard cart-fragment hooks if a client needs it.

Should I use WooCommerce’s block-based Cart and Checkout instead of the classic pages?

That’s a separate rendering path from everything covered in this piece, governed by block supports and theme.json rather than the compatibility class we read. We didn’t find WooCommerce-block-specific configuration in Brndle’s theme.json during this check, so treat that path as untested here and verify it independently if you go that route.

Does this mean Brndle is a bad choice for a WooCommerce store?

Not automatically, but it changes the scope of the work honestly. Brndle gives you a correctly-aligned content wrapper and WooCommerce’s own built-in gallery features for free, and it doesn’t fight you with leftover template overrides you’d have to work around. What it doesn’t give you is store-specific styling, template customization, or a mini-cart, those are yours to build, the same way they would be on any general-purpose theme that’s honest about not being a dedicated WooCommerce theme. If the project is primarily a content site with a small supporting shop, that trade is probably fine. If the project is a store-first build, budget real time for the styling and header-bridge work above, or consider a theme built specifically around WooCommerce instead.

How does this compare to Brndle’s WPML/Polylang compatibility?

Similarly narrow, and similarly honest about it. Brndle’s WPML/Polylang compatibility class is one hook that prints hreflang tags, and it only fires correctly for WPML, not Polylang alone (Polylang covers itself independently either way). Both compatibility classes follow the same pattern: a small, real, correctly-scoped piece of integration, clearly short of a full implementation, with the gap left for the site builder to close rather than papered over in the documentation.

Conclusion

The useful answer here isn’t “Brndle supports WooCommerce” or “Brndle doesn’t support WooCommerce.” It’s the specific, checkable list: a compatibility class that genuinely exists and genuinely does two things, flips three gallery feature flags and swaps WooCommerce’s default content wrapper for a Tailwind-classed one that matches the rest of the theme. Past that, the product loop, single product page, cart, and checkout all render through WooCommerce’s own unmodified classic templates, with no Brndle-authored Blade view, no Brndle-authored CSS, and no mini-cart anywhere in the picture. The theme’s own maintainers say as much in their public planning notes, calling Brndle “not WooCommerce-focused” in two separate places, which lines up exactly with what the code shows rather than contradicting it.

The one piece worth testing before you build anything else is whether a WooCommerce page even inherits Brndle’s header and footer, since those render through a Blade include rather than the classic header.php/footer.php files WooCommerce’s templates call directly, and we found no bridge file covering that gap in the current source. Check it on a staging install first. Past that, the path forward on a real store build is clear and not particularly hard: style WooCommerce’s own default markup with a scoped stylesheet, override specific templates only where you need structural changes CSS can’t reach, and build a mini-cart yourself if the project needs one. None of that requires fighting Brndle’s architecture. It just requires knowing, before you start, exactly how much of the work the theme is actually doing for you, which is the whole point of reading the source instead of the README.