Your shop ran out of memory four seconds after an update

What does this failure look like?

A shop owner wakes up to a white screen. The plugin files were rewritten overnight. Nothing else was touched. Nearly every request, front end and admin, returns a 500, and one line repeats in the error log more than a thousand times in a few hours: allowed memory size exhausted.

The instinct is to raise the memory limit. In this particular failure that is the one move that cannot work, and understanding why is the difference between a twenty-minute fix and a day of guessing.

What actually happened, with the times attached

One of the two reports is unusually precise, so it is worth reading as the vendor read it. The shop was on WooCommerce 11.0.1 the night before:

Plugin files rewritten at 2026-09-04 00:07:46 (auto-update to 11.1.0)

First fatal error 4 seconds later: PHP Fatal error: Allowed memory size of 268435456 bytes exhausted (tried to allocate 528384 bytes) in wp-includes/class-wp-hook.php on line 340

From then on, virtually every subsequent front-end and wp-admin request fatal errored (1,800+ occurrences in a few hours) [...]

• a store owner, 11.1.0 crashed my store, WordPress.org support forum, 4 September 2026

Four seconds between the files landing and the first fatal error. No deploy, no plugin installed, no theme edit. The owner's own summary of the update was "Last night 11.1.0 pushed automatically and crashed my website with error 500."

A second shop, a different owner, reported the same thing the next morning, on a server with a memory limit four times larger:

Confirming the same crash on a different site. Updating WooCommerce 11.0.1 → 11.1.0 immediately took the front end down with Allowed memory size of 1073741824 bytes exhausted on every request (1 GB limit). wp-admin stayed reachable. Rolling back to 11.0.1 fixed it with no other changes.

• another store owner, same thread, 5 September 2026

Why raising the memory limit does not help

Because nothing is asking for more memory. Something is asking forever.

The first owner tried the obvious thing and wrote down the result:

Raising WP_MEMORY_LIMIT from 256M → 512M did not resolve it - the site simply exhausted the new 512M ceiling too [...] pointing to unbounded/runaway memory growth rather than a legitimately higher peak requirement.

• the thread's author, same thread

That is the diagnostic, and it applies well beyond this one bug. A page that needs more memory than it used to will work at 512M and fail at 256M. A loop with no exit fails at every ceiling you give it, and each new ceiling costs you a longer wait before the error. If your shop dies at 256M, dies at 512M and dies at 1G, stop buying memory. You are not short of memory. You are in a loop.

So was it WooCommerce or was it the shop?

Both, and that is the useful part. The owner found it themselves and posted the answer four hours after opening the thread, describing the cycle in full:

The active child theme contained a global gettext filter that changed text on the WooCommerce My Account address endpoint [...] This worked with WooCommerce 11.0.1. Under 11.1.0, calling is_wc_endpoint_url() during early translation initialization produced this recursive path

• the thread's author, same thread, 4 September 2026

In plain terms: the theme had a snippet that rewrites one piece of wording on one WooCommerce page. To know which page it is on, the snippet asks WooCommerce. In the new version, that question ends up building WooCommerce's list of features, every label in that list is a translated string, and translating a string calls the snippet again. Round and round until PHP gives up.

WooCommerce support reproduced it on a clean install and confirmed the mechanism, including the detail that explains why the loop never breaks:

11.1.0 adds an Order Withdrawal controller that registers a woocommerce_get_query_vars filter unconditionally, and its callback runs a feature check every time that filter is applied, even when the feature is switched off. That check builds WooCommerce's full feature-definitions array, and every label in that array is a translated string. So it calls __(), which fires gettext, which re-enters your callback.

• a responder carrying the Plugin Support label, same thread, 5 September 2026

The reason it never terminates is the shape of the re-entry guard. get_feature_definitions() checks empty( $this->features ) before initialising, but $this->features is not populated until the very last step of the initialiser. While the array is being built the guard still reads "empty", so every re-entry starts the build over again.

• same reply

And the measurement, which is the part worth keeping:

On a clean WordPress 7.1 / PHP 8.4 site with a 512M limit and a gettext filter matching yours: WooCommerce 11.1.0: recursion reached a depth of 37,774 before PHP died [...] WooCommerce 11.0.1 with the identical filter: depth 1, page loads normally, no errors.

• same reply

One test site, one filter of that shape, one memory limit. On 11.0.1 the recursion goes one level deep and the page loads. On 11.1.0 it goes 37,774 levels deep and PHP dies. Nothing on the affected shops changed, and the shops are still half the reason they broke.

