You ran updates — WordPress, WooCommerce, and a handful of plugins. Everything looked fine. Then a customer emailed to say they couldn't complete their order. You tried the checkout yourself and got a blank screen, a spinning button that never resolves, or a white screen with no error message.
Plugin updates are by far the most common trigger for WooCommerce checkout failures. Not because updating is wrong — you should update — but because the WooCommerce ecosystem involves dozens of plugins that don't always test their updates against each other before releasing.
This guide covers every way a plugin update can break checkout, how to identify which plugin is responsible, and how to fix it without disrupting your live store.
Why plugin updates break checkout specifically
Checkout is the most complex page on a WooCommerce store. It involves JavaScript from multiple plugins running simultaneously, PHP hooks firing in a specific order, payment gateway scripts loading asynchronously, and — since WooCommerce 8.x — a choice between the classic shortcode checkout and the new block-based checkout.
Any plugin that touches JavaScript, payment processing, form fields, or the WooCommerce hook system can break checkout when updated — even if the plugin isn't obviously checkout-related. A caching plugin update that changes how assets are minified can break checkout JavaScript. A security plugin update that adds a new firewall rule can block payment gateway requests. A page builder update that changes how scripts load can conflict with WooCommerce's checkout scripts.
The four most common conflict types are:
JavaScript conflict
Two plugins load JavaScript that conflicts — one overrides a function the other depends on. The checkout form renders but interactivity breaks — buttons don't respond, fields don't validate, payment steps don't advance.
PHP hook conflict
A plugin adds, removes, or modifies a WooCommerce action or filter that checkout depends on. The page may not render at all, or render partially, or throw a fatal error that shows as a blank white screen.
Blocks vs Classic conflict
An updated plugin is incompatible with WooCommerce's block checkout but was written for the classic shortcode checkout. Common since WooCommerce 8.x switched blocks to the default. Particularly affects checkout field plugins.
PHP fatal error
The updated plugin contains a PHP error — calling a deprecated function, requiring a file that doesn't exist, or introducing a syntax error. WordPress catches it silently; checkout shows nothing or a generic error.
Step 1 — Establish what changed
Before touching anything, find out exactly which plugins were updated and when the checkout broke. This narrows the suspect list from every plugin on the site to two or three.
Check the WordPress update log
Go to Dashboard → Updates. WordPress records recent updates, but this view clears. A more reliable source is WooCommerce → Status → Logs — look for a log source called plugin-updates or check fatal-errors for the timestamp.
Check the PHP error log
Go to WooCommerce → Status → Environment and find the PHP error log path. Open the file via FTP or File Manager. Look for errors timestamped around when the checkout broke — a fatal error here often names the plugin responsible directly.
Check the browser console
Open your browser's developer tools (F12), go to the Console tab, and load the checkout page. JavaScript errors often name the script file causing the problem — which maps directly to a specific plugin. Look for red error messages, especially anything referencing wc- scripts.
Ask your hosting provider
If you have cPanel access, check Errors or Metrics → Errors for PHP errors in the server log. Your host may also be able to pull the error log for the specific time period when checkout broke.
Step 2 — The plugin conflict test
If the error log doesn't name a specific plugin, the next step is a systematic conflict test. The goal is to isolate which plugin is causing the problem by eliminating them one at a time.
The correct conflict test method
Switch to a default theme
Go to Appearance → Themes and activate Storefront or Twenty Twenty-Four. If checkout works with the default theme, your theme (or a theme update) is the culprit — not a plugin.
Deactivate all non-essential plugins
Go to Plugins → Installed Plugins. Deactivate every plugin except WooCommerce and your payment gateway. Test checkout. If it works, a deactivated plugin was the cause.
Reactivate one plugin at a time
Reactivate plugins one by one, testing checkout after each. When checkout breaks again, the last plugin you reactivated is the conflict. This is methodical but reliable.
Prioritise recently updated plugins
If you know which plugins were updated, start with those. Reactivate the updated plugins first — you'll likely find the culprit before having to test everything else.
Step 3 — The WooCommerce Blocks problem
Since WooCommerce 8.x, new stores default to the block-based checkout. Many plugins were written for the classic shortcode-based checkout and haven't been updated to support blocks. A plugin update can expose this incompatibility in a way that wasn't visible before.
How to tell if this is your problem
Go to Pages → Checkout in WordPress. Edit the page. If the checkout page contains the block labelled "Checkout" (with a block icon), you're using the new block checkout. If it contains the shortcode [woocommerce_checkout], you're using the classic checkout.
If you're on block checkout and a recently updated plugin is designed for classic checkout, you'll typically see one of these symptoms: checkout fields disappear, custom fields added by the plugin don't show, or the checkout page renders but functionality is broken.
Plugin adds custom fields via woocommerce_checkout_fields hook. Works reliably with classic checkout. Does nothing — or breaks things — on block checkout.
Custom fields must be added via the Checkout Extensibility API or __experimentalRegisterCheckoutFilters. Older plugins that hook the classic way are simply ignored or cause JS errors.
The fix options
Option A — Switch the incompatible plugin. Find an alternative that explicitly supports WooCommerce Blocks checkout. The plugin's description should state "compatible with WooCommerce Blocks" or "supports the new checkout block."
Option B — Revert to classic checkout. Replace the block checkout with the shortcode. Edit the checkout page, remove the Checkout block, and add a shortcode block containing [woocommerce_checkout]. This restores compatibility with older plugins immediately.
Option C — Wait for the plugin update. If the plugin is actively maintained, the developer will likely release a blocks-compatible version. Check their changelog and support forum.
Step 4 — Clear caching after every change
This catches more people than almost anything else. You deactivate the conflicting plugin, checkout works. You reactivate it, checkout breaks. You spend an hour testing — and the whole time, half your tests are seeing a cached version of the page rather than the current state.
After every plugin change during conflict testing, clear all caches:
- Your caching plugin — WP Rocket, W3 Total Cache, LiteSpeed Cache, WP Super Cache. Each has a "Clear All" or "Purge All" button in the admin bar or plugin settings.
- Your CDN — if you use Cloudflare, Bunny, or another CDN, purge the cache there too. Cloudflare has a "Purge Everything" button under Caching → Configuration.
- Your browser — hard refresh with Ctrl+Shift+R (Windows) or Cmd+Shift+R (Mac), or open an incognito window for each test.
- Object cache — if you have Redis or Memcached, flush it. In WP Rocket this is under Tools → Clear Cache. In LiteSpeed Cache it's under LSCache → Purge.
Step 5 — Rolling back a plugin update
Once you've identified the culprit, you have two options: fix the conflict or roll back the update. If you need the site working immediately, rolling back is faster.
Using WP Rollback
Install the free WP Rollback plugin. Once active, go to Plugins → Installed Plugins and you'll see a "Rollback" link under each plugin. Click it, choose the previous version, and confirm. The plugin downgrades instantly.
Manual rollback via FTP
Download the previous version of the plugin from the WordPress plugin directory (use the Advanced View on the plugin's page to access older versions). Delete the current plugin folder via FTP from /wp-content/plugins/ and upload the older version in its place.
Checkout down after WooCommerce update — checkout fields plugin incompatible with blocks
A UK fashion retailer contacted us after their checkout stopped loading completely following a WooCommerce update. The page returned a blank white screen. They'd already tried deactivating plugins one by one but couldn't isolate the cause.
→ All plugins deactivated checkout works ✓
→ Reactivating updated plugins one by one...
→ WooCommerce Custom Checkout Fields plugin reactivated
→ PHP Fatal: Call to undefined function wc_get_checkout_fields() in custom-checkout-fields/includes/class-fields.php
→ Root cause: plugin calling deprecated function removed in WooCommerce 9.0
The checkout fields plugin called a function that was deprecated in WooCommerce 8.x and removed entirely in 9.0. The plugin developer hadn't updated for compatibility. We switched the client to a blocks-compatible checkout fields alternative, migrated their custom field configuration, and verified full checkout functionality. The fix took under three hours.
The most common culprit plugin categories
Not all plugins are equally likely to break checkout when updated. Based on the failures we see most often, these categories carry the highest risk.
| Plugin category | Why it breaks checkout | What to check |
|---|---|---|
| Checkout field plugins | Hook into woocommerce_checkout_fields — incompatible with blocks checkout | Blocks compatibility, check plugin changelog for WC 8.x/9.x notes |
| Caching plugins | Updated minification/combination settings can break checkout JS | Disable JS/CSS minification, test checkout, re-enable selectively |
| Security plugins | New firewall rules can block payment gateway scripts or checkout AJAX | Check firewall logs, whitelist checkout AJAX URL |
| Page builders | Script loading order changes can conflict with WooCommerce checkout JS | Test with page builder scripts disabled on checkout page |
| Payment gateways | Updated gateway plugin may require new API keys or configuration | Check gateway settings in WooCommerce, test with other gateways disabled |
| WooCommerce extensions | Extension updated before it was compatible with latest WooCommerce core | Check extension developer's compatibility table, roll back if needed |
How to update safely — preventing this in future
Plugin updates breaking checkout is partly inevitable — incompatibilities happen. But the gap between "update broke checkout" and "update broke checkout and I didn't know for six hours" is almost entirely preventable.
Use a staging environment
Most hosts offer one-click staging. Apply all updates to staging first, test checkout, then push to live. This catches conflicts before customers encounter them. WP Engine, Kinsta, Cloudways, and most managed WordPress hosts include staging on every plan.
Update plugins one at a time
Updating five plugins simultaneously means you can't tell which one caused the conflict. Update one at a time, test checkout after each. More time-consuming but diagnostically much cleaner.
Set up uptime monitoring
Tools like UptimeRobot (free) or Better Uptime can monitor a checkout URL and alert you by email or SMS if it returns an error. Configure it to check your checkout page every five minutes. You'll know within minutes of a failure rather than hours.
Take a backup before updating
UpdraftPlus (free) or your host's built-in backup can restore a full site snapshot in minutes. Run a backup immediately before any update session. If something breaks badly, you restore rather than diagnose.
Check plugin compatibility before updating
Before updating WooCommerce itself, check your installed extensions against WooCommerce's compatibility database. WooCommerce publishes a list of extensions that have been tested against each major version. Extensions that haven't declared compatibility with the new version are higher risk.
Checkout still broken after working through this?
Some conflicts require direct server access to diagnose — PHP error logs, JS stack traces, and hook inspection that you can't do from the WordPress admin. We fix checkout conflicts daily. Same-day response, flat rate, no fix no fee.
Quick reference — checkout failures by symptom
| Symptom | Most likely cause | First fix to try |
|---|---|---|
| Blank white screen at checkout | PHP fatal error in a plugin | Check PHP error log, deactivate recently updated plugins |
| Place order button does nothing | JavaScript conflict | Check browser console for JS errors, test with caching disabled |
| Checkout fields missing or broken | Plugin incompatible with blocks checkout | Check if using block or classic checkout, test switching |
| Checkout spins but never completes | Payment gateway JS conflict or AJAX blocked | Check browser console, check security plugin firewall logs |
| Works on desktop, broken on mobile | JS conflict specific to mobile viewport | Test with page builder and caching minification disabled |
| Worked before update, broken after | Recently updated plugin conflict | Identify updated plugins, deactivate them, test, reactivate one by one |
| Checkout loads but payment step fails | Payment gateway plugin update broke gateway config | Check gateway settings in WooCommerce, verify API keys |
Summary
Plugin updates break WooCommerce checkout more often than any other single cause — and the failure is rarely obvious about which plugin is responsible. The systematic approach works: check the error log first, then conflict-test by deactivating plugins, starting with recently updated ones.
The WooCommerce Blocks vs Classic checkout split adds a layer of complexity that's caught many store owners off guard since WooCommerce 8.x. If a checkout field or form plugin stopped working after a WooCommerce update, blocks incompatibility is the first thing to check.
Going forward, a staging environment and uptime monitoring are the two changes that prevent most update-related checkout failures from becoming customer-facing emergencies.