WordPress 7.0 Block Checkout Changes: What Broke (and Didn’t) for Discount and Coupon Plugins

[Published: 2026-07-10]

WordPress 7.0 released on May 20, 2026. If you run a WooCommerce store and searched for what it means for you, you likely found — and should read first — the broader breakdown of what WordPress 7.0 actually changes for your store, which covers the new admin color scheme, AI Connectors, the Font Library, and the PHP 7.4 minimum. That post is the general map.

This post narrows to one question that general coverage tends to skip: if you run a discount campaign, a coupon code, or a BOGO deal on WooCommerce’s block-based cart and checkout, does WordPress 7.0 change anything about whether that discount still shows up correctly when a customer pays? The short answer is no — WordPress 7.0 itself doesn’t touch the mechanism that causes discount plugins to break on block checkout. But the risk that mechanism represents hasn’t gone away either, and a WordPress major-version update is exactly the moment worth using to check it.

The Question WordPress 7.0’s Release Notes Don’t Answer

WordPress’s own release notes for version 7.0 describe changes to WordPress core — the block editor, the admin interface, the new AI Connectors screen, performance work, and the PHP 7.4 minimum. None of that is about WooCommerce, and none of it is written with a store owner’s checkout flow in mind. That’s not a criticism of the release notes; WordPress core doesn’t know what plugins you run.

The gap this creates is real. A store owner running a BOGO campaign, a tiered-pricing setup, or a bundle of unique coupon codes reads “WordPress 7.0 is out,” updates, and is left wondering whether that update touched anything about how their checkout actually calculates a price. The honest answer requires separating two different systems that get talked about as if they’re one thing: WordPress core (what actually changed in 7.0) and WooCommerce’s block-based cart and checkout (a WooCommerce feature that has its own separate compatibility story, unrelated to any specific WordPress version).

What WordPress 7.0 Actually Touches — and What It Doesn’t

WordPress 7.0’s confirmed changes are a new “Modern” admin color scheme, the AI Connectors settings screen, Visual Revisions for post/page history, Font Library support on classic themes, per-block responsive visibility controls, page-load performance improvements (image loading priority, script module dependencies, on-demand block stylesheet loading), and a PHP 7.4 minimum requirement. All of that is documented in the general overview linked above, and none of it is a change to WooCommerce’s checkout rendering pipeline.

That distinction matters because WooCommerce’s Cart Block and Checkout Block are WooCommerce’s own components, built and maintained on WooCommerce’s release cycle — not WordPress’s. They were introduced starting with WooCommerce 8.3 and made the default for new installs. A WordPress core release doesn’t rewrite them. WordPress 7.0 shipping doesn’t mean the block cart or checkout works any differently today than it did the week before the update.

A Quick Recap: Why Block Checkout Breaks Certain Discount Plugins

This mechanism is not new, and it isn’t something WordPress 7.0 introduced — it’s worth restating briefly here because it’s the actual source of risk that store owners conflate with “the WordPress update.” The full breakdown, including how to test for it and the architectural fix, lives in why your WooCommerce discount plugin broke after you switched to block checkout.

The short version: WooCommerce’s classic cart and checkout render through PHP templates, and many discount plugins hook into that rendering pipeline — woocommerce_cart_calculate_fees, woocommerce_before_calculate_totals, and similar PHP action/filter hooks — to inject a discounted price at calculation time. The block-based Cart Block and Checkout Block don’t go through that PHP template pipeline at all. They’re React components that read cart and pricing data through WooCommerce’s Store API. A plugin that only knows how to modify prices through the classic PHP hooks can end up invisible to the block cart, even though the discount logic is technically still running.

The result, when it happens, is quiet. The product page shows the discounted price correctly (product pages still render through PHP). The block cart or checkout shows the original price. No error message appears. The first person to notice is usually a customer, mid-checkout, wondering why the price doesn’t match what the product page promised.

Does WordPress 7.0 Change That Risk at All?

No — and this is the direct answer this post exists to give. WordPress 7.0 does not alter the Store API, does not change how the Cart Block or Checkout Block fetch pricing data, and does not modify the classic PHP cart hooks that some discount plugins rely on. The block checkout compatibility gap described above existed before WordPress 7.0 and is unaffected by it in either direction — WordPress 7.0 neither introduces a new version of this problem nor resolves an old one.

