What’s New With Woo?  🔗 **Source:** [What’s New With Woo?](https://www.youtube.com/watch?v=OkIVNKJADVo) > [!note]+ Document Notes > tags: [woocommerce, block-themes, issue-backlog, agentic-commerce, model-context-protocol, extension-ecosystem] > author: The WP Minute > source: YouTube — The WP Minute (Member Meetup) > reference: https://www.youtube.com/watch?v=OkIVNKJADVo > date created: 2026-08-24 09:00 > > > [!info] Generated analysis — not the author's words. Sections below are machine-written > > from the captured source. Only text inside `> [!quote]` blocks is verbatim from the author. > > Do not quote or attribute any other line to the named author. > > # 🏷️ Title: What's New With Woo? (July 2026 Member Meetup) > <!-- deep-read:sections start --> ## 🧭 Table of Contents - [📝 Summary](#-summary) - [📖 Main Content](#-main-content) - [🗒️ Notes](#️-notes) - [📚 References](#-references) - [🗣️ Paraphrase](#️-paraphrase) - [📰 Newsletter](#-newsletter) - [✅ Action Items](#-action-items) - [🧪 Hypotheses](#-hypotheses) - [📊 Methodology](#-methodology) - [❓ Questions](#-questions) - [🔮 Future Research](#-future-research) - [💡 Implications](#-implications) - [🧠 Learning Styles Assessment](#-learning-styles-assessment) - [📊 Accessibility Assessment](#-accessibility-assessment) - [🌍 DEIB Assessment](#-deib-assessment) - [✅ Logical Validity](#-logical-validity) - [🛡️ DARVO Analysis](#-darvo-analysis) - [🎯 Conclusion](#-conclusion) ### 🔗 References - [The WP Minute](https://thewpminute.com/) — publisher; member meetup series, Matt Medeiros present - [developer.woo.com](https://developer.woo.com/) — the Woo developer blog, newsletter, and documentation hub named as the central place to follow this work - [WooCommerce on GitHub](https://github.com/woocommerce/woocommerce) — where the issue-backlog cleanup is visible - [WordPress Playground](https://wordpress.github.io/wordpress-playground/) — discussed and its limits for Woo named - [Studio by WordPress.com](https://developer.wordpress.com/studio/) — Automattic's local development tool with a built-in agent - [Ollie](https://olliewp.com/) — the block theme the guest says he personally uses for his own Woo builds - [Storefront](https://wordpress.org/themes/storefront/) — the decade-old classic Woo theme the new block theme succeeds ## 📝 Summary - **What happened.** The WP Minute's July 2026 member meetup, hosted with Matt Medeiros present and featuring Brian Richards, developer advocate at WooCommerce. It is a wide-ranging status update: a deliberate multi-quarter issue-backlog cleanup, the core-versus-extension boundary problem, a settings UI modernization that auto-converts PHP field definitions to React, an unreleased first-party block theme, and three distinct strands of AI work. - **Why it matters.** Two items have real substance behind them. The **backlog cleanup** is a stated commitment to get GitHub down to a couple hundred open issues with nothing older than roughly six months, against five-to-seven-year-old issues currently in there — with an explicit norm that filing a bug earns a response even when the answer is "expected behavior." And the **settings auto-conversion** is a genuinely clever piece of platform design: because Woo already has a PHP class where extensions declare their settings as an array, Woo can render those same declarations in React without the extension author doing anything. - **Key stakeholders.** Store owners running 10–30 plugins; extension developers facing a settings-UI migration they did not ask for and may not need to do; agencies deciding block-versus-shortcode on new builds; the wider WordPress project, since Woo is explicitly used as the proving ground for decisions core later inherits. - **Risks and tradeoffs.** The AI section is heavily forward-looking and partly embargoed — the guest twice says he did not get permission to show things and "probably should have asked" what he could say. Agentic commerce is honestly labeled as not actually happening yet. The block checkout's extensibility limits are acknowledged rather than solved. And the settings unification will flatten extension branding, which some plugin authors have already objected to. - **Bottom line.** The consistent theme is **Woo pushing functionality down into core blocks and core APIs so it arrives everywhere at once** — the block theme is thin because the blocks are thick; WordPress 7.1's responsive styles land free across 100+ Woo blocks; shipment tracking becomes one extensible API rather than per-provider UIs. The AI work is real but mostly unreleased, and the most concrete near-term wins are unglamorous: fewer old bugs, a consistent settings UI, and a much better product catalog screen. ## 📖 Main Content The meetup opens on the least glamorous and probably most consequential item: **WooCommerce is spending several quarters clearing its GitHub issue backlog.** Richards frames this against a pressure every large open source project now shares — AI-generated pull requests arriving in volume. His description is even-handed rather than dismissive: people "vibe code to PR and send it to you, which is rough. It's nice, but it's rough," because human review and triage still cost the same regardless of how cheaply the submission was produced. Combined with the ordinary backlog that any large-install-base platform accumulates, the project reached a point of deciding to just clear it. James Kemp, the product lead, is triaging and assigning through the product and engineering teams. The target is a couple hundred open issues with nothing older than roughly half a year, replacing issues currently five to seven years old. Richards describes closing one about a button that did not work, filed five years earlier, whose history showed it added to a list, removed, and orphaned when the engineer left. The stated principle is the good part: **if someone put in the effort to file a bug report, the project owes them a resolution or at least a clear answer** — including "that's expected behavior, not a priority." He is explicit that these are "not fun exciting features" but "paper cuts that just people deal with every day," which is the same framing and nearly the same vocabulary as Ella van Dorpe's block editor paper cuts effort in the Gutenberg project. The host raises the harder strategic question, referencing his own op-ed in The WP Minute newsletter: WooCommerce can sell anything and do almost anything through extensions, but the result "becomes a little bit of a tangled mess" once you stack extensions and payment providers. Can Woo become a more user-friendly all-in-one? Richards's answer is a clear no, with reasoning. Woo core is "just the foundational layer," and he does not believe there will ever be a Jetpack-style bundle for it, because **the things stores need most are precisely the things that vary most** — every store uses different payment, email, shipping, and tax providers. What Woo can do is tier the ecosystem. A small set of first-class extensions get built or partnered directly: payment providers, with WooPayments working closely with Stripe; ad and channel connections to Google, TikTok, Reddit; marketing tools like Klaviyo and Mailchimp. Beyond that, he says plainly, "it's a wild west." Most extensions installed on Woo stores do not come from Woo's marketplace, which means no revenue share and no control. The marketplace is the first line of quality — listing requires substantial integration, unit, and release testing — but he expects the average store to run 10 to 30 plugins and doubts that changes. There is movement toward consolidation at the margins: add-ons bundled into Subscriptions, and some plugins that previously cost around $70 a month folded into core for free. The stated heuristic is what roughly 80% of users actually need. His closing framing is worth keeping: this "is not even a WooCommerce problem, it's an e-commerce problem," which is true but also somewhat convenient. **Shipment tracking, currently in beta, is the model for how Woo intends to resolve these cases.** Everyone needs tracking and the "your package is on its way" email regardless of carrier, so Woo builds "the extensible API that anybody can hook into and anybody can do it and they can't break it," plus one user interface — and providers do their own work on top. General functionality in core, provider specifics in extensions. The host floats table rate shipping as another candidate that has long been discussed for core. **The settings UI work is the most technically interesting item in the meetup.** WordPress currently has two worlds: classic PHP settings screens, and the React-based modern interface. Woo extensions already declare settings through a PHP class — an array saying "checkbox to turn it on, text field for my API key" — which Woo itself renders. The WooPayments team, wanting to move to JavaScript, made the observation that unlocks it: **Woo already holds the field definitions, so it can render them in React on the extension's behalf, with no work from the extension author.** It is in beta and being enabled screen by screen. Richards is candid that this is internally contested and that the user benefit is modest per screen — "it's a form with a bunch of checkboxes and text inputs." The value is aggregate consistency. He also reports the pushback directly: plugin authors saying "now my settings just looks like everybody else's settings. I used to have icons and things." Woo's position is that sameness is what users want, with escape hatches preserved for genuine customization. He adds a line worth noting for anyone tracking where WordPress design decisions actually get made: **"WooCommerce is generally kind of ahead of WordPress, and we're always trying to try out those decisions in WooCommerce and see."** The host agrees from the user side, naming the familiar problem that Gravity Forms, WooCommerce, and LearnDash all look like different products inside one admin. The demo turns to an **unreleased first-party block theme**, in finishing touches. Woo has never had a recommended block theme; Storefront is classic and roughly a decade old. The new theme is deliberately minimal — because the functionality lives in Woo's blocks, the theme "doesn't have to bring a bunch of setting screens." It ships the things a modern store expects: slide-in mini cart, logged-in user dropdown, live product filters that update without a page reload, product tabs, and add-to-cart that does not reload. Richards notes he personally uses Ollie for much of his own Woo work, which is a fair signal that the theme is a reference implementation rather than a mandate. His argument for it is really an argument about awareness: people keep building or installing things Woo already ships as blocks — product carousels, galleries, lightboxes — so "you don't need to add Elementor." The theme exists partly to demonstrate what is already available, then hand it to the site editor for customization. On **block cart and checkout** he is even-handed. They convert well, are streamlined and performant, and Woo can control how fast they render. But if you are "doing something really crazy," the extensibility may not be there, and the old shortcodes remain available — a compatibility commitment he states twice. He contrasts this with Shopify, where checkout is hosted separately and CSS customization requires roughly a $1,000-a-month plan, while Woo's checkout is blocks you can rearrange without a developer. Live, he stumbles into the template-versus-page confusion and says so: **"This is my least favorite thing about WordPress site editing... when am I editing a template? When am I editing a page?"** He notes experiments underway to clean it up. That is a useful admission from a developer advocate demoing his own product. The same block argument extends to the product catalog: filters can become chips instead of checkboxes, price or sale badges can be hidden, layout rearranged — all without a developer. The host contrasts this with the old approach of hooks and filters, where adding a message to the cart page could be a genuine hassle. **Responsive styles is the clearest concrete win.** WordPress 7.1 introduces responsive design controls, and because Woo builds on core blocks, all of them inherit it — "it's just going to come free in WooCommerce." Someone built an AI-driven automation that walked every Woo block (Richards estimates over 100) testing for responsive-style problems, finding roughly half a dozen spots needing fixes. This is a genuinely good use of AI: exhaustive mechanical coverage across a surface too large to check by hand. The host plugs The WP Minute's episode with Anne McCarthy, the 7.1 release lead, on using responsive styles. **The AI section splits into three cleanly distinguished strands**, and Richards's willingness to separate them is more useful than most AI roadmap talk. *First, connecting an existing assistant to your store.* This was already possible through WP-CLI or the REST API — "if you tell Claude to go do something to your site and it can get in the REST API, it's going to do it." The step forward is the WordPress MCP, which Woo already supports, with abilities that lean heavily toward reading — products, orders, information out of the site — and away from editing, because "we really don't feel like that's a safe enough thing to do yet for people cuz we really don't want to break sites." He calls MCP "training wheels AI connection." Notably, this was extended across Woo's extensions, so Subscriptions, Memberships, and others expose their own abilities. *Second, AI inside the dashboard.* This is where he is visibly constrained — "I don't know what I can say. I probably should have asked." What he confirms: it exists, chatting with an agent inside WooCommerce works, and the plan is to demo and begin beta testing at WordCamp US. The framing he gives is the substantive part: the focus is not CRUD ("go add some products") but **deep analysis over years of store data** — which customers are churning, which products are underperforming — with the agent spinning up dashboards and insights. *Third, agentic commerce* — customers buying from your store through an AI agent. Stripe and Google are leading protocol development; Woo has experimental support. Richards was at a Stripe agentic-commerce event with eBay, Walmart, and Amazon in the room. The worked example: tell an agent your kid's birthday party theme and have it source supplies across multiple stores, compile a list, and get approval to purchase. His caveat is refreshingly direct: **it is "a cool future idea, but it's not really happening in the world today,"** with a tiny percentage of actual conversions, and users not ready. Woo's posture is to have protocols in place and wait for them to stabilize. The open questions he lists are the right ones — returns, refunds, customer support attribution, merchant reputability, shipping, and tax. He hedges his own skepticism with a line many will recognize: "I've learned over the last year to not underestimate AI. Anytime I'm like, 'It won't do that,' it does it." A fourth AI thread emerges that is arguably more immediately relevant than the other three: **AI as a substitute for reaching for SaaS.** If you need a simple capability, an agent can build a dashboard screen against data your site already has — database, post types, everything. The blocker is trust on a live store. Richards describes the internal debate at Automattic around Studio, their local development tool with a built-in agent: should it pull your site locally, should it be allowed to edit your live site. He predicts the resolution is copy-experiment-deploy. On Playground, which he says he uses constantly, he identifies the specific limit for commerce: **Woo stores are massive, and you cannot meaningfully test on an empty store** — Woo's own demo store populates realistic order volume for exactly that reason. The last product item is an experimental **new product catalog view**: faster, with multi-select and inline bulk editing through a sidebar for status, stock, and price, plus strong search and filtering that resolves down to individual variations — find the green sweaters, then bulk-edit those variations. His framing is a nice corrective inside an AI-heavy conversation: "even though this is sort of the opposite of AI," there are times "you need to log into your store and you need to look at the actual data and you need to know that it's doing exactly what you want. I don't think that's going to go away." On **Woo Analytics** he is candid about it being "stuck in one foot in each room" — the older Woo Reports section alongside the newer Analytics. He expects stores above a certain size are not using it, preferring tools that offload the work, and notes Jetpack can move computation to separate servers. AI has helped optimize it by moving work into scheduled actions so figures update without slowing the site. The direction he points to is exporting structured data to an LLM rather than building more charts, since a model "can definitely crunch numbers a lot faster than me looking at charts and graphs that I don't have a lot of control over." Where to follow: developer.woo.com, a monthly newsletter he recommends as the minimum subscription, a community Slack he puts at around 40,000 members, plus Twitter, Bluesky, and YouTube. At WordCamp US, Richards presents on block themes and fellow developer advocate Shawnee on agentic commerce. Two things to hold lightly. Almost everything genuinely new here is beta, experimental, or unreleased — the block theme, settings conversion, shipment tracking, product catalog view, dashboard AI, and agentic commerce are all pre-release. And this is a sponsored member meetup with a vendor's developer advocate, which shapes the register: the failures discussed are historical and already being fixed, and there is no adversarial questioning. ### 🗒️ Notes #### ⏱️ [00:00:00](https://www.youtube.com/watch?v=OkIVNKJADVo?t=0) Setup and sponsors - The WP Minute member meetup, July 2026, "What's new with Woo." Matt Medeiros present; guest is **Brian Richards, developer advocate at WooCommerce**. - Pillar sponsors thanked: Pressable, Jet Host, WP Engine, Hosting.com, 20i, GridPane, Weglot. - Worth noting for context: this is member-supported, vendor-guest programming — informative, not adversarial. #### ⏱️ [00:00:59](https://www.youtube.com/watch?v=OkIVNKJADVo?t=59) The backlog cleanup, and why now - A blog post from a WooCommerce lead the transcript renders as "Bo," described as head artistic director, kicked this off. - **AI PRs are part of the pressure:** people "vibe code to PR and send it to you, which is rough. It's nice, but it's rough" — human review and triage cost the same regardless of how cheaply the submission was made. - Plus the ordinary backlog any large-install platform accumulates: "so many things reported, so many users." - The decision: "Let's just spend a few quarters just cleaning up the backlog of issues." #### ⏱️ [00:02:00](https://www.youtube.com/watch?v=OkIVNKJADVo?t=120) The target, and the principle behind it - **James Kemp**, product lead, is triaging and assigning through product and engineering teams. - Goal by end of summer/fall: GitHub backlog "extremely low" — **a couple hundred open issues, nothing older than roughly half a year**, versus five-to-seven-year-old issues currently present. - The norm worth quoting: if somebody "put in the effort to file a bug report on GitHub, it really is our responsibility to fix it" — or give a clear answer, including "that's expected behavior, not a priority." - Illustrative case: a button that did not work, filed five years earlier, added to a list, removed, orphaned when the engineer left. - Framing: "not fun exciting features" but "paper cuts that just people deal with every day" — the same language as the Gutenberg block-editor paper cuts effort. #### ⏱️ [00:03:35](https://www.youtube.com/watch?v=OkIVNKJADVo?t=215) The host's challenge — extensions become a tangled mess - Referencing his own newsletter op-ed: Woo can sell anything and support almost any feature "if you have a good developer who knows what they're doing." - The cost: stacking extensions and juggling payment providers "becomes a little bit of a tangled mess." - The question posed directly: can Woo become a more user-friendly all-in-one package? #### ⏱️ [00:04:35](https://www.youtube.com/watch?v=OkIVNKJADVo?t=275) Why there will never be a Woo bundle - Woo core "really is just the foundational layer." No Jetpack-style everything-plugin is coming. - **The reason is structural:** the things every store needs — payments, email, shipping, tax — are exactly the things that differ store to store. - First-class tier: payment providers (WooPayments works closely with Stripe), Google, TikTok, Reddit connections; marketing via Klaviyo, Mailchimp. - "After that, you know, it's a wild west." #### ⏱️ [00:06:05](https://www.youtube.com/watch?v=OkIVNKJADVo?t=365) The marketplace has less leverage than it looks - Unlike Shopify's controlled app store, **most extensions on Woo stores don't come from Woo's marketplace** — "we don't even get a percentage, we don't get anything, we have no control over it." - The marketplace is the quality lever available: listing requires "an insane amount of integration testing, unit testing, release testing." - Expected reality: **10 to 30 plugins on an average Woo store**, and he doubts that changes. - Some consolidation at the margins: add-ons folded into Subscriptions; plugins that cost roughly $70/month bundled into core free. - Heuristic: what about 80% of users actually need. Closing frame: "that's not even a WooCommerce problem, it's an e-commerce problem." #### ⏱️ [00:08:16](https://www.youtube.com/watch?v=OkIVNKJADVo?t=496) Shipment tracking as the template for core-vs-extension - Everyone needs tracking and the "your package is on its way" email regardless of carrier — so it belongs in core. - The pattern: build "the extensible API that anybody can hook into and anybody can do it and they can't break it," plus one UI. Providers do their own work on top. - Currently in beta. The host floats table rate shipping as another long-discussed core candidate. - General principle stated: general functionality in core, provider specifics in extensions, Woo as "the foundational layer." #### ⏱️ [00:09:04](https://www.youtube.com/watch?v=OkIVNKJADVo?t=544) Settings UI — the clever bit - Two worlds today: classic PHP settings screens, and React-based modern WordPress. - Woo extensions **already declare settings through a PHP class** as an array — checkbox to enable, text field for an API key — which Woo renders. - The WooPayments team's insight: Woo already holds those definitions, so **"couldn't we just turn them to JavaScript for you, and you don't have to do it yourself?"** - In beta, enabled screen by screen. Internally "a big topic of debate." #### ⏱️ [00:10:20](https://www.youtube.com/watch?v=OkIVNKJADVo?t=620) Consistency versus extension branding - He is honest that per-screen benefit is modest — "it's a form with a bunch of checkboxes and text inputs." - The pushback, reported directly: plugin authors saying "now my settings just looks like everybody else's settings. I used to have icons and things." - Woo's position: "I think that's what the user wants. I think they just want it all to look the same and consistent." Escape hatches preserved. - **The line worth marking:** "WooCommerce is generally kind of ahead of WordPress, and we're always trying to try out those decisions in WooCommerce and see." - Host's corroboration from the user side: Gravity Forms, WooCommerce, and LearnDash all look like different products inside one admin. #### ⏱️ [00:12:01](https://www.youtube.com/watch?v=OkIVNKJADVo?t=721) The unreleased first-party block theme - Demo store with fake apparel products built by Woo's design team; the theme is in finishing touches. - **Woo has never had a recommended block theme** — Storefront is classic and roughly a decade old. - The theme is deliberately minimal *because* the functionality lives in Woo's blocks: "it doesn't have to bring a bunch of setting screens." - Ships: slide-in mini cart, logged-in user dropdown, live filters without page reload, product tabs, non-reloading add-to-cart. - Notable: **he personally uses Ollie** for much of his own Woo work — the theme is a reference implementation, not a mandate. #### ⏱️ [00:13:57](https://www.youtube.com/watch?v=OkIVNKJADVo?t=837) Block cart and checkout, assessed fairly - Convert well, streamlined, performant — Woo can control render speed. - Honest limit: if you are "doing something really crazy," extensibility may not be there. - **Compatibility commitment stated twice:** "in WooCommerce you can always use the old shortcodes, you can always use the old approach for anything." - Contrast with Shopify: checkout hosted separately, CSS customization roughly a $1,000/month plan. Woo's is blocks you can rearrange without a developer. - His frustration with awareness: people build or install what Woo already ships as blocks — carousels, galleries, lightboxes — "you don't need to add Elementor." #### ⏱️ [00:16:12](https://www.youtube.com/watch?v=OkIVNKJADVo?t=972) A developer advocate hits the template/page trap live - He fumbles editing the checkout, then names it: **"This is my least favorite thing about uh WordPress site editing... when am I editing a template? When am I editing a page?"** - Notes there are "some really good experiments to clean this up." - Once inside, list view shows everything is blocks — full access, though "some of it's a little locked down," which is why some stores stay on the old checkout. #### ⏱️ [00:17:53](https://www.youtube.com/watch?v=OkIVNKJADVo?t=1073) The catalog is blocks too - Shop page and filters fully rearrangeable: checkboxes → chips, hide price, hide sale badge, change colors and layout. - "I don't need to get a developer to do this stuff" — he calls this "a hidden value of the block themes." - Host's contrast: the old approach meant hooks and filters, where even adding a message to the cart page could be a hassle. - Host's addition: pair with something like block visibility for mobile-only or logged-in-only content. #### ⏱️ [00:19:15](https://www.youtube.com/watch?v=OkIVNKJADVo?t=1155) Responsive styles arrive free — verified by AI sweep - WordPress 7.1 introduces responsive design controls; **because Woo builds on core blocks, all of them inherit it.** - Someone built an AI automation that walked **every Woo block (he estimates over 100)** testing for responsive-style problems — found roughly half a dozen spots needing fixes. - A genuinely good AI application: exhaustive mechanical coverage across a surface too large to hand-check. - The strategic point: "as long as we keep building on core, if core does something special like responsive design... it's just going to come free in WooCommerce." - Host plugs The WP Minute's episode with **Anne McCarthy**, 7.1 release lead, on using responsive styles. #### ⏱️ [00:20:45](https://www.youtube.com/watch?v=OkIVNKJADVo?t=1245) AI strand one — MCP as "training wheels" - Already possible via WP-CLI or REST API: "if you tell Claude to go do something to your site and it can get in the REST API, it's going to do it. It doesn't care." - **Woo already supports the WordPress MCP**, with abilities weighted toward reading — products, orders, site information. - Editing is deliberately limited: "we really don't feel like that's a safe enough thing to do yet for people cuz we really don't want to break sites." - **Extended across extensions** — Subscriptions, Memberships (SkyVerge) and others expose their own abilities. - His characterization: "MCP I always think of it as like training wheels AI connection." #### ⏱️ [00:22:28](https://www.youtube.com/watch?v=OkIVNKJADVo?t=1348) AI strand two — dashboard agent, partly embargoed - He is visibly constrained: "I don't know what I can say. I probably should have asked." - Confirmed: it exists, agent chat inside WooCommerce works, and the plan is **demo plus beta testing at WordCamp US**. - **The substantive framing:** not CRUD ("go add some products") but deep analysis over years of store data — which customers are churning, which products are underperforming. - Goal is the agent spinning up dashboards and "deeper insights to managing my store." #### ⏱️ [00:23:21](https://www.youtube.com/watch?v=OkIVNKJADVo?t=1401) AI strand three — agentic commerce, honestly hedged - Customers buying from your store through an agent. **Stripe and Google leading the protocols**; Woo has experimental support. - He attended a Stripe agentic-commerce event with eBay, Walmart, and Amazon present. - **The caveat that makes this credible:** "that's a cool future idea, but it's not really happening in the world today" — a tiny percentage of actual conversions, users not ready. - Woo's posture: protocols in place, waiting for them to stabilize, in ongoing conversation with Stripe and Google "because stores are complicated." #### ⏱️ [00:25:21](https://www.youtube.com/watch?v=OkIVNKJADVo?t=1521) The unsolved questions in agentic commerce - Worked example: give an agent your kid's birthday party theme, it sources supplies across stores, compiles a list, seeks approval to purchase. - The immediate open questions he lists: returns, who issues refunds, who handles customer support, how you know the merchant is reputable, shipping, tax. - His hedge on his own skepticism: **"I've learned over the last year to not underestimate AI. Anytime I'm like, 'It won't do that,' it does it."** - Host's version of the same question: does the agent already hold my payment details, or do I re-enter them per store? #### ⏱️ [00:26:55](https://www.youtube.com/watch?v=OkIVNKJADVo?t=1615) The fourth strand — AI as SaaS replacement - The pattern he expects to grow: instead of buying a SaaS for a simple capability, have an agent "build a new screen on my dashboard that does that cuz it already has access to everything." - Why it works: "all the building blocks are already there" — database, post types, existing data. - **The blocker is trust on a live store.** Internal debate at Automattic around Studio: should it pull your site locally, should it edit your live site. - His predicted resolution: copy the site, experiment and iterate, deploy back — "you're not paying some SaaS provider. It's definitely going to change the dynamics." #### ⏱️ [00:28:40](https://www.youtube.com/watch?v=OkIVNKJADVo?t=1720) Why Playground struggles with commerce specifically - He uses Playground "constantly," but names the limit precisely: **Woo stores are massive, and you cannot meaningfully test on an empty store.** - Woo's own demo store populates realistic order volume on spin-up because "we need that information to really test things." - He has been trying to find a way to make that demo store publicly usable, but its value comes from its size. - Hence his enthusiasm for Studio as a local dev tool that is "getting really good with WooCommerce" and with built-in agentic features. #### ⏱️ [00:29:57](https://www.youtube.com/watch?v=OkIVNKJADVo?t=1797) Experimental product catalog view - Modern React treatment for the product catalog — faster, with acknowledged rough edges. - Multi-select with **inline bulk edit via sidebar**: status, stock, price. - Strong search and filtering that resolves to **individual variations** — find the green sweaters, bulk-edit those variations. - The corrective inside an AI-heavy talk: "even though this is sort of the opposite of AI," sometimes "you need to log into your store and you need to look at the actual data and you need to know that it's doing exactly what you want. I don't think that's going to go away." #### ⏱️ [00:31:44](https://www.youtube.com/watch?v=OkIVNKJADVo?t=1904) Woo Analytics — one foot in each room - Two overlapping surfaces: the older Woo Reports section and the newer Woo Analytics. - He expects stores above a certain size aren't using it, preferring tools that offload the work; Jetpack can move computation to separate servers. - AI has helped optimize it — moving work into scheduled actions so numbers update dynamically "but not also slow your site down." - A cloud extension experiment is on the dev blog and "informed where the final product is going to go." - The direction: export structured data to an LLM rather than build more charts, since a model "can definitely crunch numbers a lot faster than me looking at charts and graphs that I don't have a lot of control over." #### ⏱️ [00:33:33](https://www.youtube.com/watch?v=OkIVNKJADVo?t=2013) Where to follow the work - **developer.woo.com** is the hub — dev blog, documentation, links to everything. - A **monthly newsletter** he recommends as the minimum subscription: "just the high level stuff that's most important." - A community Slack he puts at roughly **40,000 members**; also Twitter, Bluesky, and some YouTube. - WordCamp US: Richards presenting on block themes, fellow advocate **Shawnee** on agentic commerce, plus a Woo booth. ## 📚 References - [developer.woo.com](https://developer.woo.com/) — dev blog, newsletter, docs, community Slack - [WooCommerce GitHub issues](https://github.com/woocommerce/woocommerce/issues) — where the backlog cleanup is observable - [WooCommerce blocks documentation](https://developer.woo.com/docs/) — the block surface the new theme depends on - [WordPress MCP](https://github.com/Automattic/wordpress-mcp) — the abilities layer Woo extended across its extensions - [Studio by WordPress.com](https://developer.wordpress.com/studio/) — local dev tool with built-in agent - [WordPress Playground](https://wordpress.github.io/wordpress-playground/) — useful, but limited for large stores - [Ollie](https://olliewp.com/) — block theme the guest uses personally for Woo builds - [Storefront](https://wordpress.org/themes/storefront/) — the classic theme the new block theme succeeds - [The WP Minute — Anne McCarthy on 7.1 responsive styles](https://thewpminute.com/) — the companion episode plugged in this meetup ## 🗣️ Paraphrase - **Opening.** A member meetup on WooCommerce updates, with a vendor developer advocate as guest and sponsors acknowledged up front. - **Backlog.** The project is deliberately spending several quarters clearing years-old GitHub issues, pressured partly by a rising volume of AI-generated pull requests that still require full human review. - **Target and norm.** A few hundred open issues, none older than about six months, with a commitment that every filed report earns a resolution or an explicit answer. - **The bundle question.** Woo will not become an all-in-one, because the components stores most need are the ones that vary most between stores. - **Tiering.** A small set of first-party or partnered extensions covers payments, ad channels, and marketing; everything else is uncontrolled, and most installed extensions never touch the official marketplace. - **Consolidation.** Some paid add-ons have been folded into core or into larger extensions, guided by what most users need. - **Core pattern.** Where a need is universal, Woo builds one extensible API and one interface, leaving provider specifics to extensions — shipment tracking is the current example. - **Settings.** Because extensions already declare their settings declaratively in PHP, Woo can render those declarations in a modern interface without extension authors doing anything. - **Consistency debate.** Some plugin authors dislike losing their distinct look; the platform's position is that users prefer uniformity, with escape hatches retained. - **Block theme.** A first-party block theme is nearly ready, thin by design because functionality lives in blocks, and intended partly to show what is already available without extra plugins. - **Checkout.** The block checkout performs well but is less extensible for unusual cases; legacy shortcodes remain permanently supported. - **Site editing.** The template-versus-page distinction is confusing even to the presenter, with cleanup experiments underway. - **Responsive styles.** Core's new responsive controls arrive across all Woo blocks automatically; an AI sweep across every block found only a handful of problems. - **AI, three strands.** Connecting external assistants through a read-leaning abilities layer; an unreleased in-dashboard analytical agent; and experimental protocol support for purchases made by agents. - **Honest limits.** Editing capabilities are deliberately restricted for safety, and agent-driven purchasing is acknowledged as not yet real in practice. - **Fourth strand.** Agents building bespoke dashboard functionality against existing site data may displace small SaaS purchases, pending trust and environment questions. - **Testing.** Browser-based sandboxes struggle with commerce because realistic testing needs large data volumes; local tooling with seeded data is preferred. - **Catalog.** An experimental catalog view adds inline bulk editing and variation-level search, presented as deliberately non-AI tooling that remains necessary. - **Analytics.** Two overlapping reporting surfaces exist; larger stores offload, and the stated direction is structured export to a model rather than more built-in charts. ## 📰 Newsletter **Woo is spending a few quarters just closing old bugs — and that might be the most interesting thing in this meetup** Brian Richards (developer advocate, WooCommerce) joined The WP Minute's July member meetup, and while there's plenty of AI talk, the item with the clearest near-term payoff is the least exciting one. **They're clearing the backlog.** James Kemp is triaging, and the target is a couple hundred open GitHub issues with **nothing older than about six months** — against five-to-seven-year-old tickets sitting in there now. Richards described closing one about a broken button, filed five years ago, that got added to a list, removed, and orphaned when the engineer left. The principle he stated is the part worth quoting at people: if someone put in the effort to file a bug report, the project owes them a fix *or a clear answer* — "that's expected behavior, not a priority" counts. Two things make this land. First, he names AI PRs as part of the pressure — "people vibe code to PR and send it to you, which is rough. It's nice, but it's rough" — because review cost doesn't drop just because production cost did. Sound familiar? That's the same squeeze the Gutenberg folks flagged in Changelog #134, and Woo is using the same word for the work: **paper cuts.** **The core-vs-extension answer is a firm no.** There will be no Jetpack-style Woo bundle, and his reasoning is good: the things every store needs — payments, email, shipping, tax — are exactly the things that differ store to store. What surprised me was the honesty about leverage: **most extensions on Woo stores never touch Woo's marketplace.** No revenue share, no review, no control. Expect 10–30 plugins on an average store, and don't expect that to change. Where a need really is universal, the pattern is shipment tracking (in beta now): one extensible API, one UI, providers hook in. **The cleverest engineering item:** Woo extensions already declare their settings as a PHP array. So the WooPayments team asked — since Woo already *has* the field definitions, why not render them in React on the extension's behalf? Zero work for extension authors. It's in beta, rolling out screen by screen. Some plugin authors have already objected that their settings now "look like everybody else's." Woo's answer is that this is what users actually want. I'm inclined to agree, and if you've ever bounced between Gravity Forms, Woo, and LearnDash in one admin session you know why. **File this line away:** *"WooCommerce is generally kind of ahead of WordPress, and we're always trying to try out those decisions in WooCommerce and see."* That's a fairly direct statement about where WordPress design decisions actually get proven. **For theme people:** a first-party Woo **block theme** is in finishing touches — the first recommended one ever, succeeding decade-old Storefront. It's deliberately thin because the functionality lives in the blocks. Mini cart, live filters without reload, AJAX add-to-cart, all core. His argument is really about awareness: people keep installing plugins for carousels, galleries, and lightboxes that Woo already ships. Nice grace note — he says he personally uses **Ollie** for a lot of his own Woo builds, so this reads as a reference implementation rather than a mandate. **The 7.1 tie-in is the concrete win.** Responsive styles land in WordPress 7.1, and because Woo builds on core blocks, **all 100+ of them inherit it for free.** Someone built an AI sweep across every single Woo block to check for responsive-style breakage and found about half a dozen spots to fix. That's the right use of AI — exhaustive mechanical coverage across a surface nobody could hand-check. **On AI generally,** he separates three strands cleanly, which is more than most roadmap talks manage. MCP is live and deliberately **read-heavy** — editing is restricted because "we really don't want to break sites," and he calls MCP "training wheels AI connection." An in-dashboard analytical agent exists but is embargoed until WordCamp US (he said outright he "probably should have asked" what he could share). And agentic commerce gets the most honest framing I've heard on it: *"that's a cool future idea, but it's not really happening in the world today."* Tiny conversion numbers, users not ready, protocols still moving. **One admission I appreciated:** demoing live, he hit the site editor's template-versus-page confusion and said "this is my least favorite thing about WordPress site editing." When the developer advocate trips on it in his own demo, that's a UX finding. **Also worth knowing:** an experimental product catalog view with inline bulk editing and variation-level search — find your green sweaters, bulk-edit the variations. He framed it as "sort of the opposite of AI," and defended it: sometimes you need to log in and look at the real data. Everything genuinely new here is beta or unreleased. Follow at **developer.woo.com** — the monthly newsletter is the low-effort option. ## ✅ Action Items #### DevRel - Developer advocacy: the settings auto-conversion is the most teachable item — a platform absorbing migration cost on behalf of its extension authors. Build the talk around that pattern, not around the UI. - Education: write the "what actually ships in Woo blocks" guide. His frustration that people install plugins for carousels and lightboxes Woo already provides is a documentation and awareness failure, not a product gap. - Developer experience: publish the settings-migration story clearly — what authors must do, what happens automatically, and how the escape hatches work. Silence here will read as a forced migration. - Developer marketing: "responsive styles arrive free across 100+ blocks" is the cleanest value story from 7.1 for commerce builders. - Community management: the backlog-response norm — every filed report earns a resolution or an explicit answer — is worth adopting and publishing verbatim in other projects. - Internal/external/cross-project: coordinate with core on the template-versus-page cleanup; a developer advocate stumbling live is strong qualitative evidence to attach to that effort. #### OSPO - Policy & Governance: write an explicit policy on AI-generated pull requests. Review capacity, not submission volume, is now the constraint, and Woo is naming it openly. - License Compliance: not applicable to this source. - Security Management: Woo's decision to keep MCP abilities read-heavy is a defensible default worth copying — expose reads freely, gate writes behind explicit review. - Software Inventory: the 10–30 plugins per store figure is an inventory reality worth planning around rather than wishing away. - Developer Support: prepare guidance for extension authors facing the settings change, especially those who invested in custom settings UI. - Community Engagement: the ~40,000-member Woo Slack is a large, underused channel for ecosystem coordination beyond product support. - Strategic Alignment: track the backlog metric publicly — open issues and oldest-issue age are two honest numbers that other WordPress projects could adopt. #### Community - Maintainers: adopt the "every filed bug earns a response" norm explicitly, including the permission to close as expected-behavior. Silence is the failure mode, not rejection. - Contributors: the backlog cleanup is a genuine contribution window — old issues are being actively triaged, so reproductions and confirmations land better now than usual. - Sponsors: fund the unglamorous work. Several quarters of bug-closing is exactly what sponsorship should make possible and exactly what rarely gets funded. - Ecosystem: the read-only-by-default posture for agent abilities deserves to become a cross-project convention before someone ships write-by-default and sets the norm badly. #### WordPress - Core: the template-versus-page confusion is confirmed here by a developer advocate demoing his own product. Attach that to the existing site-editing cleanup work as evidence. - Core Performance: block cart and checkout are claimed to convert and perform better because render speed is controllable — worth independent measurement rather than acceptance. - Core AI: Woo's three-strand split (external assistant via MCP / in-dashboard analytical agent / agentic commerce) is a better taxonomy than core currently uses. Borrow it. - **Core Program Team:** Woo is explicitly the proving ground for decisions core later adopts. That relationship should be documented and deliberate rather than informal. - Mobile: responsive styles landing across all Woo blocks makes mobile commerce testing a priority for 7.1 — worth a coordinated pass. - Playground: the commerce limitation is now clearly articulated — realistic testing needs seeded data at volume. A seeded-store blueprint would unlock a real use case. - Community: a meetup format around "what Woo already ships as blocks" would directly address the awareness gap Richards describes. - Training: build a lesson on the block catalog and filters — chips versus checkboxes, hiding price and sale badges — since the whole point is that it needs no developer. - Marketing: the free-inheritance story (core feature → every Woo block) is a strong argument for building on core rather than around it. - Support: expect tickets from the settings UI transition and from stores mixing block and shortcode checkout. Prepare guidance for both. - Design: the settings unification is a design-system win worth documenting as a case study — including the escape hatches, which are what make it acceptable. - Documentation: document the shipment tracking API pattern as a reference architecture for "universal need, varied providers." It generalizes well beyond shipping. - Photos: not applicable to this source. - TV: this meetup's auto-captions mangle nearly every name and product term — worth a captions-quality pass for member content that gets referenced later. - Polyglots: e-commerce has locale-specific tax, shipping, and payment requirements; the "80% of users need it" heuristic risks encoding US-centric defaults into core. - Accessibility: live filters that update without page reload need proper focus management and live-region announcements — worth auditing in the new block theme before release. - Meta: not applicable to this source. - CLI: he notes agents already act through WP-CLI and REST; WP-CLI's role as an agent surface deserves explicit design attention rather than incidental use. - Hosting: agentic dashboards and analytics running in-store have real resource implications — the scheduled-actions optimization is a hosting-relevant detail. - Tide: the marketplace's testing requirements (integration, unit, release) are conceptually adjacent to Tide; worth comparing approaches. - Openverse: not applicable to this source. - Themes: **highest-relevance team.** A first-party Woo block theme sets an implicit standard for commerce themes. Theme authors should see it early enough to react. - Plugins: the fact that most Woo extensions never pass through Woo's marketplace is the same distribution gap the WP Rocket incident exposed — commercial plugin distribution remains unsolved at the project level. #### The WPOCC - Programs: a workshop on building Woo stores with core blocks only — no page builder, no extra plugins — would directly serve the awareness gap and produce reusable material. - Projects: document the "universal need, varied providers" API pattern as a governance-and-architecture reference; it recurs across the ecosystem. - Funding experiments: fund backlog-clearing sprints for smaller projects, modeled on what Woo is doing with dedicated staffing. ### FAIR - Technical independence: agents building bespoke functionality against a site's own database and post types is a genuinely independence-friendly pattern — it replaces SaaS dependency with local capability. - Policies and covenants: agentic commerce protocols led by Stripe and Google will encode commercial defaults; independent platforms should have a position before those protocols stabilize, not after. - Productized governance artifacts: a published backlog-response commitment (respond or resolve, with a stated age ceiling) is a small reusable governance artifact worth templating. ### 🧪 Hypotheses 1. **Dedicated backlog-clearing reduces recurrence, not just count.** Issues closed during a focused cleanup will show a lower re-open and duplicate-refile rate than issues closed incidentally during feature work. 2. **AI-generated PRs increase reviewer load per merged change.** Since AI submissions became common, median reviewer time per merged PR will have risen even where merge rates held steady. 3. **Platform-rendered settings raise adoption of modern UI faster than developer migration.** Extensions whose settings are auto-converted will reach modern-UI parity at a far higher rate than extensions relying on authors to port their own screens. 4. **Block checkout converts better than shortcode checkout, controlling for store size.** Richards asserts this; it is measurable across matched stores and, to my knowledge, unpublished. 5. **Seeded-data sandboxes change commerce testing behavior.** If Playground offered a realistically-populated store blueprint, testing participation on commerce issues would rise measurably versus empty-store sandboxes. 6. **Agentic commerce conversion remains negligible through the next year.** Given protocol instability and unresolved returns/support attribution, agent-originated purchases will stay a very small share of Woo GMV — his own stated position, and worth tracking as a falsifiable prediction. ### 📊 Methodology - **H1:** Repository analysis on WooCommerce GitHub — compare re-open and duplicate rates for issues closed during the cleanup window against a matched pre-cleanup baseline. Data is public and the natural experiment is already running. - **H2:** Repository analysis across several large WordPress-ecosystem projects: PRs opened per month, distinct reviewers, median time-to-first-review and time-to-merge, segmented by whether a PR shows AI-generation markers. The segmentation is the hard part. - **H3:** Track the proportion of marketplace extensions rendering modern settings screens before and after auto-conversion ships, against a control group of extensions outside the auto-conversion path. - **H4:** Matched-pair analysis across stores that migrated checkout, controlling for traffic, catalog size, and extension count. Requires either Woo telemetry or a cooperating host with a large store population — the obvious confound is that stores willing to migrate differ systematically from those that aren't. - **H5:** A/B the availability of a seeded store blueprint and measure testing participation on commerce-tagged issues. Cheap to run once the blueprint exists. - **H6:** Longitudinal tracking of agent-originated transactions as a share of total, using whatever attribution the protocols expose. The measurement problem is itself part of the finding — if attribution is unavailable, that is worth reporting. ### ❓ Questions - What happens to the backlog norm after the cleanup ends — is "respond or resolve within six months" a permanent commitment with staffing behind it, or a one-time push? - If most extensions never pass through Woo's marketplace, what actual quality leverage does the marketplace have on the typical store's real risk surface? - For extension authors who invested in custom settings UI, what is the migration path, and is opting out sustainable long-term or a temporary courtesy? - Does the block checkout's conversion advantage hold for complex stores, or only for the simpler ones most likely to have adopted it? - Who is accountable when an agent-originated purchase goes wrong — the store, the agent provider, or the protocol operator? None of the parties named appear to have answered this. - How does the "80% of users need it" heuristic for core inclusion avoid encoding US-centric tax, shipping, and payment assumptions? - If Woo is where WordPress design decisions get proven, what is the feedback path back to core, and who decides what graduates? - Does the read-heavy MCP posture hold as competitive pressure builds, or does write access arrive before the safety questions are answered? ### 🔮 Future Research - **Backlog cleanup as an intervention.** Woo is running a well-defined natural experiment with public data. Whether focused cleanup improves contributor retention and reduces recurrence is answerable and would inform every large project. - **Review capacity under AI submission volume.** Repeatedly named as a pressure across projects, never measured. The data exists in public repositories. - **Platform-absorbed migration cost.** The settings auto-conversion is a rare case of a platform doing its ecosystem's migration work. Whether this generalizes — and what it requires structurally, namely declarative configuration — deserves study. - **Commerce testing environments.** The empty-store problem is specific, well-articulated, and blocks a real class of contribution. Seeded-data sandboxes are the obvious intervention and nobody has evaluated them. - **Agentic commerce trust mechanics.** Returns, refunds, support attribution, and merchant reputation are all unsolved and are being designed now by a small number of commercial actors. - **Accessibility of live-updating commerce UI.** Filters that update without page reload are becoming standard in block themes; their screen-reader behavior is not covered in the source and appears under-examined generally. ### 💡 Implications - **Practice.** Two things to act on now: audit what you are installing plugins for against what Woo already ships as blocks, and if you build extensions, find out where you sit relative to the settings auto-conversion before it reaches your screens. - **Policy.** AI-generated contributions need a stated project policy. Woo is describing the pressure candidly without publishing a rule, and that gap will close one way or another. - **Security.** Read-by-default, write-by-exception for agent abilities is a good default that deserves to become convention before a less careful implementation sets the precedent. - **Education.** The single biggest gap this meetup reveals is awareness, not capability — people build and buy what already exists. That is a documentation and teaching problem with a clear owner. - **Funding.** Several quarters of clearing five-year-old bugs is exactly the work that never attracts funding and always creates value. It is happening here because a company staffed it; smaller projects have no equivalent path. ### 🧠 Learning Styles Assessment - **Reading level estimate:** Flesch-Kincaid Grade Level ≈ 8; Flesch Reading Ease ≈ 65. Conversational and accessible, but comprehension depends on prior familiarity with blocks, the site editor, extensions, MCP, and WooCommerce's product surface. The vocabulary is easy; the assumed context is not. #### 👀 Visual learners - Present: strong — live screen sharing of a real demo store, the block theme front end, site editor list view, and the experimental product catalog. You see the features rather than hear about them. - Improve: no architecture diagram of the block-theme-versus-core-blocks relationship, which is the conceptual claim underneath the whole demo. One diagram would carry it better than five minutes of navigation. #### 🔊 Aural learners - Present: natural conversational format with a host asking the questions a practitioner would actually ask. - Improve: the AI section jumps between three strands and a fourth emerges implicitly; verbally numbering them as they arrive would help listeners track the taxonomy that is genuinely the section's value. #### 🗣️ Verbal learners - Present: good analogies and plain framing — "training wheels AI connection," "wrangling ants," "one foot in each room," "wild west." - Improve: MCP, abilities, scheduled actions, and agentic commerce all arrive undefined. A one-line gloss each would open this to the store owners who are much of the audience. #### 🧩 Kinesthetic learners - Present: everything is demonstrated live in a working store, including a fumble that shows the real interface rather than a rehearsed path. - Improve: most of what is shown is beta, experimental, or unreleased, so viewers cannot follow along. Naming which experiments can be enabled today, and where, would convert watching into doing. #### 🧠 Logical learners - Present: the core-versus-extension reasoning is genuinely well-built — the claim that universal needs are also the most variable needs is a real argument, and shipment tracking is offered as a worked instance. - Improve: several performance and conversion claims (block checkout converts better, is more performant) are asserted without figures in a conversation that elsewhere gives concrete numbers. #### 🧑‍🤝‍🧑 Social learners - Present: a member meetup by construction, with a ~40,000-member Slack, WordCamp US sessions, and a booth all signposted. - Improve: no mechanism surfaced for extension authors to feed back on the settings change specifically, which is the item most likely to generate strong opinions. #### 🧘‍♀️ Solitary learners - Present: developer.woo.com and a monthly newsletter give a clear low-effort self-directed path. - Improve: no written summary of what is beta versus experimental versus shipped — the single most useful artifact for someone reviewing this alone later. #### 🌿 Naturalistic learners - Present: only obliquely — the analytics optimization moving work into scheduled actions is a resource-efficiency story. - Improve: agentic commerce and in-store AI analysis both have compute footprints that go unmentioned. **Otherwise not applicable to this source.** ### 📊 Accessibility Assessment #### Screen reader semantics - Present: Richards narrates most of what he demonstrates, so much of the content survives without sight. - Improve: significant stretches are "you can see here" while navigating menus; naming screens and controls aloud would close the gap. Maps to **WCAG 2.2 AA 1.2.5 Audio Description (Prerecorded)**. #### Keyboard navigation - Present: not applicable to the video artifact. - Improve: **the product concern is real, though.** Live filters that update without page reload, the slide-in mini cart, and AJAX add-to-cart all need focus management and predictable keyboard behavior. Maps to **WCAG 2.2 A 2.1.1 Keyboard** and **2.4.3 Focus Order** — and none of it is discussed in the source. #### Contrast and readability - Present: standard WordPress admin and a light storefront theme in the demo. - Improve: admin screens are shown at default zoom and will be unreadable on a phone; increase font size during demos. Maps to **WCAG 2.2 AA 1.4.4 Resize Text**. #### Text resizing and reflow - Present: not applicable to fixed-frame video. - Improve: the responsive styles discussion is directly relevant to **1.4.10 Reflow** for the resulting stores — worth explicit testing guidance as those controls ship. #### Media and captions - Present: auto-generated captions exist. - Improve: the auto-captions mangle names and terms throughout — "WorkCamp US" for WordCamp US, "Klaviyo" and "SkyVerge" rendered inconsistently, "agent to commerce" for agentic commerce, "Metric" for what is likely a named analytics product, "Bo" for a WooCommerce lead's name. For member content that gets cited later, human-corrected captions matter. Maps to **WCAG 2.2 AA 1.2.2 Captions (Prerecorded)**. #### Forms and interactions - Present: not applicable to the video artifact directly. - Improve: the block checkout is a form, and the meetup discusses its customization at length without once mentioning accessible labels, error handling, or target size. For a checkout, that is the omission that matters most. Maps to **WCAG 2.2 AA 3.3.1 Error Identification**, **3.3.2 Labels or Instructions**, and **2.5.8 Target Size (Minimum)**. #### Standards reference - Artifact gap: **1.2.2 Captions**. Product gaps implied but unexamined: **2.1.1 / 2.4.3** for live-updating filters and mini cart, and **3.3.x / 2.5.8** for block checkout. The most actionable recommendation from this source is an accessibility audit of the unreleased block theme *before* it ships, since it will become the reference implementation others copy. ### 🌍 DEIB Assessment #### Cultural breadth - Present: the ad-channel examples span Google, TikTok, and Reddit, and the extension discussion acknowledges that tax and shipping vary. - Improve: the framing is otherwise US-centric — Stripe, WordCamp US, US retail examples. The "80% of users need it" heuristic for core inclusion is where this becomes structural: whose 80%? Tax, shipping, and payment norms differ enough that a majority-driven core risks encoding one market's defaults. #### Inclusive language - Present: neutral throughout; collaborators and colleagues named and credited — James Kemp, Anne McCarthy, Shawnee. - Improve: unglossed jargon is the practical barrier. This is a *member meetup*, so the audience includes store owners, not only developers, and MCP, abilities, and scheduled actions all pass without definition. #### Neurodiversity support - Present: predictable topic-by-topic progression, and the host summarizes and redirects at intervals. - Improve: 35 minutes without chapter markers, plus live navigation fumbles and screen-hunting, is demanding to follow. Chapters and an on-screen topic indicator are cheap fixes. #### Representation - Present: one vendor advocate, one host, one publisher present. Shawnee is credited for the agentic commerce work and session. - Improve: no store owners, no extension developers, and no critics of the settings change appear — and the settings unification is precisely where an affected third party would have added something the vendor cannot. A member meetup is well positioned to include those voices. #### Psychological safety - Present: genuinely good. He admits the site editor confuses him, says outright he does not know what he is permitted to disclose, concedes block checkout has extensibility limits, reports plugin authors' objections in their own words rather than paraphrasing them away, and states plainly that agentic commerce "is not really happening in the world today." A developer advocate volunteering that much friction is not typical. - Improve: the embargo produces a few stretches of "there's very cool stuff I can't show," which is honest but leaves listeners unable to evaluate the most consequential claim in the meetup. ### ✅ Logical Validity #### Strong reasoning - **Causal, [00:04:35].** The argument against an all-in-one bundle is well-formed: the components every store needs are the components that vary most, therefore bundling cannot work, therefore core stays foundational. The premise is empirically plausible and the conclusion follows. - **Worked instance, [00:08:16].** Shipment tracking is offered as the resolution pattern rather than as a mere example — universal need justifies core, provider variance justifies an extensible API plus one UI. Naming the general rule and instantiating it is good technical argument. - **Inference from existing structure, [00:09:04].** The settings insight is genuinely elegant: because settings are already declared declaratively, the platform can change the renderer without changing the declarations. The conclusion is entailed by the architecture rather than asserted. - **Systems reasoning, [00:19:15].** "As long as we keep building on core, if core does something special... it's just going to come free" correctly identifies inheritance as the payoff of building on shared primitives — and it is backed by an actual verification sweep across every block rather than left as a claim. - **Empirical humility, [00:23:21].** On agentic commerce he distinguishes what is built (protocol support) from what is happening (almost nothing), and resists the incentive to conflate them. He then explicitly hedges his own skepticism about AI's trajectory. Both moves are correct and rare in vendor communication. - **Boundary reasoning, [00:29:57].** Arguing that better manual tooling remains necessary *inside* an AI-heavy conversation shows he is reasoning about where each tool applies rather than pattern-matching to the current enthusiasm. #### Fallacies - **Unsupported comparative claim** — [00:14:20] and [00:17:32]. Block cart and checkout "convert really well," are "really performant," and "definitely performs better in terms of conversion rate." *Weakness:* no figures, no baseline, no controls, from the vendor whose product it is — in a conversation that elsewhere supplies concrete numbers like the 10–30 plugin range. Conversion rate is exactly the claim a merchant would act on. *Fix:* publish the comparison methodology and numbers, or scope it to "in our testing, on stores of this shape." - **Deflection by generalization** — [00:07:15]. "That's not even a WooCommerce problem, it's like an e-commerce problem." *Weakness:* true, and it does not discharge the responsibility. Shopify addresses the same problem differently through a controlled app store, which he himself notes — so the problem being industry-wide does not make Woo's particular handling inevitable. *Fix:* keep the observation, then state what Woo specifically will and will not do about it, which he partly does elsewhere. - **Appeal to assumed user preference** — [00:10:57]. On plugin authors losing their distinct settings look: "I think that's what the user wants. I think they just want it all to look the same." *Weakness:* asserted twice as belief, with no research cited, to override a stakeholder objection reported verbatim. The position is probably right, which makes the absence of evidence more conspicuous, not less. *Fix:* cite usability research or run it — this is a testable claim about a contested change. - **Hasty generalization** — [00:06:36]. "People are going to probably average like 10 to 30 plugins on their Woo store." *Weakness:* a specific numeric range offered without a source, then used to support the conclusion that consolidation will not happen. *Fix:* cite the telemetry, which Woo plausibly has. - **Argument from personal incredulity, inverted** — [00:26:00]. "I've learned over the last year to not underestimate AI. Anytime I'm like, 'It won't do that,' it does it." *Weakness:* generalizes from a few surprises to a rule that any specific skepticism will be overturned, which is unfalsifiable and makes the well-grounded caveats immediately preceding it harder to hold. *Fix:* keep the specific claim — protocols are immature, conversions are negligible — and let it stand without the general disclaimer. - **Appeal to authority / self-report** — [00:06:26]. Marketplace listing requires "an insane amount of like integration testing, unit testing, release testing," offered as the quality guarantee. *Weakness:* the vendor describing its own review rigor, immediately after conceding most installed extensions bypass it entirely — so even if true, it bears on a minority of real-world risk. *Fix:* publish the review criteria, and state what share of installs the marketplace actually covers. #### Tone of voice - Candid and unpolished — live fumbles left in, uncertainty about disclosure permissions stated aloud, his own product's rough edges named without prompting. - Practitioner-to-practitioner rather than promotional; he assumes the audience runs stores and wants to know what will break. - Notably even-handed on tradeoffs: block checkout praised and limited in the same breath, agentic commerce presented and deflated in the same answer. - Enthusiastic where he is genuinely enthusiastic — the block theme, the catalog view — and visibly constrained where he is under embargo, without pretending otherwise. - Deferential to the ecosystem: he names Ollie as what he personally uses, credits colleagues by name, and reports critics' objections in their own words. ### 🛡️ DARVO Analysis - **Deny:** Not present. No accusation is under discussion. The pattern runs the other way — he volunteers limitations (block checkout extensibility, Analytics being "one foot in each room," Playground's unsuitability for large stores) rather than minimizing them. - **Attack:** Not present. Competitors are described neutrally; the Shopify comparison is factual (hosted checkout, CSS at a high plan tier) rather than disparaging. Plugin authors who objected to the settings change are quoted rather than characterized. - **Reverse victim/offender:** Not present. No victim/offender framing appears in the source. - **Emotional cues and rhetoric:** Enthusiasm and mild embargo-induced hedging. The only persuasive pressure is ordinary product advocacy, disclosed by context — this is a vendor advocate on sponsored programming. - **One item that is not DARVO but belongs adjacent to it:** at [00:07:15] the tangled-extensions problem is generalized to "an e-commerce problem," which shifts a specific complaint about Woo onto the category. That is deflection rather than reversal, it is mild, and it is catalogued under Logical Validity above. - **Assessment:** DARVO is **not applicable to this source** — a product status update with no accusatory or defensive dynamic. ## 🎯 Conclusion - **Bottom line.** The through-line is **pushing capability down into core blocks and core APIs so it arrives everywhere at once.** The block theme is thin because the blocks are thick. WordPress 7.1's responsive styles land across 100+ Woo blocks for free. Shipment tracking becomes one extensible API rather than per-provider interfaces. Settings become React without extension authors touching anything, because the declarations were already declarative. That is a coherent platform strategy, and it is more interesting than the AI section it shares airtime with. - **The most valuable near-term item is the least exciting.** Several quarters of closing five-to-seven-year-old bugs, with a stated norm that every filed report earns a resolution or a clear answer, will do more for daily Woo users than anything in beta — and it is directly connected to the AI-PR review-capacity squeeze that every large project is now feeling. - **What to discount.** Nearly everything genuinely new is unreleased: block theme, settings conversion, shipment tracking, catalog view, dashboard AI, agentic commerce. The conversion and performance claims for block checkout are unsupported. And the dashboard AI — the most consequential item — was under embargo, so it cannot be evaluated at all until WordCamp US. - **The honest bit worth crediting.** Agentic commerce gets a straight answer: protocols exist, Woo has experimental support, and it "is not really happening in the world today." That is a vendor advocate declining an easy hype opportunity, and it makes the rest of his claims more trustworthy. - **Next steps for readers.** Audit what you install plugins for against what Woo already ships as blocks — the awareness gap is the cheapest win available. If you build extensions, find out where you sit relative to the settings auto-conversion before it reaches your screens. If you care about accessibility, push for an audit of the block theme's live filters and mini cart *before* release, since it will become the reference implementation. And subscribe to the developer.woo.com monthly newsletter if you follow nothing else. ## 🔄 Refactor Appendix — What's New With Woo? (July 2026 Member Meetup) > Density: 2–5 Literature atoms (H3), 0–3 Permanent candidates (H4). > Defaults: 3 Literature, 1 Permanent. Resonance filter: if you can't > articulate in one line why a claim matters, drop it. > > Konik claim-header rules: present tense, declarative, ≤10 words when > possible, searchable, unique, mirrors annotation focus if present. > > Atomicity: one declarative sentence per atom. "and"/"also" → split. > > Tag pool: #bmf · #addendum · #xref · #articleseed · #storystem · #share · #aphorisms ### 📚 Literature Atoms (H3) #### [H1] Filing a bug earns a response, always > [!quote] > if somebody gave put in the effort to file a bug report on GitHub, it really is our responsibility to fix it **Context & use**: - [00:02:17](https://www.youtube.com/watch?v=OkIVNKJADVo?t=137) - Target: a couple hundred open issues, nothing older than ~6 months, against 5–7 year old tickets today. The norm includes closing as "expected behavior, not a priority" — silence is the failure mode, not rejection. Adoptable verbatim by any maintainer. **Tags**: #xref #share <!-- atomicity: 1 idea ✓ --> #### [H2] Universal needs are the most variable needs > [!quote] > everybody is uses different payment providers, they use different email, they have different shipping integrations, they have different tax things **Context & use**: - [00:05:19](https://www.youtube.com/watch?v=OkIVNKJADVo?t=319) - The structural argument against an all-in-one bundle. Resolution pattern: where the need is universal, ship one extensible API plus one UI and let providers hook in — shipment tracking is the worked instance. Generalizes well past commerce. **Tags**: #xref #articleseed <!-- atomicity: 1 idea ✓ --> #### [H3] Declarative config lets the platform swap renderers > [!quote] > we already have all the information of what your fields are. Couldn&#39;t we just turn them to JavaScript for you, and you don&#39;t have to do it yourself? **Context & use**: - [00:09:59](https://www.youtube.com/watch?v=OkIVNKJADVo?t=599) - Because Woo extensions declare settings as a PHP array rather than rendering their own markup, the platform can absorb the entire migration cost. A rare case of a platform doing its ecosystem's work — and only possible because the config was declarative. **Tags**: #xref #aphorisms <!-- atomicity: 1 idea ✓ --> #### [H4] Building on core makes new core features free > [!quote] > as long as we keep building on core, if core does something special like responsive design ... it&#39;s just going to come free in WooCommerce **Context & use**: - [00:20:01](https://www.youtube.com/watch?v=OkIVNKJADVo?t=1201) - WordPress 7.1's responsive styles land across 100+ Woo blocks with no per-block work. Verified by an AI sweep over every block that found ~6 spots to fix. The clearest argument available for building on shared primitives rather than around them. **Tags**: #xref <!-- atomicity: 1 idea ✓ --> #### [H5] Agentic commerce is built but not happening > [!quote] > that&#39;s a cool future idea, but it&#39;s not really happening in the world today **Context & use**: - [00:24:12](https://www.youtube.com/watch?v=OkIVNKJADVo?t=1452) - Stripe and Google lead the protocols; Woo has experimental support; conversions are a tiny percentage and users aren't ready. A vendor advocate declining an easy hype opportunity — and the unresolved questions he lists (returns, refunds, support attribution, reputability) are the real blockers. **Tags**: #xref <!-- atomicity: 1 idea ✓ --> ### 🧠 Permanent Candidates (H4) #### [P1] Declarative configuration lets a platform absorb its ecosystem's migration cost **Claim** (one sentence, Courtney's voice): When extensions describe what they need rather than how to render it, the platform can change the implementation underneath them without asking anyone to migrate. **Evidence pointer**: [[#H3]] **Scope & conditions**: Requires the declaration to be genuinely complete — anything an extension renders itself is outside the platform's reach. Fails where authors have already escaped the declarative path for custom UI, which is exactly the group objecting here. The cost is uniformity: extensions lose their distinct look, and that is the actual tradeoff, not a side effect. **Links** (≥1 with annotation): - [[theme-json-as-contract]] — because extends to styling - [[Design-token-conformance]] — because applies-in visual systems - [[API-layer-delivery-precedes-interface-delivery]] — because extends <!-- atomicity: 1 idea ✓ --> #### [P2] Acknowledgment is the minimum a maintainer owes a reporter **Claim** (one sentence, Courtney's voice): A filed issue creates an obligation to respond, and closing something as expected behavior discharges that obligation while silence does not. **Evidence pointer**: [[#H1]] **Scope & conditions**: Holds where reporting is voluntary and the reporter bears effort. Requires staffing — Woo can commit because a company funded several quarters of it, which is precisely what smaller projects lack. Distinct from resolving: the obligation is to answer, not to agree. **Links** (≥1 with annotation): - [[Procedural-burden-falls-hardest-on-those-with-least-standing]] — because contrasts on which side bears the cost - [[Maintainer-governance-obligations]] — because extends - [[Paper-cuts-tracking]] — because applies-in WordPress <!-- atomicity: 1 idea ✓ --> ### ✏️ Fleeting Queue - [F1] Woo and Gutenberg independently converged on "paper cuts" as the name for accumulated small annoyances, and both are clearing them in the same window. Worth writing up as an ecosystem-wide maintenance turn — pairs with the Changelog #134 read. — https://www.youtube.com/watch?v=OkIVNKJADVo #fleeting #addendum - [F2] "Most extensions on Woo stores never come from Woo's marketplace — no revenue share, no review, no control." That is the same commercial-plugin-distribution gap The Repository's WP Rocket piece surfaces. Two sources, one unsolved problem. — #fleeting #articleseed - [F3] Accessibility of live-updating commerce UI — filters without page reload, slide-in mini cart, AJAX add-to-cart — is unexamined in the source and the new block theme will become the reference others copy. Worth raising before release. — #fleeting #inbox - [F4] He personally uses Ollie for his own Woo builds. Useful signal for my own stack, and a good sign the first-party theme is a reference implementation rather than a mandate. — #fleeting #xref - [F5] Playground can't do commerce because empty stores don't test anything. A seeded-store blueprint is an obvious, small, high-leverage contribution. — #fleeting #inbox ### → Things 3 (max 2 actions) - [ ] Audit my Woo builds for plugins doing what core blocks already ship — carousels, galleries, filters, mini cart — wordpress #things - [ ] Raise an accessibility review of the unreleased Woo block theme's live filters and mini cart before it ships — accessibility #things <!-- deep-read:sections end --> 📄 **Full text:** [[Full Document Contents/Articles/What’s New With Woo.md|What’s New With Woo? by YouTube]] ## Highlights - James Kemp, who's the product lead, product manager, is sort of triaging all of this stuff and assigning it through the product teams, through the engineering. So, the goal is by the end of the summer, fall time to have the backlog of issues in GitHub extremely low with the idea that like if somebody gave put in the effort to file a bug report on GitHub, it really is our responsibility to fix it or, you know, some of them are we're just saying, "Yeah, that's not an issue. That's expected behavior. Not a priority." But, at least there's a response. At least there's like a clear ([View Highlight](https://read.readwise.io/read/01m0sz6j8zxxzj9gkavrsd1yvf)) - Note: [H1] Filing a bug earns a response, always. Target: a couple hundred open issues, nothing older than ~6 months, against 5–7 year old tickets today. The norm includes closing as "expected behavior, not a priority" — silence is the failure mode, not rejection. Adoptable verbatim by any maintainer. - Tags: atom/literature/h1, share - your fields are. Couldn't we just turn them to JavaScript for you, and you don't have to do it yourself?" So, that's what they did. It's in beta right now, and they're starting to turn it on on specific screens, and see like I mean, it's a setting screen. It's not, you know, it's This isn't like the most complicated stuff. It's a form with a bunch of checkboxes and text inputs. And so, the idea is, can we just make that happen automatically? And I feel like that's kind of what I think people wanted to see from WordPress from the getting. And, you know, WooCommerce is generally kind of ahead of WordPress, and we're ([View Highlight](https://read.readwise.io/read/01m0sz726ah9ej5ntx9ymgzxqr)) - Note: [H3] Declarative config lets the platform swap renderers. Because Woo extensions declare settings as a PHP array rather than rendering their own markup, the platform can absorb the entire migration cost. A rare case of a platform doing its ecosystem's work — and only possible because the config was declarative. - Tags: aphorisms, atom/literature/h3 - blocks. And so, I think that's another benefit is like as long as we keep building on core, if core does something special like responsive design, which I think we've all been waiting a very long time for, um this is it's just going to come free in WooCommerce. So, you're going to have access to that. So, if you want to do your product pages really special on mobile or something like that, um you know, you can just do it. >> Yeah, yeah. I do I just want to plug that we just published an episode with Anne McCarthy who's the release lead for WordPress 7.1 where she shows us about ([View Highlight](https://read.readwise.io/read/01m0sz7knxjzkfa6ryq0hsk94n)) - Note: [H4] Building on core makes new core features free. WordPress 7.1's responsive styles land across 100+ Woo blocks with no per-block work — verified by an AI sweep over every block that found ~6 spots to fix. The clearest argument available for building on shared primitives rather than around them. - Tags: atom/literature/h4 - support for those so that you somebody could actually buy something in a chatbot from your store. Um, but the down the the the caveat there is that's a cool future idea, but it's not really happening in the world today. I think there's been like some tiny percentage of actual conversions and stuff, but it's not a a real thing that's happening very much. Users aren't really ready for that, but I think it is something that we're we're just going to have to prepare for. And so we do have the protocols set up and ([View Highlight](https://read.readwise.io/read/01m0sz81f6zz0wpkzv1b1dfj1x)) - Note: [H5] Agentic commerce is built but not happening. Stripe and Google lead the protocols; Woo has experimental support; conversions are a tiny percentage and users aren't ready. A vendor advocate declining an easy hype opportunity — and the unresolved questions (returns, refunds, support attribution, reputability) are the real blockers. - Tags: atom/literature/h5