Why Your WooCommerce Address Plugin Breaks on Checkout Blocks

In 2026, the single most common reason a WooCommerce address plugin stops working overnight is a WooCommerce update that switches the checkout to block-based rendering. Your plugin worked fine yesterday. Today, the address autocomplete is gone, postcode lookup does nothing, and orders are coming in with incomplete addresses. The root cause is almost always the same: your plugin was built to manipulate the DOM, and Checkout Blocks don't work that way.

This article explains exactly why that conflict happens, what breaks and why, and what a compatible plugin actually looks like under the hood.

Classic Checkout vs Block Checkout: What Changed

WooCommerce's classic checkout rendered a PHP template - a static HTML form that existed in the DOM as soon as the page loaded. Plugins could safely target that form using jQuery selectors: find the postcode field, attach an event listener, intercept the value, fire an API call, populate the address fields. This approach worked reliably for years.

WooCommerce Checkout Blocks replace that PHP template with a React application. The checkout form is rendered client-side by React, which manages its own internal state. Fields are React components, not static HTML inputs. React owns the DOM - it decides when to render, re-render, and update elements. Anything that reaches into that DOM from outside React is working against the rendering engine, not with it.

According to WooCommerce's own Checkout Blocks documentation, the block-based checkout is now the default for new WooCommerce installations, and it is architecturally separate from the classic shortcode checkout.

What Is DOM Manipulation and Why Does It Conflict With React?

DOM manipulation - as a technique - means directly reading and writing HTML elements using JavaScript. A classic address plugin might do something like this: wait for the page to load, find #billing_postcode using jQuery, attach a keyup listener, and on a valid postcode, write values directly into #billing_address_1, #billing_city, and so on.

That approach, while perfectly reasonable for static HTML, breaks in a React-rendered environment for two reasons. First, the fields may not exist in the DOM at the moment your plugin's JavaScript runs. React renders asynchronously - the checkout form might load several hundred milliseconds after your plugin's DOMContentLoaded hook fires. Second, and more critically, even if you successfully write a value into a React-controlled input, React doesn't know about it. React tracks field state internally. If you bypass that internal state and write directly to the DOM, React may overwrite your value on the next re-render cycle - which can happen immediately after a user interaction, a validation check, or a state update elsewhere in the checkout.

The result from the user's perspective: the address fields appear to populate, then clear themselves. Or the lookup fires but nothing happens. Or the plugin's UI renders in the wrong position because the DOM nodes it anchored to have been replaced by React. These are not bugs in the plugin's logic - they are symptoms of a fundamental architectural mismatch.

Why MutationObserver Workarounds Also Fail

Some plugins attempt to work around this by using a MutationObserver to watch for when React inserts the form fields, then attaching listeners once they appear. This is a fragile fix. React can replace DOM nodes during re-renders even when the visible output looks identical, which causes the observer's attached listeners to detach silently. The plugin appears to work in testing but fails intermittently in production - particularly after a user corrects a validation error or navigates back to the checkout.

What the WooCommerce Blocks Extensibility API Actually Provides

WooCommerce Blocks exposes a JavaScript extensibility API specifically designed for this problem. Rather than reaching into the DOM, plugins register themselves with the Blocks runtime using registerCheckoutFilters, ExperimentalOrderMeta, and similar hooks. The plugin's code runs inside React's rendering cycle, not outside it. State updates go through WooCommerce's internal store, so React knows about every change and re-renders correctly.

This is a meaningfully different integration model. It requires the plugin developer to write React-compatible code - not just JavaScript that runs on a page that happens to contain React. WooCommerce's extension compatibility documentation advises that extensions should declare compatibility with Cart and Checkout Blocks specifically, and its FAQ on extending Cart and Checkout Blocks warns that a plugin which touches checkout but hasn't added Blocks support will, in most cases, simply not appear - and in some cases can break the experience for the store.

Most UK address lookup plugins were written before Checkout Blocks existed. Retrofitting them to use the extensibility API is not a small change - it requires restructuring how the plugin initialises, how it reads and writes field values, and how it positions its UI components. Many plugin authors haven't done that work yet.

What Breaks in Practice When You Upgrade WooCommerce

When a store switches to Checkout Blocks - either by updating WooCommerce, installing a new theme that defaults to blocks, or manually enabling the block checkout - here is what typically breaks for a DOM-manipulation-based address plugin:

