If your WooCommerce Shop page suddenly changed layout, lost a filter, stopped using its custom template or started returning a 404 after updating to WooCommerce 11.0, there is a fairly important change worth knowing about.
WooCommerce changed the way WordPress sees the main Shop page.
WooCommerce did this deliberately. It wasn’t an accidental change.
The problem is that themes, page builders, plugins and custom code may have been relying on the old behaviour for years without anybody really noticing.
Then WooCommerce 11.0 lands and suddenly the Shop page stops using the right template, a filter disappears or something starts returning a 404.
That doesn’t mean every Shop page problem after WooCommerce 11.0 has the same cause either.
There have been compatibility problems in themes, plugins and custom code, and some failures have initially looked like WooCommerce bugs.
The important bit is working out which one you’re dealing with before you start changing things.
What changed in WooCommerce 11.0?
This gets a little technical, but the actual change isn’t too difficult to understand.
WordPress has a function called:
get_queried_object()
It tells code what the current request is actually about.
On a normal WordPress page, that would usually be the WP_Post object for that page.
On a category archive, it would normally be the term being viewed.
WooCommerce’s main Shop page was different.
Before WooCommerce 11.0, calling get_queried_object() on the Shop page returned the WP_Post_Type object for products rather than the actual WordPress page assigned as the Shop page.
WooCommerce 11.0 changed that.
The Shop page now returns the actual WP_Post for the page you’ve assigned as the WooCommerce Shop page.
So if your Shop page is WordPress page ID 123, code asking for the queried object now gets that page.
That brings WooCommerce much closer to normal WordPress behaviour.
Why can that break the Shop page?
Because some code was written around the old WooCommerce behaviour.
A theme, builder or plugin might have been doing something like:
$object = get_queried_object();
and then assuming $object was the products WP_Post_Type whenever it was running on the main Shop archive.
After WooCommerce 11.0, that assumption isn’t true anymore.
The object is now the actual Shop page.
The same change can affect code using:
get_queried_object()
get_queried_object_id()
$wp_query->queried_object
or:
$wp_query->queried_object_id
That doesn’t automatically mean the theme or plugin was badly built either.
WooCommerce worked this way for a long time, so plenty of code was written around it.
The behaviour changed. Anything depending on the old behaviour now needs to cope with the new one.
Why can product categories still work?
This is one of the more useful clues.
WooCommerce didn’t make the same change to product category pages.
A product category still gives code the WP_Term for that category.
The same sort of thing applies to product tags, brands and attributes.
So you can end up with:
- Shop page: broken
- Product category: working
- Individual product: working
From the front of the site that can look strange.
The Shop page is broken, but click into a product category and everything suddenly works again.
Behind the scenes they are different requests, and WooCommerce 11.0 only changed the queried object for the main Shop page.
So I wouldn’t immediately start rebuilding the Shop page just because the category pages still look normal.
Divi was one real example
This wasn’t just something WooCommerce warned developers might happen.
After WooCommerce 11.0 was released, Divi users reported Theme Builder templates no longer being applied to the main Shop page.
The same sort of template could still work on product category pages.
Rolling WooCommerce back to 10.9 made the Shop template work again.
Divi later released version 4.27.8 with a specific fix for WooCommerce 11.0 Shop templates.
That’s the useful bit here.
Rolling WooCommerce back made the problem disappear, but it wasn’t really the fix.
Divi needed to support the new WooCommerce behaviour. Once it did, the Shop template worked again.
Filters have been affected too
It isn’t only page builders.
Filter Everything users also reported filters disappearing from the main Shop page after moving from WooCommerce 10.9.4 to 11.0.
The same filters continued to work on product category pages.
The plugin later released an update fixing its WooCommerce 11 compatibility problem.
This is where you can easily end up looking in the wrong place.
You could spend ages changing the Shop page, rebuilding sidebars or saving the same plugin settings over and over when the actual problem is compatibility with WooCommerce 11.
If the plugin has already released a compatibility update, that’s where I’d start.
Using the Shop page as the homepage can cause something different
There is an even stranger example if the WooCommerce Shop page is also set as the site’s static homepage.
A problem reported with the HUSKY/WOOF product filter caused some SEO-friendly filter URLs to redirect back to the homepage after WooCommerce 11.0, dropping the selected filters.
The change itself wasn’t really about product filters.
WooCommerce was now correctly identifying the assigned Shop page as the queried WordPress page.
That meant WordPress’s normal canonical handling could recognise it as the front page in a situation where it hadn’t before.
The filter plugin eventually added its own compatibility fix.
The filter looked broken, but the change that caused it had nothing to do with the filter itself.
That’s why I wouldn’t diagnose these problems from the front-end symptom alone.
What if the Shop page is returning a 404?
This is where I wouldn’t assume everything comes back to a theme or plugin.
There was also a WooCommerce report where the assigned Shop page started returning a 404 after updating to WooCommerce 11.0, then worked again after reverting to 10.9.4.
The reporter initially went quite a bit further than simply turning one or two plugins off.
They reproduced the problem with third-party plugins disabled and a default WordPress theme, while individual products and product categories continued to work.
They also ruled out things like the Shop page assignment, permalinks and caching.
WooCommerce issue #67509 was labelled as a confirmed bug while it was being investigated.
The later follow-up changed the diagnosis. The reporter traced the 404 to custom stock-sorting code that wasn’t limited to the main query. WooCommerce closed the issue because there was nothing actionable in core at that point.
So I wouldn’t put every broken Shop page after WooCommerce 11 into the same box.
Sometimes a theme or plugin hasn’t caught up with the new behaviour.
Sometimes the WooCommerce change exposes a problem in custom query code that had stayed hidden before.
You need to know which one you’ve actually got.
What I’d check before changing anything
If the Shop page broke straight after moving to WooCommerce 11.0, I’d first work out exactly what broke.
- Is it returning a real 404?
- Is the page loading but using the wrong template?
- Are the products still there but a filter or sidebar has disappeared?
- Do product categories still use the correct layout?
- Is WooCommerce still pointing at the correct Shop page?
- Does
is_shop()still recognise the page?
Once I knew what had actually stopped working, I’d check whatever controls that part of the Shop page.
That might be the theme, a page builder, a filter plugin or some custom code.
I’d also check whether that theme or plugin has released a WooCommerce 11 compatibility update.
Divi and Filter Everything are good examples of why.
The WooCommerce update exposed the problem, but the lasting fix came from updating the component that relied on the old behaviour.
I wouldn’t edit WooCommerce core to fix it
You may come across fixes telling you to change something inside:
woocommerce/includes/class-wc-query.php
That can be useful as a test on staging.
If temporarily removing or changing something there makes the problem disappear, you’ve learned something useful.
I wouldn’t leave a live shop running like that.
The next WooCommerce update can overwrite your change, and you’re modifying plugin core code that the rest of WooCommerce expects to work a certain way.
Just because a change proves what caused the problem doesn’t mean I’d leave that change on the live site.
What about rolling WooCommerce back?
A rollback can also be useful for diagnosis.
If WooCommerce 10.9.4 works and WooCommerce 11.0.x breaks with everything else left alone, that tells you the WooCommerce update is involved.
It still doesn’t tell you whether WooCommerce itself is broken or whether something else on the site can’t handle the new behaviour.
That’s the next thing I’d want to find out.
If the problem belongs to a theme or plugin, I’d rather update or fix that component.
If it turns out to be a genuine WooCommerce bug, a temporary rollback may be reasonable while you’re waiting for a fix.
That’s very different from rolling WooCommerce back, seeing the Shop page come back, and deciding to leave it there.
You’re then keeping WooCommerce behind without actually fixing what caused the problem.
What should developers change?
If your own code really needs the product WP_Post_Type object, don’t use the Shop page’s queried object as a shortcut anymore.
Ask WordPress for the product post type directly:
$product_post_type = get_post_type_object( 'product' );
if ( $product_post_type instanceof WP_Post_Type ) {
// Work with the product post type object here.
}That’s the approach WooCommerce recommends.
If you’re only trying to find out whether you’re on the main Shop page, WooCommerce hasn’t changed that part.
is_shop(), is_archive() and is_post_type_archive( 'product' ) still work as before.
So I wouldn’t start replacing perfectly good is_shop() checks.
The change is specifically about what WooCommerce now returns as the queried object for the Shop page.
“WooCommerce 11 broke my Shop page” is only the start
The main thing is not to assume every Shop-page problem after WooCommerce 11.0 has the same cause.
If the template disappears, I’d look closely at the theme or builder.
If a filter disappears, I’d look at the filter plugin and how it works with the Shop archive.
If the page is returning a real 404, I’d check custom query code as well as WooCommerce. Issue #67509 looked like a core bug at first, but the later investigation pointed to a stock-sorting filter interfering with another query after the queried-object change.
And if changing the Shop page assignment or rolling WooCommerce back suddenly makes everything work, that still doesn’t tell you you’ve fixed it.
You’ve found a clue.
“WooCommerce 11 broke my Shop page” is only the start of the diagnosis.
Before changing anything, I’d want to know what part of the page has actually stopped working and which piece of the site was responsible for that part.
That’s a lot safer than rebuilding the Shop page, adding random snippets or permanently rolling WooCommerce back.
Frequently asked questions
Why does my WooCommerce Shop page break but product categories still work?
The main Shop page and product category pages don’t use exactly the same query context.
WooCommerce 11.0 changed the queried object for the main Shop page. Product taxonomy pages still return their normal term objects.
That means code affected by the Shop-page change can break there while continuing to work normally on categories.
Should I change the assigned WooCommerce Shop page?
Not as my first fix.
Changing the assigned page can change how the request is handled and may make the symptom disappear.
I’d still want to know why the original setup stopped working.
Otherwise you’ve changed the setup without really fixing the compatibility problem.
Should I downgrade WooCommerce?
Possibly as a temporary troubleshooting step.
It can be useful for proving that the WooCommerce update is involved, and a temporary rollback can make sense if you’re dealing with a confirmed core bug and need the shop working while a fix is prepared.
I wouldn’t treat an old WooCommerce version as the permanent answer without finding out what actually broke.
Do I need custom PHP?
Not necessarily.
If the problem comes from a theme, builder or plugin and there is already a WooCommerce 11 compatibility update available, I’d use that first.
Custom compatibility code makes more sense when you control the affected code yourself or you’ve identified a specific integration that genuinely needs changing.