WooCommerce 11.1 brings back the admin menus you disabled

The menu you removed is back, and nothing errored

Somewhere in your theme or a small plugin there is probably a snippet like this, copied from a gist or a blog years ago:

add_filter( 'woocommerce_admin_features', function( $features ) {
	return array_values(
		array_filter( $features, function( $feature ) {
			return $feature !== 'marketing';
		} )
	);
} );

It still runs. It still returns a list without marketing in it. And since WooCommerce 11.1, the Marketing menu is in the sidebar anyway.

Nothing failed. No error, no warning in the admin, no line in the update notes that a shop owner reads. The filter you are calling still exists and is still applied. What changed is what WooCommerce does with the answer.

What WooCommerce says about the technique

The vendor published an advisory dated 31 August, before the release, and its wording is careful:

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.

• Retiring stable feature flags in WooCommerce 11.1, WooCommerce Developer Blog, 31 August 2026

"Not a supported way to disable" is a claim about support, not about outcome. The same post is reassuring about what stores will notice:

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.

• same advisory, WooCommerce Developer Blog

Both statements are true and neither one tells the shop owner the thing they need to know, which is that a menu they deliberately removed is coming back. Thirty feature slugs are on the retired list, including marketing, homescreen, analytics, coupons, onboarding, wc-pay-promotion and wc-pay-welcome-page.

Nothing is deleted in this release. In the shipped code every one of those thirty entries carries a removal version of null: the shims are deprecated, with removal promised for an unnamed future version.

Why does the filter still run but stop working?

Because the gate it fed was moved, not the filter itself. This is visible in the release source.

In WooCommerce 11.0, the loader walked the filtered list and instantiated a class only if its slug survived. Remove marketing from the array and the Marketing class was never constructed, so its menu item never registered. That is why the snippet worked for years.

In 11.1, the loader instantiates a fixed set of sixteen classes unconditionally, before it walks the filtered list at all. Marketing and the home screen are in that set. The filtered loop then skips whatever is already loaded.

The Marketing class itself did not change: its constructor is identical between the two versions, and its only guard has always been a check that it is running in the admin. It never read the feature flag. The flag was enforced by whoever decided to construct it, and that decision no longer consults your filter.

There is a second, blunter piece of evidence in the same release. The Coupons class used to begin by checking the marketing flag and returning early if it was off. In 11.1 those five lines are deleted. One class stopped constructing itself when the flag was absent; another stopped reading the flag at all.

Worth saying what is not affected, because the snippet in circulation also targets the WooPayments promotions: those two classes register no hooks in either version, so instantiating them changes nothing either way.

What the snippet does now, slug by slug

Read from the 11.1 source, and worth checking against your own admin:

Except Analytics, which still obeys the filter

Here is the part that makes this hard to diagnose. One slug was given an explicit exception. In 11.1 the features controller special-cases analytics: if the legacy filter excludes it, the feature reports as disabled, and the Analytics class returns early exactly as before.

That exception is not a last-minute patch: it landed in July, in a single pull request that added both the check and its tests, and was refined again at the start of September.

So the same snippet now produces different outcomes for different slugs. Analytics stays hidden. Marketing and the home screen come back. A shop owner looking at their sidebar sees some of their customisations holding and others silently undone, which reads as "something is a bit broken" rather than as one identifiable change.

What does a shop owner see in the update notes?

Nothing about any of this. The changelog that renders in the WordPress update screen is 351 lines for 11.1.0, and the filter name does not appear in it once. What does appear reads like reassurance:

Update - Keep stable WooCommerce Admin shell features enabled without legacy feature flags.

Update - Keep WooCommerce Admin commerce recommendations enabled without legacy feature flags.

• readme.txt at tag 11.1.0, woocommerce/woocommerce, read 6 September 2026

"Keep enabled" is accurate from the vendor's side and precisely backwards from the shop's side, because keeping those features enabled is the thing the shop asked not to happen. The warning that explains it lives on the developer blog, in a post categorised as an advisory, dated 31 August. The earlier what-is-coming post for 11.1 covers the block registration change and says nothing about the retired flags or about the filter.

This is the recurring shape of a WooCommerce upgrade: the advisory goes out on a developer blog, and the sidebar changes on a shop that never read it.

The dates are worth writing down, because they do not line up, and one of them disagrees with itself. The advisory is dated 31 August. The release notes were published on 3 September and carry the line "Released: September 1, 2026" inside them. The git tag, the GitHub release and the WordPress.org plugin listing all put 11.1.0 on 3 September, and the WordPress.org listing is the one that matters, because that is what automatic updates read. So if you are trying to match "the day my sidebar changed" against "the day WooCommerce announced this", the honest answer is that the announcement came first and the release date depends on which vendor page you believe.

The new stream of deprecation notices

