Normal view

WooCommerce 11.1.0: Release Notes

Release

WooCommerce 11.1.0 is available now

This release is now available for download. Review the highlights below, follow the update guide, and check the full changelog before updating production sites.

Highlights

  • Product variation image galleries
  • Right to order withdrawal
  • Faster Store API & REST requests
  • Released: September 1, 2026
  • Backwards compatible
  • Database update: Yes
  • PRs: 561
  • Contributors: 77

WooCommerce 11.1 is here! This release includes a number of performance improvements for variable products and block registration, more accurate refund details in API endpoints, improvements to product CSV imports, and experimental support for videos in product galleries. Here’s a few more highlights:

Introducing variation image galleries

Variation galleries are now enabled for all stores in WooCommerce 11.1 and WooCommerce Additional Variation Images is being retired. That means you no longer need a separate extension to add image galleries to your product variations — it’s a native WooCommerce feature available to every store, for free. There’s nothing to switch on: the experimental toggle is now gone from the Features screen, and a database update (11.1.0-1) enables the feature even on stores that had previously opted out. (#67884)

Right of order withdrawal for EU customers

Disabled by default, stores that need to conform to EU guidelines can enable the order withdrawal form for their customers. This feature creates a new screen in the My Account page for users to submit an order withdrawal request. The request is logged and the merchant is notified via email and the dashboard. Because each store is unique and the process may differ, withdrawing and potentially refunding an order remains a manual process.

Cleaner admin orders for virtual products

Orders that don’t need fulfillment no longer show a shipping address in the admin order summary. Store API checkout retains billing-derived shipping data for compatibility, so virtual-only orders were displaying an address that meant nothing; that read-only address and its implicit phone fallback are now hidden. Physical, mixed, and unresolved orders keep their details. (#66488, refined by #66627).

Video support in product gallery (beta)

WooCommerce 11.1 introduces experimental support for videos in both classic and block-based product galleries. The initial release supports locally uploaded videos only. The feature is disabled by default and can be enabled under WooCommerce → Settings → Advanced → Features → Product gallery videos. As an experimental feature, it may change in future releases. Share your feedback in the GitHub discussion. (#65396)

Developer updates

Unified block editor assets
A new experimental feature replaces WooCommerce’s per-block editor scripts and styles with shared JavaScript and CSS bundles, cutting the number and total size of editor asset requests. It’s disabled by default in 11.1; with it off, existing handles and per-block assets behave exactly as before, and frontend assets are unchanged either way. (#66200)

Changes to order item deletion
WC_Abstract_Order::remove_order_items() now records which item IDs existed when removal was requested, so replacement items an extension adds before $order->save() are no longer deleted by accident. Most extensions won’t require a change, but if you maintain a custom order data store, review your get_item_ids() and delete_items_by_ids() implementations.

Block registration skips non-rendering requests
WooCommerce 11.1 no longer registers block types and patterns on requests that can’t render or edit blocks, making Store API and REST requests 30–42% faster. If your extension renders WooCommerce blocks during one of those requests, opt back in with the new woocommerce_should_register_blocks filter. Product and variation descriptions are handled on demand and need no action.

Retiring stable WooCommerce Admin feature flags
A set of stable WooCommerce Admin features now load directly instead of through the feature configuration pipeline. No functionality is removed, and deprecated shims keep Features::is_enabled() and window.wcAdminFeatures returning compatibility values, but they now emit deprecation warnings, so audit your extensions and remove those gates before the shims go.

For more information about this release, including Developer Advisories, API changes, and database updates, read the WooCommerce 11.1 pre-release highlights.

Code Contributors

WooCommerce 11.1 includes 561 PRs from 77 contributors:

adimoldovan, Aljullu, allilevine, alopezari, annchichi, Anuj-Rathore24, asahasrabuddhe, ayushpahwa, bacoords, bruberries, chihsuan, chubes4, costasovo, daledupreez, dilirity, dinhtungdu, dmallory42, drewmt, eason9487, elazzabi, faisalahammad, frosso, gigitux, iamdharmesh, ikamal7, j111q, jamesckemp, JanaMW27, jorgeatorres, kalessil, kmanijak, Konamiman, kraftbj, LiamSarsfield, louwie17, luisherranz, lysyjan, m1r0, malinajirka, manzoorwanijk, MarcinDudekDev, Mayisha, mcliwanow, mikejolley, mordeth, NeosinneR, nerrad, noumanofficiall, oaratovskyi, oxfordmetadata, poligilad-auto, prettyboymp, puneetdixit200, R1shabh-Gupta, ralucaStan, retlehs, rtio, s-a-s-k-i-a, samiuelson, SantosGuillamot, sawirricardo, senadir, shsajalchowdhury, sunyatasattva, Thelmachido, tjcafferkey, TowyTowy, triple0t, tyxla, vbelolapotkov, vismaytiwari, vladolaru, webdados, wjrosa, xristos3490, yjailin, yuliyan

Download WooCommerce 11.1

Browse our update guide for more details on how to update to the latest version of WooCommerce.

The post WooCommerce 11.1.0: Release Notes appeared first on The WooCommerce Developer Blog.

Retiring the magic strings: enum classes in WooCommerce core

WooCommerce is old enough that its most important string values (order statuses, product types, stock states, tax modes) predate almost every modern PHP convention. Across the WooCommerce codebase, and in many extensions, every one of those comparisons was written against a raw string literal:

if ( 'completed' === $order->get_status() ) { // hope you spelled it right!

Over the last few years, WooCommerce has begun shipping a family of enum classes under Automattic\WooCommerce\Enums. These are named, documented constants for order statuses, product types, stock states, settings values, and more.

The enum classes are considered a public API, and extension developers are encouraged to use them. This post covers what’s available, why we built classes of string constants instead of native PHP enums, and what shipping them taught us about load order and backward compatibility.

The price of a “magic string”

String literals might feel easier to write or more simple than classes, but the come with tradeoffs. Spread across a codebase the size of WooCommerce and the many extensions, magic strings tax you four ways:

  • Silent errors. Linters, autoloaders, and tests may not catch an error like typing 'complete' instead of 'completed'.
  • Abiguity. WordPress stores post-prefixed order statuses as wc-completed, while most WooCommerce APIs expect the un-prefixed completed, something a developer may only discover the hard way.
  • Discoverability. An agent searching 'simple' to find product-type logic returns half the codebase. Grepping for ProductType::SIMPLE should return a much narrower, accurate set of results.
  • Documentation. The definition for a status like on-hold will now live in a docblock next to its declaration.

Enum classes have the added benefit of clarifying empty strings based on intent. For example, woocommerce_default_customer_address treats '' as “no default”, which is unguessable without a named constant.

Why not native PHP enums

PHP has had enum support since 8.1, but for a few reasons, it wasn’t a viable solution for WooCommerce. Primarily, WooCommerce’s minimum supported PHP version is 7.4 which doesn’t include support for native enums.

There’s also an architectural difference. These values are already stored as plain strings in millions of databases, and thousands of extensions expect them to stay that way. Native PHP enums would turn those strings into objects, which could break existing code. String constants avoid this problem. OrderStatus::COMPLETED still produces the same 'completed' string, so developers can use the clearer name without changing how WooCommerce works. Existing code continues to work, and extensions can adopt the new constants when they are ready.

final class OrderStatus {
	/**
	 * Order fulfilled and complete.
	 */
	public const COMPLETED = 'completed';
	// ...
}

Enum classes currently available

The src/Enums directory (and its README) is an authoritative list of what’s currently available. The highlights:

  • Orders: OrderStatus (unprefixed values like completed), OrderInternalStatus (the wc--prefixed variants stored in the database), OrderItemType
  • Products: ProductType, ProductStatus, ProductStockStatus, ProductTaxStatus, CatalogVisibility
  • Payments: PaymentGatewayFeature, the strings gateways declare in their supports arrays
  • Settings values: WeightUnit, DimensionUnit, CurrencyPosition, TaxBasedOn, TaxDisplayMode, DefaultCustomerAddress, StockDisplayFormat, CatalogSortOrder

Using the constants in your extension

These constants are intentionally a publicly discoverable API, with explicit public visibility, docblocks, and developer docs. Extension developers are welcome to rely on them.

use Automattic\WooCommerce\Enums\OrderStatus;
use Automattic\WooCommerce\Enums\ProductType;

if ( OrderStatus::COMPLETED === $order->get_status() ) {
	// ...
}

$products = wc_get_products( array( 'type' => ProductType::SIMPLE ) );

Two things to check before adopting them:

  1. Your minimum supported WooCommerce version. The classes landed incrementally: OrderStatus in WooCommerce 9.5, the product classes around 9.7 and 9.8, the settings-value classes across the 10.x releases. If you support older versions, keep the literal or guard usage with class_exists().
  2. Which string WooCommerce expects. OrderStatus::COMPLETED is completed; OrderInternalStatus::COMPLETED is wc-completed. Most WooCommerce functions take the un-prefixed form; database-level and post_status contexts use the prefixed one.

The product querying and order querying docs show the constants in use alongside the literal forms.

What’s next

New vocabularies in core should now get an enum class by default. WooCommerce still contains many string values that deserve names, and contributions are welcome.

The post Retiring the magic strings: enum classes in WooCommerce core appeared first on The WooCommerce Developer Blog.

#232 – Aaron D Campbell on Navigating WordPress Security in the AI Era

Transcript

[00:00:19] Nathan Wrigley: Welcome to the Jukebox Podcast from WP Tavern. My name is Nathan Wrigley.

Jukebox is a podcast which is dedicated to all things WordPress. The people, the events, the plugins, the blocks, the themes, and in this case, navigating WordPress security in the era of AI.

If you’d like to subscribe to the podcast, you can do that by searching for WP Tavern in your podcast player of choice, or by going to wptavern.com/feed/podcast, and you can copy that URL into most podcast players.

If you have a topic that you’d like us to feature on the podcast, I’m keen to hear from you and hopefully get you, or your idea, featured on the show. Head to wptavern.com/contact/jukebox and use the form there.

So on the podcast today we have Aaron D. Campbell.

Aaron is a seasoned veteran in both the internet and WordPress space. With over 25 years of experience spanning agency work, security products, hosting giants like GoDaddy and Newfold, and now his role at Monarx, a company focused on malware detection and remediation, particularly for web hosts. He’s led, the WordPress Security Team, has been involved deeply in shaping security practises, and remains tightly connected to the WordPress ecosystem.

We talk about the rapidly changing landscape of WordPress security, specifically how the advent of AI has escalated the speed, scale, and complexity of attacks, moving the security game from a battle of wits to a battle of compute power. Aaron discusses how attacks that once required human ingenuity are now orchestrated by AI agents, capable of chaining vulnerabilities that humans would struggle to conceive.

We get into the shift from a reactive to a proactive security posture across the WordPress ecosystem. Aaron explains how both attackers and defenders are now deploying AI leading to an arms race, where AI is used to combat AI, and where collaboration among security teams is just as crucial as information sharing among adversaries.

Which chat about the motivators behind attacks, spoiler, it’s almost always money. And the specific vulnerabilities WordPress faces as the most popular CMS on the web. Of interest is the narrowing window between when vulnerabilities are discovered and when they’re exploited, how supply chain attacks are on the rise, and what the WordPress “Protect the Shire” innovation means for plugin security.

Towards the end of the episode, we explore practical security advice for everyday WordPress users, with Aaron, recommending actionable tips on updates, choosing security minded hosts, and monitoring for Compromise credentials.

If you are concerned about how AI is reshaping the WordPress security landscape, and want to know how the community is responding, this episode is for you.

If you’re interested in finding out more, you can find all of the links in the show notes by heading to wptavern.com/podcast, where you’ll find all the other episodes as well.

And so without further delay, I bring you Aaron D. Campbell.

I am joined on the podcast by Aaron Campbell. Hello, Aaron.

[00:03:43] Aaron D Campbell: Hello, nice to be here.

[00:03:44] Nathan Wrigley: Yeah. Thank you for joining me. We’re in a corridor. I should say that at the very beginning. We’re in a corridor at WordCamp US, and so if background noise becomes a problem, we’re just going to have to cope with it. So apologies. But thank you for joining me in a corridor.

[00:03:57] Aaron D Campbell: Absolutely.

[00:03:58] Nathan Wrigley: We’re going to talk today a little bit about WordPress security, and particularly about the advent of AI, and the way that certainly in the more recent past, it appears to have upended what once was normal, I think it’s fair to say. I think things are happening at a rate of knots that perhaps a year or two ago we wouldn’t necessarily have predicted.

Do you want to just give us a little bit of background about yourself in terms of where you have worked, where you currently work, and what it is that you do for a living?

[00:04:25] Aaron D Campbell: Sure. So I guess I have worked in the internet space for a very long time at this point. I guess 25 years-ish. Ran my own agency for a long time and then into security product in the WordPress space, and over into hosting at GoDaddy, at Newfold, at hosting.com.

During that time I ran the WordPress security team for a couple years, have continued to be involved with it along the way, and now I am over at Monarx. We do malware detection and remediation, and have some security tooling for web hosts. So I’m still very tightly tied into that space on a few fronts.

[00:05:09] Nathan Wrigley: Is Monarx a new company? Because it’s not one that may necessarily come into mind when we talk about security online, WordPress security specifically.

So if you’re willing, could you just give us a little bit of a potted history of Monarx and what specifically you do in the WordPress space? I think it’s perhaps more related to hosting companies than it might be to end users. Just flesh that out a little bit.

[00:05:33] Aaron D Campbell: Yeah. Monarx has been around probably longer than you expect, six or seven years. The name’s may be not as recognisable, because a lot of times we are a white label in the background. Hosts run us, and you may not know that.

We protect more than just WordPress, but obviously WordPress is a big part of that. And we help hosts keep their users, their end users, safe and secure and malware free by monitoring the files, the runtime, having a WAF layer, protecting it several different layers along the way.

[00:06:08] Nathan Wrigley: So is this kind of like a white label solution? You are in talks with hosts, many of which I’m sure we’ve heard of, but their purchase of the products and services that you sell is white labelled.

[00:06:20] Aaron D Campbell: Yes, they may sell us as their own security product. They may also just include us in higher end hosting packages so that the malware detection and remediation and all that kind of stuff is included in your package. It varies from host to host, but most of the time you’re not seeing the Monarx name out in front, but you’re benefiting from our services anyway.

[00:06:40] Nathan Wrigley: So does that allow you to, because you are cross platform in terms of hosting company, hosting company X, hosting company Y, hosting company A, B, and C. Does that give you a larger depth of knowledge for want of a better word? So you can see that hosting company A’s got this Linux set up, and these kind of things are happening.

[00:06:59] Aaron D Campbell: Yes, it does. It’s less about their specific setups. I think the most valuable thing of being across many hosts like that, is that we see attacks, or new and novel malware, or those kinds of things happening in pockets and can often then protect against it globally, even though maybe it first started at host A.

By the time it spreads to host B X or Y in your example, we’ve already been able to understand what that is and block it across the whole realm. So we get a bigger picture, which is super useful. Especially as we start talking about some of the AI stuff and how fast it moves. That’s really necessary to stay ahead of that curve.

[00:07:42] Nathan Wrigley: Okay, so let’s move into that a little bit. And I think if we were having this conversation, let’s go for four years ago, that seems like a long enough period of time where AI was not really on anybody’s menu.

And now we seem to be in the era where the human is really being surpassed in almost everything logical, let’s go with that word. If it can be achieved with some kind of logic then AI seems to have surpassed humans.

And, especially recently, there seems to have been an uptick, not just in the WordPress news cycle, but also just in the general news cycle about, okay, we need to be a little bit more mindful about the products and services that we buy. We need to be more mindful about the security and logging in and credentials and all of that.

But specifically in the WordPress space over the last three or four months, I’ve heard story after story, which was unlike anything I’d heard before. These kind of chained attacks where, something that a human probably would never have conceived and pulled off is now possible. You spend 25 US cents on an AI agent, wait for six hours, and it’s come up with these 14 overlapping things, and it can hack WordPress Core and various other things.

So just paint the landscape of how alarming it is, and then presumably you can paint the landscape of how not alarming it is, because how you can mitigate against that.

[00:09:00] Aaron D Campbell: That’s fair. Let’s explain the reality and then let’s hopefully, help comfort people at least a little. It can be pretty scary. You’re absolutely right. AI has dramatically changed the game. And the way I like to explain it is it hasn’t changed the absolute core realities of the game in that there’s still a bit of cat and mouse. They’re trying to surpass us. We’re, trying to stay ahead of them.

But the scale and the speed and the complexity at which it is able to happen now is nothing we could have imagined four years ago. Honestly, even two, two and a half years ago. It has moved that fast. And what that looks like are, a few different things.

One, the speed at which AI can find issues in code, potential exploits, vulnerabilities, et cetera, is so much faster than any human. Like the compute power of it doing those logical bits rather than humans doing those logical bits, makes that move so fast. So the number of things being found, and being either reported or exploited, or both, the volume has just gone up dramatically.

And then on the complexity side of it, you are right. A simple example of that, one of the WordPress Core reports that I looked at recently, I needed to print it out and mark it up with a pen to wrap my brain around all these steps that it was taking. When I printed it out, it was 11 pages. 11 pages of like steps and instructions for an actual vulnerability that turned out to be real.

If four years ago that had existed in your piece of software, you would consider your software absolutely secure. No human’s ever going to find that. No one would ever know about it. And now AI is able to chain all those steps together into something that it can then write scripts to go automate and exploit.

And so those two things have both really shifted the game in a way that feels like it can put software owners, software managers, SaaS services, all these things on their back foot. There’s just such this flood, and such a complex flood coming at you.

[00:11:10] Nathan Wrigley: So I guess also the problem is that these things never sleep. So four years ago, every human, maybe they could put 10 hours in at the computer and then they would have to rest. So you get a, breathing space, and and the human can do this one thing.

But that’s not the case here. With an AI, presumably it could have 10, 50, a hundred, a thousand, the sky is the limit, things happening simultaneously. Just testing absolutely every permutation of everything conceivable. And then coming back with something. I don’t even know how we compete against that. And obviously we can get into that in a moment.

Is this a moment of despair or is there genuinely a way of getting out ahead of it? Or is it always going to be a case looking into the future where you are going to be reactive instead of proactive? In other words, when you wake up in the morning and you print out the 11 and then next year, the 30, and then the year after that, the 80 page document, how does that make you feel? Are you sanguine or is it just a prophecy of doom.

[00:12:08] Aaron D Campbell: I think it is a time of overwhelm, but hopefully not despair. Which is different. And I think that as big technology shifts hit, which AI is a big technology shift. There is often a significant adjustment. And we are at that time, and I am even one that maybe would say, I think it might get a little bit worse before it gets better, but it’s definitely going to get better.

And I see the path there in some of the foundations that we’re laying in things that we’re learning right now during this time of overwhelm, where we’re feeling flooded like this, is going to put us in a place to start getting into that curve where everything gets better.

And I think that, what’s the right way to put this? I think that the path there is apparent, but takes some time. And part of that’s because we have to shift from the being reactive to the being proactive all the time. Because agents move so fast to 24 hours a day, seven days a week. And the second they find a thing, they can immediately, automatically start trying to exploit it.

We have to shift to being ahead. Because there is no longer a gap in between when a thing is found and when it’s exploited, for us to fix the thing. We have to get ahead.

[00:13:36] Nathan Wrigley: So, you are obviously deep in the weeds of this, and it sounds like you’ve got an intuition that at some point in the near to midterm future, you feel like you are going to reach a point where things start to improve. That was the implication, I think of what you said.

What is that intuition? How do you come to the conclusion that there is an opportunity for things to improve. Even if you need to go into the weeds a little bit. I’m curious as to how it’s not a prophecy of doom, and how you believe that a moment will arrive where, I can’t answer that for you. I’ll just open it up.

[00:14:06] Aaron D Campbell: Yeah. So I think that some of this comes from historical experience, right? We’ve had these kinds of experiences where say, a certain type of hash that we used for security became a thing that hackers could break with the level of computing power that they finally had access to.

And that felt doom and gloom. But also we created better hashing algorithms. We created better things that were able to counteract that. We were able to shift to those, and we were also able to learn from them and think further forward.

So now some of the algorithms that we’re using aren’t just better enough to handle current computing, but better enough that we think they’re going to last a decent ways into the future.

I think that there are similar things with AI now. Where we are leveraging the same kind of tools now that these bad actors are, and we’re learning how to use them not just to protect against the way the bad actors are using them, but to get ahead enough to stay ahead of them.

And the way that looks, because that sounds maybe too vague to be realistic I guess, is we’re not just running those same algorithms against our code, or those same models against our code and hoping that we find the stuff before they find it. We’re instead also looking at how can we push to a different part of the stack? How can we protect against things that we’ve never seen? How can we start to recognise these patterns so that we can look at behaviours and protect against those, rather than just flaws that need to be patched. It’s shifting our thinking some, but I think in a way that’s going to help us get ahead in this game.

[00:16:03] Nathan Wrigley: Okay. That’s really interesting. I have a question surrounding how this kind of stuff happens, and I’m thinking about it from the adversarial’s point of view. What is that like? Because I have a notion that a decade ago it was individuals, perhaps offices, that’s probably the wrong word, but, collections of people sitting in a space, but there would be a finite number of them. There may be 10 in a room, one in a room, a hundred in a room.

But I don’t know if that’s still the case. Do the adversaries that you are dealing with, do they have a collaborative approach to hacking? Do they share information? And then the flip side of that is do you also, in the industry that you work in, do you share information?

If you discover something, does Monarx treat that like it’s your intellectual property? Or is there a, a whole system of sharing that amongst the community so that everybody benefits from the work that you do? You’re giving away the hard work that you’ve done. If that’s the case.

[00:16:59] Aaron D Campbell: So, first let me just say personally, one of the most important things to me is to raise the level of security across the whole internet, because that is better for humanity that relies on it so much, for all kinds of things in our daily lives, and for sharing information and making progress forward as people.

I think that I’m not alone in the space. Like I think that a lot of us that were drawn to this security space are drawn to it because it is a way to improve life for everybody. Will there be some intellectual property for individual companies? Yes, but I think it’s a lot more in how we approach the thing, and less we’re not going to tell people about this new vulnerability, or this new method that we found. Because we do want to be able to see the end user protected. Like that is the way we’re going.

Backing up to your, how do the adversaries work? It’s been a long time, I think since they sat in rooms together. They’re now virtual rooms, right? They can be spread all over the world, but still be working together. And they definitely do. They share information around. For us to be able to keep up with that, we have to share information around too. That is super important.

Simple example of that, the WordPress Security Team. Let me step back from Monarx and talk more of the space in general. The WordPress Security Team. You talked about how for the last few months you’ve seen maybe more security releases going out from WordPress and stuff. The way that the WordPress Security Team treats those, when we find out about them, and we triage them, and we realise that they’re real, and we start figuring out what our approach is to patching them. We then have a whole private Slack channel that has other people in it that can help us get protection out. Broader, wider by sharing some of that information sooner.

Cloudflare can maybe put some rules in place, and protect tonnes of people before the WordPress release goes out. So can some of the big hosts. So can some of the security groups. And so not only do we share that information, we’ve built it into our processes as a must, because that’s the only way to really do it right, and really protect as many people as possible. Because our adversaries are doing that. And so we have to as well. And we’ve just realised that, learned from it and made that the right way to do it.

[00:19:26] Nathan Wrigley: I’m just going to flip back to the comment that you made a moment ago where you said that you woke up and you printed out this summation. Let’s go with that. And it was 11 pages, and presumably that took a certain amount of your day to parse and understand.

How likely is it that that process will begin to run away from humans’ capacity to actually do it? So as an example, let’s say that a year from now that thing that you print out is 50 pages or 80 pages. Just the reading of it would be a whole morning, let alone the understanding of how those layers, and the stacks and the way that they’re overlapping and reliant upon each other.

Have we now, or have you now as an industry, have you almost handed the responsibility to figuring that stuff out, figuring out what the adversaries are doing? Has that gone to AI from your part as well? So is it AI versus AI basically, which seems very dystopian.

[00:20:18] Aaron D Campbell: We definitely pit AI against AI. It’s an extremely useful tool to combat itself essentially. And yeah, even for that 11 page one. Yes, I had to read through it and figure it out. but I did use AI to help summarise that. What are the steps that I need to do? Where does this actually track to in the code base?

I use it as an assistive tool in getting through that. And I do think that the longer the reports get, the more that’s going to be necessary. And now I personally, and several other people that I work with, have built testing rigs in AI, in various models, that are purpose built to help with this.

I can give it a report, in the repository and it can check its viability. It can see if that’s simplified. Check certain things. Is this a thing that requires some level of authentication, all these things that we use to have to do manually. And now we’re sharing around these sort of test rigs, or assessment rigs, that use this so that we can all use them, and grow them faster and make them better and make them more efficient. Because we are pitting AI against AI in many ways.

And as human, I think that it’s still important for the human to guide the process in a way that’s ensuring the fix is forward thinking enough, and that it’s in the right place and whatnot. Because in the end, the software is largely used by humans. But, in order to scale to the level that AI is pushing us to scale to, the human needs to be the decision maker, and possibly the opinionated one on form, and function, but not the logical power behind any of it now.

[00:22:01] Nathan Wrigley: Do you get the sense that WordPress itself is the target, or is WordPress just a bit of collateral damage? Are these adversaries of yours, are they specifically targeting WordPress because it’s got this giant footprint? Or is it more a case of this is just the adversaries just spraying and scatter gunning, and it just so happens that every so often they stumble across a WordPress thing.

[00:22:23] Aaron D Campbell: There is spray and scatter gun, just not running WordPress, or running your own bespoke thing is not enough to get away from AI trying to break your thing. But the bigger you are, the bigger the potential benefit from finding an exploit in you. And therefore, the more you are, like the bigger you are, the target is on you.

So WordPress has a big target, but it’s not just WordPress. Some big hosting companies also have a big target on their infrastructure in the same way that they’re targeting WordPress, their targeting, maybe a Hosting or a GoDaddy or a Blue. Someone big that has many people on it, not because they think their security is lax, or that they have some reason to suspect that there’s vulnerabilities, but because the payoff of finding a vulnerability there can be big. And so there’s a big focus there.

So yes, the bigger you are, the bigger the target. But that doesn’t mean that the scattershot isn’t also happening. And that they’re not also hitting small targets.

[00:23:24] Nathan Wrigley: Yeah. I suppose there would’ve had to have been a lot of joined up thinking in the past from a human to discover that, “Okay, this thing with Linux over here, okay we’ll just store that somewhere. But then there’s a PHP thing over here. Oh, and then curiously, there’s a PHP thing in WordPress, which,” that would’ve all had to have been conjured up by a human. And the memory of that would be difficult to maintain over time. But presumably the AI can just remember that forevermore. Store that PHP thing for the next decade and suddenly whip it out when it’s happens to coincide with some other thing. It’s fairly bleak.

Okay, so in terms of WordPress specifically, what is the incentive specifically? Why would somebody, let’s say somebody was coming after WordPress. What is it that they gain? What could they possibly have that benefits them off the back of a, let’s go for WordPress Core vulnerability which is, I don’t know, you can successfully log in as an admin or whatever it may be. What do they actually gain?

[00:24:17] Aaron D Campbell: It really comes down to money in end, if I’m honest. WordPress Core powers tens of millions of sites all over the web. Some of those have valuable stuff on them. Many of them frankly don’t. But that doesn’t mean that they’re worthless. They can be used, you’ve seen pharma ads and stuff showing up on a site, and it’s a pay per click kind of thing. And someone’s making some money off of putting not great ads your site. Even if you don’t get a lot of traffic, they’re making something. And when you’re looking at the potential of this vulnerability could apply to tens of millions of sites, you don’t need to make much per site.

But also, you could use that site as a way to have broad compute power to attack some other site. You’re using tens of thousands of sites to do it. Each one of them is on some separate IP. So now you have a distributed attack that’s harder to block than if you were doing the same attack from one place.

But you’re only doing that because it costs a lot to buy your own distributed power from everywhere. So you’re essentially stealing it and it’s making it, there’s some sort of worthwhile monetary value from it.

And so you may think, they can’t make anything off my site. They don’t have to. Your site’s one small bit in a huge array of sites that they’re trying to get, to get some monetary benefit in the end.

[00:25:40] Nathan Wrigley: So there’s no one size fits all. But money is essentially the broad overlapping thing?

[00:25:46] Aaron D Campbell: I mean, there are exceptions to that, where people are doing it for some political reason. Or some moral directive that they have or whatever. But the vast majority can be traced back to there’s money in it somewhere.

[00:25:59] Nathan Wrigley: I wonder curiously, because you mentioned about things like, pay per click style, you take oversight and you flood it with, I don’t know, nonsense about the thing that you’ve got and you want the world to notice. I wonder if curiously, people’s adoption of AI and that different way that we’re searching for things will actually impoverish that way of monetizing, because simply nobody’s actually looking on a search, well, increasingly people seem to be relying less and less on a search engine, and so maybe that kind of bit of it will dry up. Who knows?

[00:26:27] Aaron D Campbell: I love the optimism there. And I would like to think that those ads specifically probably will at some point. But the root of how those work is, I’ve broken into a site and I can inject some JavaScript ad, or some something like that.

And if those ads stop being valuable, then maybe I can inject some AI directives so that when an AI agent of some kind hits that site, it’s getting some sneaky thing snuck into its memory, or pulled in as a skill, that can then use that AI agent for nefarious purposes in the future.

I think that we can’t lower our guard against those things, because our adversaries will pivot and reuse it for something else. And so we will continue to protect against it.

[00:27:13] Nathan Wrigley: I’m going to peel back the contents of your head a little bit here. Because I’ve often wondered what the characteristic is of somebody like you who constantly facing this tidal wave of things. You’ve got to get up every morning, and every morning you could potentially wake up to the next big thing.

How do you just remain calm in the face of all of it? It’s a peculiar question, I realise, but tomorrow could be the next big thing. The day after that could be the next big thing. I’m imagining on most days now there is not necessarily the next big thing, but there’s a thing. It’s like you’re a fireman or something, except that there’s a fire going off in every district of town, and you are constantly busy and you never get to put the fire hose down. You’re just constantly at work.

[00:27:52] Aaron D Campbell: Some of us love that little consistent regular shot of adrenaline, and we get it in different ways than the firemen. But, honestly, I love complex problems solve. I love the challenges. Do I get exhausted and burnt out at times when they really do come every day for X amount of time? Sure, I’m human, I need to sleep, et cetera. But I think that it’s because I enjoy figuring out those really difficult problems, that I enjoy being in this space. And even specifically on this side of the space, the white hat side.

[00:28:26] Nathan Wrigley: Yeah. I suppose it’s like playing a good opponent at chess. You enjoy the chess game, even though it’s a hard thing and it stretches your brain. You play the chess over and over again because it’s a pleasurable thing to have your brain exercised in that way.

[00:28:39] Aaron D Campbell: And it’s like the more you do it the better chance you have at winning at chess. And I think it’s the same way in our game, right? Like the more you’re doing it, the more ways you’re finding to outmanoeuvre and to essentially win, and keep people safe online. And that’s, that’s exciting.

[00:28:56] Nathan Wrigley: You get the fist pump moment do you, there’s once in a while where you literally figure something out and you’re like, I nailed that.

[00:29:04] Aaron D Campbell: You absolutely do.

[00:29:04] Nathan Wrigley: Okay. Yeah. That’s really interesting. Your bio reads like an open source manifesto. I know that open source has been the thing for you throughout your career. I imagine that you could have gone into proprietary security and all of that.

But how does open source, particularly WordPress, how does that approach to developing software, how does that benefit the position that we can take and the security posture that you can take, and the reliability that you can have in things like WordPress going forwards? In your head, does it offer a superior model for fighting the adversaries?

[00:29:35] Aaron D Campbell: Yes, in my opinion it offers a superior model for fighting the adversaries. And the reason is actually still the same as it was 20 years ago when I started doing this. And I’ll explain why in just a second, but first, the reason is because we are able to benefit from many intelligent people, many more than any single company could with their source code.

Looking at our source code, and finding the weaknesses and even pitching in to help fix them. Hundreds of thousands, or millions, of people around the world are looking at our source code, finding those issues, and able to help pitch in and fix them, or report them to us so that we can, by having all that out there, it’s sort of like a building’s not less likely to collapse because no one saw the crack. It’s actually better that people are inspecting it, and finding those things and making sure it’s done right.

Now, that has shifted a little bit now, where in the past our adversaries looked at our source code too, right? They would immediately look at our repository when new things went out. As a matter of fact, when I ran the security team, I stopped committing stuff for a while, because it turned out that was a tell that this thing was probably a security issue, and people would look at that and try to figure it out.

So now the adversaries are using AI to watch our source code, which is also open to them, 24 7 and really look deep at it. But so are those many thousands of people using our source code for good. And so it’s still true that we have so many people on our side in helping us out, because our source code is out there because we’re open source, and it outweighs the bad. We find things faster because of that, and ultimately end up with more secure software more rapidly.

[00:31:36] Nathan Wrigley: Is there ever going to become a time where the amount of time that a vulnerability is available becomes moot? So in the past, a six hour window, where something wasn’t patched in WordPress Core, that’s a thing, but it’s not really a big thing. Maybe a month where something’s unpatched, that’s a big, I’m just wondering if in the future with the nature of the adversaries that you described and the tooling that they can bring to bear, if even like a three or five second window is going to become a thing.

[00:32:05] Aaron D Campbell: That is possible. We’re not at the three to five second window yet, so that’s good. I’ll let everybody relax a little bit. But the time from vulnerability disclosure to exploitation has shrunk dramatically over the last few years.

We did in fact used to have weeks, and then eventually days where it was okay to find out about the vulnerability, and responsible people, or responsible hosts, or responsible software companies could see that disclosure, patch the problem before there was much exploitation at all. And that’s now hours for major vulnerabilities.

As a matter of fact, we did a Monarx in conjunction with Patchstack, did like a year in review, thing looking back at last year. And we saw that for the more major vulnerabilities, it was about five hours. That’s not enough time for, you know, what happens if it happens in the middle of the night for a host who’s constantly monitoring that, immediately patching it, that’s difficult. And I do think that it will continue to shrink. And that that time that causes risk will be shorter and shorter.

And, we saw that with the recent wp2shell WordPress exploit. Once we released the patch, and everything was out there, the spike of exploitation that we as Monarx saw, like monitoring stuff happened within 30 minutes. Honestly, even a little bit faster than that. But the big spike started coming in about 30 minutes later, and that is just really fast.

But on the flip side, all that coordination that I talked about that WordPress did, had many millions of people already protected by then. And that’s how we have to look at it. We have to say, this is eventually going to get down to three to five seconds being a problem. How do we get ahead of it? And that’s what we’re trying to do.

[00:34:03] Nathan Wrigley: So a timely thing at the moment is this new innovation in the WordPress space called Protect the Shire. And Protect the Shire is the, a time bound moment where a plugin that has an update, it can’t be updated at the moment, I believe it’s standing at something in the region of six hours. On the face of it, that seems like a really excellent posture. But then there’s the flip side of that. If an exploit becomes discovered, and nobody can update their plugin for six hours, then that’s a big six hour window we’ve just painted. in the future where milliseconds may count. What do you think about that? It’s a interesting innovation. It’s something new. It was worth a try. Do you think that’s the way forward?

[00:34:41] Aaron D Campbell: I think it, was not only worth a try. I think it was a really good choice, and I think it will continue to be. We are seeing that a lot of current attacks are essentially supply chain attacks. How can we compromise whether it’s some package, an NPM package or something like that. Or whether it’s a plugin that’s gotten sold to a nefarious person, or even just hacked into and taken over by a nefarious person. That is happening more and this six hour gap helps protect against that.

But it can’t be a hard and fast, locked in stone, can never have exceptions, rule. And the truth is, it’s not. If there is a vulnerability in your plugin, or especially in a major plugin, reach out to the WordPress Security Team because we can coordinate a faster release, we can make an exception to that rule when it’s necessary.

And I think that for security fixes that are clearly security fixes that exception iss an easy one to make, because we do want to protect immediately. But slowing things down enough to make sure that there’s not been some sort of supply chain issue that is actually going to cause a vulnerability rather than fix one, is smart.

And so I think that it will find the right balance there as we continue to move forward, and figure out how to make better processes around this, to make it easier to do the right thing all the time, and know exactly which of those right things. But I think at the moment we’re in a pretty good place there and continuing to find the exact right place.

[00:36:18] Nathan Wrigley: It feels from the outside as if security’s fairly binary. On the one hand, adversary on the other hand, good guys. On the one hand hacked, on the other hand, not hacked. It’s black and white. But it seems from everything that you’ve been talking about today, that you are occupying a really grey area. You’re just trying to figure out what the path is forward. You’re constantly staring into the future trying to figure out what the adversaries are doing. Trying to patch, trying to make sure that everything is as good as it possibly can be. And I hadn’t really thought about it in that way. It’s not, there is no destination here where everything’s white. It’s a journey and every day’s going to be a bit grey. There’s going to be a bit of black and a bit of white, but a lot of grey in the middle.

[00:36:58] Aaron D Campbell: I don’t really look at it as grey, but I can see where you’re going there. But I think that there is this black and white, and then there’s sort of the cloudy. The further forward you look, the more difficult it is to know exactly where the black and white are always going to be. And some of that sort of comes across as grey. It’s a little blurry. You can’t quite figure it out.

But you’re right. there’s some prediction. There’s some, we think that moving this way is going to cause more white and less black. And that’s what we’re, that’s what we’re constantly aiming for. But you can’t just say turning right always makes things more white. Because sometimes there could be black over on that side somewhere, right? You’re really trying to be predictive, but not just randomly predictive, right?

Many of the people like myself that are trying to help guide this path forward, and even more than me, some of the people like Matt, who instituted that wait policy and some of the people that are running the WordPress Security Team, we have decades of experience watching this, that’s helping to inform our predictions. And so it’s not, we’re not just willy-nilly guessing. And I think that’s important to point out to the people that rely on us, to help guide them to the right space going forward.

[00:38:02] Nathan Wrigley: Yeah. Okay. So my schooling in chemistry was pretty basic, but I know that if I want to understand chemistry, my quickest way to do that is to rely on an expert, is to go and find a chemist who has years of experience. And, the same would be true here. I think most of us have probably not got the capacity to actually get a hold of what you’re saying. We, understand that your expertise is what we need to be listening to. But I’m just wondering for a typical WordPress user of whom many listen to this podcast, they have a WordPress site, but they’re not really interested in security, other than how it may impact their business.

So I’m going to ask for some very basic advice here. What would be the 1, 2, 3 things that somebody using WordPress with no security credentials whatsoever. What would be the few things that you would advise them to either go and read, or go and do, or go and think about?

[00:38:51] Aaron D Campbell: Yeah, so I think the biggest thing that I would encourage them to do, is essentially position themselves in such a way that they are relying on the experts, right? You’re not an expert and that’s okay. No one can be an expert in everything. But there are some things you can do to position yourself such that you’re benefiting from those experts.

One of those is updating as fast as possible. So WordPress auto updates turned on, those kinds of things. This WordPress Security Team that I’m talking about that has so much expertise in the area, and their whole focus is trying to make sure that WordPress is always secure. That lets you rely on them to help keep your site secure.

I think in similar ways, you want to find the right host that is also doing those security focused things for you, so that you don’t need to. And maybe that’s asking your host, what do you do to keep me safe? We talk about security, like the best security is layered security. It’s almost like having a gate at the complex, but also having a lock on your door, right? Those kinds of things. You can ask your host, what do you do to protect me in a layered way?

And maybe that question doesn’t make sense to you, and maybe even their answers don’t make sense to you, but if they have an answer, that’s good for you. It means that you can rely on their expertise.

And then stepping out of the obvious space to give a third thing that people should be doing. And this is, this may sound out in left field, but you should get some form of dark web monitoring for yourself, for your own credentials. And whether that’s going to someplace like, Have I Been Pwned, and looking at your own email address, and passwords and seeing if they’ve been in some breached data from somewhere, and are now being sold on the dark web. Or whether that’s using some service that offers it. I think that’s important, more so now than it’s ever been.

Because one of the other things that AI is doing that it’s particularly good at is collecting all this massive amount of breach data that’s happened over the last couple decades, that’s being sold on the dark web. Collating it all and saying, oh, we see that, gosh, 15 years ago, an account that Aaron had was in a breach. And we now know one of his passwords.

And granted it’s 15 years old, but it’s very easy for that AI to then say, where is Aaron now? What’s he doing? What can we learn about him? He works at Monarx. I wonder if this password works for his Monarx account. I wonder if this password works for the bank that he’s at. Or this other tool that we see that he uses. Let’s try all his social media accounts.

And so knowing whether that’s out there and being able to, you can’t get rid of that data, but being able to do things to protect yourself because you now know it’s out there is more important than it’s ever been.

[00:41:47] Nathan Wrigley: I hope you take this in the spirit in which it’s offered, but I really do wish to live in a world where you don’t have a job.

[00:41:55] Aaron D Campbell: Me too.

[00:41:56] Nathan Wrigley: But, am glad that we live in a world where you do, somebody like you does have a job. So I hope that landed correctly.

[00:42:02] Aaron D Campbell: If I could work to the point where I could work myself out of a job, I would find a new career and I would feel so accomplished, you couldn’t even imagine it. I’m okay with that.

[00:42:12] Nathan Wrigley: Yeah. Good. Aaron, just before we wrap up, is there a place where you hang out online where people could poll you if they’ve got a question, or any thoughts about what we’ve talked about?

[00:42:21] Aaron D Campbell: Yeah, if you’re looking for me professionally, you can find me Monarx.com, M-O-N-A-R-X.com. I also have aarondcampbell.com if you want some of my own more personal takes on security and things. And you can find me on Bluesky or the WordPress Slack. Those are probably the biggest places I’m at.

[00:42:40] Nathan Wrigley: What I will do, dear listener, into the show notes, if you go to wptavern.com and you search for the episode with Aaron Campbell, you’ll be able to find the links. I will dig out the Bluesky, and the various social links and the Monarx website and what have you, so you don’t have to hunt around too much. Go there wptavern.com. And Aaron, thank you so much for chatting to me today.

[00:43:01] Aaron D Campbell: Thank you. This was a really fun talk.

On the podcast today we have Aaron D Campbell.

Aaron is a seasoned veteran in both the internet and WordPress space, with over 25 years of experience spanning agency work, security products, hosting giants like GoDaddy and Newfold, and now his role at Monarx, a company focused on malware detection and remediation, particularly for web hosts. He’s led the WordPress Security Team, has been deeply involved in shaping security practices, and remains tightly connected to the WordPress ecosystem.

We talk about the rapidly changing landscape of WordPress security, specifically how the advent of AI has escalated the speed, scale, and complexity of attacks, moving the security game from a battle of wits, to a battle of compute power. Aaron discusses how attacks that once required human ingenuity are now orchestrated by AI agents capable of chaining vulnerabilities that humans would struggle to conceive.

We get into the shift from a reactive to a proactive security posture across the WordPress ecosystem. Aaron explains how both attackers and defenders are now deploying AI, leading to an arms race where AI is used to combat AI, and where collaboration among security teams is just as crucial as information-sharing among adversaries.

We chat about the motivators behind attacks, spoiler, it’s almost always about money, and the specific vulnerabilities WordPress faces as the most popular CMS on the web. Of interest is the narrowing window between when vulnerabilities are discovered and when they’re exploited, how supply chain attacks are on the rise, and what the WordPress “Protect the Shire” innovation means for plugin security.

Towards the end of the episode, we explored practical security advice for everyday WordPress users, with Aaron recommending actionable tips on updates, choosing security-minded hosts, and monitoring for compromised credentials.

If you’re concerned about how AI is reshaping the WordPress security landscape, and want to know how the community is responding, this episode is for you.

Useful links

Aaron’s website

Monarx website

Monarx and Patchstack’s State of WordPress Security In 2026

WordPress wp2shell Exploitation Grows as Public Exploit Fuels Mass Scanning

Protect The Shire

Have I Been Pwned

Aaron on Bluesky

💾

Additional Variation Images included in WooCommerce 11.1

Variation galleries were introduced in WooCommerce 10.9 as an opt-in feature and rolled out gradually. As per previous announcement, starting in WooCommerce 11.1, they will enabled for every store, and the experimental feature toggle is removed.

The functionality previously provided by the WooCommerce Additional Variation Images extension is now part of WooCommerce core. When a store updates to WooCommerce 11.1, the standalone extension is automatically deactivated to prevent conflicts. Existing variation galleries continue to appear through WooCommerce core.

Technical details

Core stores gallery attachment IDs in _product_image_gallery on the variation record—the same postmeta key used for galleries on parent products.

The wc/v3 product variation REST API exposes the gallery through the readable and writable gallery_image_ids property. This property contains gallery attachment IDs only; the variation’s featured image remains separate in image.

The former feature option, wc_feature_woocommerce_additional_variation_images_enabled, is removed during the WooCommerce 11.1 database update. Variation galleries are always enabled and no longer appear under WooCommerce > Settings > Advanced > Features.

Migrating from Additional Variation Images

If migration has not already completed, WooCommerce schedules an Action Scheduler job that copies data from _wc_additional_variation_images to _product_image_gallery. It processes up to 250 variations per run and requeues itself until no variations remain.

The migration is idempotent and does not overwrite a non-empty _product_image_gallery value. Legacy meta is preserved for backward compatibility, but it is not kept synchronized after core takes ownership of the gallery. We recommend testing the upgrade on a staging site, especially for stores with large variation catalogues or custom gallery integrations.

How can developers tell if they are affected?

You may be affected if your extension, theme, or custom code:

  • Uses the Additional Variation Images extension.
  • Reads or writes _wc_additional_variation_images or _product_image_gallery directly.
  • Checks wc_feature_woocommerce_additional_variation_images_enabled.

Stores without the extension or custom variation-gallery integrations do not need to take action.

What action do developers need to take if affected?

Remove any feature gates based on wc_feature_woocommerce_additional_variation_images_enabled, because WooCommerce 11.1 deletes this option.

Access variation galleries through WC_Product_Variation::get_gallery_image_ids() and set_gallery_image_ids(), or through gallery_image_ids in the wc/v3 product variation REST API.

Do not treat _wc_additional_variation_images as the current source of truth. Although its existing value is preserved, core edits are not written back to it, and subsequent writes to the legacy key may not affect the gallery displayed by WooCommerce.

Test custom storefront integrations when selecting, changing, and clearing variations, particularly when variations have different galleries or no gallery of their own.

The post Additional Variation Images included in WooCommerce 11.1 appeared first on The WooCommerce Developer Blog.

WooCommerce 11.1 release is delayed

Hi, folks.

Initially scheduled for Tuesday, September 1, 2026, we are tentatively postponing the release of WooCommerce 11.1.0 to Thursday, September 3, 2026.

Reason for delay

During early testing of WooCommerce 11.1.0 RC1, we identified certain issues around the mini cart, and highlighted some additional fixes .

We are preparing RC2 with a fix and will complete another round of pre-release validation before the stable release.

What happens next?

We plan to prepare RC2 and begin additional testing on September 2, 2026. If testing is successful, WooCommerce 11.1.0 will be released on Thursday, September 3, 2026. We will share any further changes to the release plan through this blog.

Thank you

Thank you for your patience and understanding as we work toward the WooCommerce 11.1 release.

The post WooCommerce 11.1 release is delayed appeared first on The WooCommerce Developer Blog.

WooCommerce 11.1 Delivers Faster REST and Store API Requests by Skipping Block Registration

Faster REST and Store API requests

WooCommerce block types and patterns were previously registered on nearly every request, including many that never render or edit blocks. We are changing that deliberately: a request should only pay for block registration when it can actually render or edit blocks.

The first step shipped in WooCommerce 11.0, where patterns register by file path and their content is loaded only when the editor requests it, matching WordPress core and saving 5–8 ms on every request that registers blocks .

WooCommerce 11.1 completes the change: a new BlockRegistrationContext guard now skips block and pattern registration on non-rendering requests. One exception is built in: when a product or variation description contains a WooCommerce block, block types are registered on demand via the woocommerce_short_description filter, so descriptions still render correctly in the products REST API, the Store API, the variation AJAX endpoint, and product webhooks.

Front-end, core admin, and block/site editor requests are unchanged, and the guard only skips contexts it recognizes; anything else keeps registering blocks, so a missed case costs a little performance, never a rendering regression.

The benefit: Store API and WooCommerce REST requests are 13–18 ms (30–42%) faster in our measurements.

How can developers tell if they are affected?

This applies from WooCommerce 11.1.0. You are affected only if your extension renders WooCommerce blocks, or relies on WooCommerce block types, patterns, or per-block assets being registered, during one of the skipped requests above. A WooCommerce block comes back as raw block markup (<!– wp:woocommerce/… –>) or as static HTML without its dynamic output which can be confirmed in code:

// Returns false in a skipped context on WooCommerce 11.1+.

WP_Block_Type_Registry::get_instance()->is_registered( 'woocommerce/mini-cart' );


Product and variation descriptions need no action; they are handled on demand. Blocks your extension registers itself with register_block_type() are also unaffected; so this only covers registration done by WooCommerce.

What action do developers need to take if affected?

Opt back in with the new woocommerce_should_register_blocks filter; return true only for the requests where you actually render blocks:

add_filter(

'woocommerce_should_register_blocks',

function ( $should_register ) {

	return my_context_renders_blocks() ? true : $should_register;

}

);

The filter runs on plugins_loaded, before the main query is parsed, so the condition can only rely on what’s available that early ($_SERVER, $_GET).

Please test your extension against WooCommerce 11.1 before the final release.

One more recommendation: don’t build your blocks on AbstractBlock. It’s an internal class, and blocks built on it inherit every registration decision WooCommerce makes, including the skips above; its lifecycle will keep changing as we optimize registration.

The supported way to create a block is the standard WordPress Block API: define it in block.json and register it with register_block_type() on init. Good starting points: Scaffolding and sample store data, @wordpress/create-block, and for Cart and Checkout inner blocks the @woocommerce/extend-cart-checkout-block template.

The post WooCommerce 11.1 Delivers Faster REST and Store API Requests by Skipping Block Registration appeared first on The WooCommerce Developer Blog.

Retiring stable feature flags in WooCommerce 11.1

Retiring stable WooCommerce Admin feature flags in WooCommerce 11.1

WooCommerce 11.1 retires a set of stable WooCommerce Admin feature flags from the normal feature configuration pipeline.

These features are no longer experimental or optional, so WooCommerce now loads them directly instead of treating entries in core.json, development.json, or window.wcAdminFeatures as the source of truth for whether the feature should be available.

This change should not remove functionality from stores. The affected features continue to be available. To preserve backward compatibility, WooCommerce 11.1 includes deprecated PHP and JavaScript compatibility shims for existing checks.

For example, calls such as:

Features::is_enabled( 'launch-your-store' );

Features::exists( 'customize-store' );

Direct JavaScript access such as:

window.wcAdminFeatures[ 'launch-your-store' ];

These will continue to return compatibility values for now. However, these checks are deprecated and will emit deprecation warnings. The compatibility layer is intended to give extension developers time to remove feature-flag-based gates before the shims are removed in a future WooCommerce version.

Who is affected?

This affects extensions and custom code that check retired WooCommerce Admin feature flags before loading UI, routes, tasks, recommendations, or other WooCommerce Admin behavior.

Developers should audit their code for usage of:

Features::is_enabled()

Features::exists()

Features::get_available_features()

Features::get_optional_feature_options()

Features::enable()

Features::disable()

window.wcAdminFeatures

– the woocommerce_admin_features filter when used to control stable WooCommerce Admin features

In most cases, checks for retired stable feature flags can be removed because the related feature is now treated as stable and available.

Affected feature flags

The retired compatibility shims include the following feature slugs:

activity-panels

analytics

analytics-scheduled-import

experimental-iapi-mini-cart

coupons

core-profiler

customize-store

customer-effort-score-tracks

import-products-task

experimental-fashion-sample-products

shipping-smart-defaults

shipping-setting-tour

homescreen

marketing

mobile-app-banner

onboarding

onboarding-tasks

pattern-toolkit-full-composability

payment-gateway-suggestions

product-custom-fields

printful

remote-inbox-notifications

remote-free-extensions

shipping-label-banner

subscriptions

transient-notices

wc-pay-promotion

wc-pay-welcome-page

woo-mobile-welcome

launch-your-store

Developers should use the underlying option or supported API when they need to check behavior that remains configurable.

About woocommerce_admin_features

The woocommerce_admin_features filter should no longer be used to control retired stable WooCommerce Admin features.

WooCommerce now loads these features directly, so removing a retired stable slug from the filtered feature list is not a supported way to disable the underlying feature behavior. Deprecated compatibility lookups may still reflect legacy filtered values while the shim exists, but those lookups now emit deprecation warnings and should be removed.

Extensions that currently use woocommerce_admin_features to gate stable WooCommerce Admin features should migrate away from that pattern and use the actual option or API for behavior that remains configurable.

Deprecated helpers

The following legacy helpers are also deprecated:

Features::get_optional_feature_options();

Features::enable();

Features::disable();

New code should avoid using WooCommerce Admin feature flags as extension points for stable feature behavior.

Timeline

These compatibility shims are deprecated in WooCommerce 11.1 and are planned for removal in a future WooCommerce version.

The post Retiring stable feature flags in WooCommerce 11.1 appeared first on The WooCommerce Developer Blog.

❌