Do you have the snippet that does this?

Look in your child theme's functions.php, and in any small "customisations" plugin, for a filter on gettext that asks a question about the current page. The shape is a translation tweak scoped to one WooCommerce screen, and the tell is one of is_wc_endpoint_url(), is_cart() or is_checkout() sitting inside it.

WooCommerce's own advice, from the same reply, is broader than this one bug:

More generally, it is worth avoiding any query-dependent conditional (is_wc_endpoint_url(), is_cart(), is_checkout()) inside a gettext callback, since translation can be triggered at any point in a request, including well before the main query exists. Scoping to template_redirect or later achieves the same thing.

• the same Plugin Support responder, same thread

The fix both owners applied was a guard that makes the snippet do nothing until WordPress has actually worked out what page this is:

add_filter( 'gettext', function ( $translated, $text, $domain ) {
    if (
        is_admin()
        || ! did_action( 'wp' )
        || ! function_exists( 'is_wc_endpoint_url' )
        || ! is_wc_endpoint_url( 'edit-address' )
    ) {
        return $translated;
    }
    // Translation customization...
}, 20, 3 );

That is the published version of the workaround, from the owner who wrote it, and after applying it they installed 11.1.0 successfully. Two things to notice before copying it: the endpoint name in the last check is theirs, not yours, and the guard that matters is ! did_action( 'wp' ), which is what stops the callback running before the query exists.

If that snippet is in your theme and you cannot say who put it there or why, the question is no longer "how do I edit PHP". It is which of the things on this site are load-bearing, and that is a survey, not a patch.

Can you roll back? Usually, and here it was awkward

Rolling back the plugin fixed both shops with nothing else changed. One of the two published the command, and it is the WP-CLI one:

wp plugin install woocommerce --version=11.0.1 --force

WP-CLI documents both flags plainly: --version=<version> gets "that particular version from wordpress.org, instead of the stable version", and --force will "overwrite any installed version of the plugin, without prompting for confirmation".

The awkward part is specific to this bug and worth knowing, because it makes the obvious fix look broken. The loop happens while plugins load, which means it happens during WP-CLI commands too. WooCommerce's own ticket records it:

the bug kills every WP bootstrap, so wp option update and wp plugin install also OOM

• WooCommerce issue #68401, 5 September 2026

The way out is to run the command without loading plugins. The merchant reported that --skip-plugins avoided the crash, and WooCommerce support confirmed the same contrast, so that is the flag to have ready. In this case the plain command worked anyway and resolved the problem immediately, so try it first and keep the flag for when the shell dies too. If you have no SSH access at all, the documented alternative is WP Rollback, which adds a Rollback link next to each plugin, though its own page is blunt about testing on staging first and offers no guarantees.

Did the update really arrive on its own?

For this shop, yes, and the mechanism is documented, but the popular version of it is wrong. WordPress does not auto-update plugins by default. Since 5.5 it is opt-in, per plugin:

Since WordPress 5.5, websites Administrators can manually opt-in for automatic updates theme by theme and plugin by plugin.

• Plugin and themes auto-updates, WordPress documentation

So somebody switched it on. That somebody is often the owner, years ago, on the sensible theory that security updates should not wait for them. It is sometimes the host, which is the other side of the sentence in the same page about the feature being "partially or completely deactivated by your hosting company or by a plugin". Either way, once it is on, the schedule is not a negotiation:

By default WordPress runs auto-updates twice per day.

• same page

The numbers line up with that. WordPress.org lists 11.1.0 as published on the morning of 3 September. The shop's files were rewritten just after midnight local time on 4 September, roughly nineteen hours later, which is a cron pass or two. Nobody was awake for it. This is the same trade we wrote about when the delay is on the other side: turning auto-updates off buys you a review window and hands you the job of actually using it.

The documentation, to its credit, says the quiet part out loud:

Before enabling auto-updates on your plugins and themes, you may want to make sure you're able to rollback to a previous version of your website in case things go wrong.

• same page

How widespread is this?

Nobody knows, including WooCommerce, and its own ticket says so:

Confirmed count is small and honestly measured: 2 merchants + 1 lab reproduction. I did not attempt to size fleet exposure [...]

• WooCommerce issue #68401

Treat any article claiming thousands of broken shops, this one included, as invention. What is known is the shape: two shops, both with a snippet of the same kind, both taken down within seconds, both fixed by rolling back. For the exact pattern that was reproduced, a gettext filter calling is_wc_endpoint_url(), this is not a question of odds. It was reproduced on demand. The other conditionals WooCommerce warns about are advice rather than a demonstrated crash.