What a WordPress major-version update does do, practically, is give store owners a reason to open their admin, look at plugin update notices, and think about their stack as a whole. That’s a genuinely useful moment to re-run a block checkout discount test even though the WordPress update itself isn’t the cause of any risk you’d find. If you haven’t checked whether your discount plugin’s prices survive into the block cart since you last changed anything about your checkout pages, updating to WordPress 7.0 is as good a trigger as any to do it now rather than during your next sale.

How to Check Your Own Discount or Coupon Plugin Right Now

Three checks, in order of speed:

If the product page shows the discount but the cart or checkout doesn’t, you’ve found the exact symptom described above, and the plugin’s underlying architecture — not WordPress 7.0 — is the thing to investigate.

Where Smart Cycle Discounts and TrustLens Actually Stand

Since this is a Webstepper-published post, it’s worth being precise rather than promotional about our own plugins’ status, using the same standard applied to any compatibility claim: what the readme actually says, checked at the time of writing.

Smart Cycle Discounts, as of version 2.1.11, lists Requires at least: 6.4, Tested up to: 7.0, WC requires at least: 8.0, and WC tested up to: 9.5 in its current WordPress.org readme.txt. In plain terms: the developer has explicitly tested and confirmed this plugin against WordPress 7.0 as of this writing — this isn’t an inferred or hoped-for compatibility, it’s the stated tested-up-to version. On the block checkout question specifically, Smart Cycle Discounts applies discounts through WooCommerce’s price and cart-calculation hooks and exposes the adjusted cart prices to the block cart and checkout through a WooCommerce Store API extension, which is the architectural approach described above as the one that survives the move to blocks. The plugin’s readme FAQ states it directly: “Smart Cycle Discounts fully supports WooCommerce block cart and checkout pages (WooCommerce 8.3+). Discounted prices display correctly with strikethrough formatting in both classic templates and the new block-based cart/checkout.”

TrustLens, as of version 1.3.8, lists Requires at least: 6.4 and Tested up to: 7.0 in its current WordPress.org readme.txt as well. TrustLens doesn’t apply discounts or touch cart pricing at all — it’s a fraud-detection and trust-scoring plugin that reads order and customer data — so the block checkout pricing-hook issue described in this post isn’t something TrustLens is exposed to in the first place. Its own compatibility work is concentrated on order data storage (it declares WooCommerce HPOS compatibility) and on checkout-blocking enforcement, which its readme states covers “Classic + Blocks.”

Both figures come directly from each plugin’s current readme.txt as published to WordPress.org at the time this post was written. Plugin versions and tested-up-to fields change over time — if you’re reading this well after July 2026, check the current readme rather than taking this snapshot as permanent.

Coupons and Campaign Discounts Don’t Carry the Same Risk

It’s worth separating two things that get lumped together under “discounts” in this conversation, because they carry genuinely different levels of block checkout risk.

WooCommerce’s native coupon system — the coupon code field a customer types in at checkout — is built directly into the Checkout Block itself and has been fully supported since block checkout was introduced. Coupons apply through WooCommerce’s core coupon handling, a different layer entirely from the third-party PHP cart hooks that cause the campaign-discount breakage described above. If your only concern is whether coupon codes work on block checkout, they do, and neither WordPress 7.0 nor any other recent update changes that. If a code still won’t apply, the cause is somewhere other than block checkout — the guide on why a WooCommerce coupon code isn’t working walks through the 12 usual reasons.

Campaign-style discounts — automatic percentage-off sales, BOGO deals, tiered pricing, spend thresholds — are where the risk actually lives, because these are the discount types typically handled by a third-party plugin rather than WooCommerce core, and third-party plugins vary widely in whether they’ve done the Store API integration work needed for block checkout. This is the same distinction covered in more depth in the coupons vs. campaign discounts comparison, which is useful background if you’re trying to decide which mechanism to use for a given promotion in the first place.

If you’re running both — coupon codes for one type of promotion, a plugin-driven campaign for another — it’s worth testing each independently rather than assuming that a working coupon field means your campaign discounts are also fine on block checkout. They’re unrelated systems from WooCommerce’s point of view, even though a customer sees them as “the discount” on the same order.

Frequently Asked Questions