Issue #194 Loop WP

Hi, {{first_name|friend}}. 👋

Welcome to Issue #194 of Loop WP!

Last week was part one of a three-part mini-series based on Beau Lebens interview on the Do The Woo Podcast.

This week, it’s part two as we discuss the remaining interview questions, from Agentic Commerce and fees, a decoupled WooCommerce, “Commerce Mode” and more.

Let’s go! 👇

So you can easily follow along, and know who is saying what, here’s a key:

Now on to the remaining questions.

Beau highlighted that “data visibility” is strongest through WooPayments and opt-in data sharing:

Woo is working with major partners (Google/OpenAI/Stripe), but its openness makes implementation more challenging than with controlled platforms.

💡 This was exactly my thinking when I discussed this question in detail and Woo’s options back in Issue 192.

🚨 James framed it as active work, with technical uncertainty remaining:

“We don’t know exactly what that looks like right now… [but] the team is working… heavily on [it].”

🚨 I added a clarification point later in the live interview, defining what I meant by “decoupled”: a separately maintained Woo version or modules, with a more controlled/managed, and optimised approach, like Shopify.

The answer and additional points below are based on the original question and my clarification point (which James did a good job deciphering, sorry, James!)

💡Beau agreed with the spirit: offer something beyond “normal Woo” through restrictions, curated extensions, controlled environments, and improved onboarding:

“Offering something that’s not your normal Woo… apply some extra restrictions… build some custom stuff on top… totally valid.”

Beau identified complexities:

🚨 🔮 The big news is that Beau said something that answers issues 2 and 3 (51:04) is “most likely in our [Woo’s] future!

James points out that a subset of merchants don’t want maximum flexibility; they want a fast launch and a professional store. Whilst it’s complex, there’s definitely demand for something that is not the standard Woo.

💡 I think we all feel this pain as WordPress users, and I love both Beau and James’ openness and investigative work to date.

I agree that this is not necessarily a WooCommerce problem, but I appreciate that WooCommerce would consider addressing it at the WooCommerce level.

🧠 Beau frames it as a platform/framework issue requiring better APIs (e.g., a centralised notification system). “If… there was a better, easier-to-use API… they would do that.”

Woo may tackle it at the Woo layer, but WordPress plugins still affect the overall experience. Beau highlighted the positive momentum in the WordPress design system/admin redesign, but notes that developer buy-in is essential.

🚨 James Kemp added that UI improvements are constrained by backwards compatibility and integration with extensions; full redesigns can break ecosystems.

🧠 Katie Keith added (from a developer perspective) that a clear, complete design library and clearer timelines (not “consult then never ship”) would greatly help when developers are building for Woo.

💡 I agree with Beau here: in my experience with WooCommerce merchants, WordPress is secondary; they don’t care about it.

🧠 Beau goes on to explain that Woo is exploring menu and settings changes (e.g., moving Orders to the top level). He proposes an optional commerce mode to align with plugin ecosystem expectations and to support different user types (commerce-only vs. blended).

“Given what we’re looking at… we end up with some sort of option. A Default [new stores]… toggle… flip back to the old menu for existing users…”

🧠 James really liked the idea of a Commerce mode, added some important additional points:

💡 I strongly favour opinionated defaults, so what Beau said next pleased me. Beau stated that Woo should go further with defaults because merchants request them, but always keep the ability to change them:

“Merchants… want us to be more opinionated with defaults… but… still have the option to change…”

🚨 Beau then extended this to default functionality: more should be in core, but done via layered architecture (capability → core UI → optional advanced services), he said:

“We haven’t done enough… people don’t expect to have to go get separate extensions…”

🧠 Beau used the recent changes to shipment tracking as a good example. Core capability standardises data storage/access; advanced features can remain extensible.

🧠 James went on to add: “It’s about time we kind of replace Storefront,” and that this new theme could do that, improve demos and block quality across the ecosystem.

🧠 Beau Lebens reinforced this by noting that a standard theme helps Woo test performance, mobile-friendliness, and visual consistency.

It would be particularly useful if demos defaulted to the new block theme to improve consistency and potentially reduce fragmentation across the ecosystem.

🧠 Beau added that feedback should include concrete goals, what you’re trying to achieve, so that the team can reverse-engineer necessary settings and controls.

Don’t forget, if you missed Part One in this series, you can catch up now.

💡 Next week is the final part of our series, as we compare and contrast Matt and Beau’s answers with my thoughts.

🏝️ I’m on holiday this week, and this email has been scheduled so the News & Tips section is smaller than usual.

That’s it for this week, {first_name|friend}}. 👋

This week's excellent and insightful WordPress News & Tips:

If you have a question about this email or WordPress, please reply, and I will respond as soon as possible.

👋 Until next time,