The ticket was open and assigned, with no comments on it, two days after it was filed. The public conversation about this bug happened on one support forum thread and then stopped.

What else broke after the update?

This is where the reporting around WooCommerce releases usually goes wrong, so here is the honest version. Five separate reports in the same fortnight, and they are not one story:

Three releases across two minor branches, five different symptoms, and two of the five threads end with nobody knowing anything at all. Only one reporter said the update arrived automatically. "WooCommerce 11.1 broke stores" is a headline that this evidence does not support. "Something in the 11.x series behaved differently on sites with existing customisations" does.

The cart one is worth a footnote because it looks the most alarming and is the least dangerous. The block was rendering the editor's sample cart on the front end whenever another plugin loaded the editor scripts there. The underlying API "returns the real cart the whole time", in the ticket's words, so what was wrong was the display, not the stored cart. It is the same class of problem as a page that looks clean while the thing behind it disagrees.

What to check on your own shop

1. Check whether auto-updates are on for WooCommerce. Plugins screen, the "Automatic update" column, which carries a link to enable or disable them per plugin. If that column is not there at all, the documentation's explanation is that the feature was deactivated by your host or by a plugin.
2. Search your child theme and any customisation plugin for gettext. Then look at what is inside those callbacks. Any WooCommerce conditional in there is the pattern described above.
3. If your site is down right now with repeated memory errors, do not raise the limit twice. Roll the plugin back to the previous version, get the site up, and diagnose afterwards.
4. Write down which version you were on before. That single fact turns a rollback into one command. Without it the first step of the recovery is archaeology.
5. Have a copy of the site you can break. Every piece of advice above is safe on a staging copy and consequential on a live shop.
6. Do not conclude your shop is fine because it loaded once. Two of these symptoms only show up on particular pages, and the admin side stayed reachable on one of the shops that was down.

When this is a job to hand over

Rolling back a plugin and adding one guard to a snippet is an hour, and if you have SSH and a staging site, do it yourself.

It becomes a job when the shop is down and the rollback fails too, when nobody knows what is in the child theme or who put it there, or when you are back on the old version and now have to decide how to move forward without living on it for a year. A shop that is down is not the moment to price by the hour, which is why we quote the fix and the deadline first and take website work on that basis.

One thing to do while this is fresh, whether or not it happened to you. Open the Plugins screen and decide, deliberately, which plugins are allowed to update themselves overnight. The release notes were about features, the failure was about a line in a theme nobody had reason to look at, and the two met at midnight because a switch somewhere was on. When the host says the server is fine, and it is, that switch is where the question starts.

Sources

• 11.1.0 crashed my store - WordPress.org support forum, 4-5 September 2026, read 7 September 2026. The timeline from automatic update to first fatal error, the memory limit raised without effect, the recursive path found by the reporter, the confirming report from a second shop on a 1 GB limit, the workaround snippet, and the Plugin Support reply with the reproduction and the recursion depths.
• WooCommerce issue #68401 - woocommerce/woocommerce on GitHub, opened 5 September 2026, read 7 September 2026. The unconditional filter registration, the shape of the re-entry guard, the note that the bug breaks the WordPress bootstrap including WP-CLI, the statement that 11.1.0 is the current stable release published on 3 September, and the honest count of confirmed cases.
• Cart block renders the preview cart on the frontend when any plugin loads wp-editor - woocommerce/woocommerce on GitHub, opened 6 September 2026, read 7 September 2026. The editor preview cart appearing on the front end, and the confirmation that the Store API returned the real cart throughout.
• Plugin and themes auto-updates - WordPress documentation, read 7 September 2026. Auto-updates as a per-plugin opt-in since WordPress 5.5, the twice-daily schedule, hosting companies being able to deactivate the controls, and the advice to be able to roll back before enabling them.
• wp plugin install - WP-CLI command reference, read 7 September 2026. The version and force flags used to reinstall a specific version of a plugin.
• WP Rollback - WordPress.org plugin directory, read 7 September 2026. Rolling a plugin back to a previous version from the admin, and the plugin's own insistence on testing and backups first.
• WooCommerce 11.1 release notes - WooCommerce Developer Blog, 3 September 2026, read 7 September 2026. The release notes for the version in question.
• Other reports read in full on the WordPress.org support forum, 7 September 2026: the cart block showing preview items, the blank shop archive, the missing attributes and variations, and the Payments screen error. The versions each reporter named, and how each thread ended.