If your shop or your staging site runs with WordPress debugging on, expect more log lines from 11.1. The compatibility shims emit a deprecation warning on every lookup, naming the flag and saying the shim will be removed in a future version.

That is noise on a live site and a genuine signal on staging: each warning points at a piece of code still gating behaviour on a retired flag, which is exactly the list of things to migrate before the shims go.

The other two changes in 11.1 worth knowing

Block registration is skipped on requests that cannot render blocks. The release notes say WooCommerce no longer registers block types and patterns on Store API and REST requests, which makes them 30 to 42 per cent faster, and that extensions rendering blocks in those contexts should opt back in with a new filter. Before assuming this one is your problem: the same release also registers block types on demand when a product or variation description is rendered, which covers the most common shop-visible case. If blocks in a product description come back as raw markup somewhere, this is the area, and the opt-in filter is woocommerce_should_register_blocks.

Order item deletion changed, but the big change was earlier. The 11.1 notes describe recording which item IDs existed when removal was requested, so replacement items added by an extension before save are not deleted by accident. Worth being precise, because the version matters if you are debugging: deferred deletion itself, and the hook timing shift that came with it, shipped in 11.0. Version 11.1 refines which IDs get deleted and adds a synchronous fallback for custom order data stores. If an extension of yours implements a custom data store, that is the paragraph to read.

What to do about the menus

1. Find the snippet. Search your theme's functions file, any site-specific plugin, and any code snippets plugin for woocommerce_admin_features. It is usually one filter, added long ago, by somebody who has moved on.
2. List which slugs it removes. That tells you what to expect: analytics still disappears in 11.1, the rest of the retired list does not.
3. Check the sidebar on your own 11.1 shop before deciding anything. This article is read from the release source; your shop is the authority on your shop.
4. Move each gate to the real setting where one exists. WooCommerce's guidance is to use "the actual option or API for behavior that remains configurable" rather than the filter. For menu clutter with no setting behind it, hiding the menu item is a different technique from disabling the feature, and it is the one that survives this change.
5. Do not leave it on the deprecated shims. They emit warnings now and are scheduled for removal in an unnamed future version, which means this decision comes back later at a worse moment if you skip it.
6. If you maintain or commission extensions, audit them for checks on the thirty retired flags, and for block rendering in REST or Store API requests.
7. Watch the debug log after upgrading, on staging, with debugging on. The new deprecation warnings are a free inventory of what still needs migrating.

When this is a job to hand over

Deleting a stale snippet and hiding a menu item properly is an hour of work, and if you can find the snippet, do it yourself.

It becomes a job when nobody knows where the snippet lives, when the shop has a dozen of these accumulated from three different developers, or when the admin started behaving differently after an update and the question is which of forty plugins changed. Each of those is a scoped job with the price known in advance, which is what Fix S and Fix M are, and the website work we take is largely this: a shop that upgraded itself into a different configuration than the one it had.

Two related pieces if you are auditing a shop after an upgrade: what WooCommerce 11.0 changed about failed orders and stock, and why the update arrived when it did if you did not choose the moment. The same week brought the same shape somewhere else: Google migrating live campaigns in place, announced to developers and applied to whoever pays.

Sources

• Retiring stable feature flags in WooCommerce 11.1 - WooCommerce Developer Blog, 31 August 2026, read 6 September 2026. The filter described as not a supported way to disable retired features, the full list of retired slugs, the deprecated compatibility shims and their planned removal, and the statement that functionality is not removed from stores.
• WooCommerce 11.1 release notes - WooCommerce Developer Blog, 3 September 2026, read 6 September 2026. The three developer-facing changes: retired admin feature flags, block registration skipped on non-rendering requests, and the change to order item deletion.
• WooCommerce 11.1: What's coming for developers - WooCommerce Developer Blog, 18 August 2026, read 6 September 2026. The pre-release summary, which covers block registration and does not raise the retired feature flags.
• Block registration skips non-rendering requests - WooCommerce Developer Blog, 31 August 2026, read 6 September 2026. Which request types skip registration, the self-check for whether a block type is registered, and the opt-in filter.
• Changes to order item deletion - WooCommerce Developer Blog, 31 August 2026, read 6 September 2026. Recording item IDs at removal time, and the guidance for custom order data stores.
• woocommerce/woocommerce - WooCommerce source at tags 11.0.0 and 11.1.0, read 6 September 2026. The unconditionally loaded feature classes in 11.1 against the filtered loader in 11.0, the unchanged Marketing constructor, the analytics exception in the features controller, the thirty retired entries with no removal version, the deprecation warning helper, the deferred deletion already present in 11.0, and the 11.1.0 changelog in readme.txt.
• A widely copied public gist, read 6 September 2026 - the canonical version of the snippet in circulation, including the slugs it suggests targeting; given without a link or author.