• The postcode lookup input renders but keypress events don't fire the API call
• Address suggestions appear in a dropdown but selecting one doesn't populate the checkout fields
• The plugin's UI element (dropdown, modal, or inline suggestions) renders in the wrong position or not at all
• Field values are populated by the plugin but immediately cleared by React's next render cycle
• The plugin throws JavaScript console errors referencing null DOM nodes

None of these failures produce a visible error to the customer. From their perspective, the address lookup simply doesn't work - so they type their address manually, often incompletely. According to Baymard Institute's cart abandonment research, checkout friction is a significant driver of abandonment. An address field that silently stops working is exactly that kind of friction - and it directly increases your failed delivery rate, as we cover in detail in our piece on the real cost of failed deliveries for UK WooCommerce stores.

How to Tell If Your Plugin Uses DOM Manipulation

You don't need to read the source code to diagnose this. Open your browser's developer tools, switch to the Console tab, and reload the checkout page. Look for errors referencing null or undefined on field selectors like #billing_postcode or .wc-block-components-text-input. If you see those, the plugin is trying to query DOM nodes that either don't exist yet or have been replaced by React.

You can also check the plugin's WordPress.org listing or changelog for any mention of "Checkout Blocks compatibility" or "WooCommerce Blocks support". If the plugin was last updated before WooCommerce 8.3 (released November 2023, when the Cart and Checkout blocks became the default for new installs) and the changelog makes no mention of blocks, assume it uses DOM manipulation.

Why Most Plugins Haven't Fixed This Yet

Rewriting a plugin to use the WooCommerce Blocks extensibility API is a significant investment. For small plugin teams or plugins that are secondary products for a larger company, it may not be commercially prioritised. The WordPress Interactivity API proposal signals that the ecosystem is moving firmly toward declarative, framework-aware interactivity - but legacy plugins built on jQuery and direct DOM access are not going to migrate themselves.

For a deeper look at how different UK address lookup plugins handle this problem - and which ones have actually done the work - see our UK address lookup API comparison and our dedicated guide on predictive address lookup for WooCommerce Checkout Blocks.

What a Blocks-Compatible Address Plugin Looks Like

SnapAddress was built with Checkout Blocks compatibility as a first-class requirement, not an afterthought. Our WooCommerce plugin integrates through the WooCommerce Blocks extensibility API - field values are written through WooCommerce's internal state management, not directly into DOM nodes. The lookup UI is positioned using block-aware rendering, so it doesn't detach or misplace itself when React re-renders the checkout.

It works with both classic checkout and block-based checkout out of the box. No configuration switches, no fallback modes to enable. The same plugin handles both checkout types, and it uses Royal Mail PAF data - the same dataset postal workers use - rather than Google Places, which frequently misses flat and unit-level address detail for UK properties.

Pricing is published transparently: credit packs from 2.5p per lookup, no subscription, no annual commitment. You can start with 100 free lookups and no card required.

If your address autocomplete stopped working after a WooCommerce update, get your free API key at SnapAddress and have it running in the time it would take to file a support ticket with your current provider.

Frequently Asked Questions

Why does my address plugin work on classic checkout but not on block checkout?

Classic checkout renders a static PHP template that exists in the DOM when the page loads. jQuery-based plugins can safely target those fields. Block checkout renders the form using React, which manages its own internal state. Plugins that write directly to DOM nodes bypass React's state management, causing values to be overwritten or events to go unfired. The fix requires integrating through the WooCommerce Blocks extensibility API rather than querying DOM elements directly.

Can I revert to classic checkout to make my existing plugin work again?

Yes - WooCommerce still supports the classic shortcode checkout, and you can revert by replacing the Checkout Block page with the [woocommerce_checkout] shortcode. But this is a workaround, not a fix. WooCommerce's development roadmap is moving toward block-based checkout as the standard, and reverting means you'll face the same problem again on the next major update. Switching to a Blocks-compatible plugin is the durable solution.

Does the WooCommerce Blocks extensibility API cover address field population?

Yes. The extensibility API provides hooks that allow plugins to read and write checkout field values through WooCommerce's internal store, which React renders from. This means address data set by a plugin persists through re-renders and validation cycles. It also allows plugins to register custom UI components - such as a postcode lookup dropdown - that render as part of the React component tree rather than being injected into the DOM from outside.