WordPress 6.8 + WooCommerce 9: 7 things that break old plugins (and how to fix them)

WordPress 6.8 (released March 2026) and WooCommerce 9 (released February 2026) introduced several changes that quietly break older plugins. If your site has plugins built before 2025, this is the list of seven things to check this month before something breaks at the worst possible time.

1. PHP 8.0 minimum, 8.2 recommended

WordPress 6.8 raised the minimum PHP version to 8.0. Most plugins written before 2024 still parse on 7.4 syntax but use deprecated patterns (like passing null to non-nullable parameters) that produce fatal errors on PHP 8.0. Quick fix: a scan with phpcs --standard=PHPCompatibility against PHP 8.0 finds these in minutes.

2. Stricter type checks in WooCommerce 9 hooks

Several WooCommerce filters that previously returned mixed now have strict types. Plugins that returned arrays where strings are now expected (or vice versa) will trigger a fatal. The most common offenders are filters around woocommerce_product_get_price and woocommerce_get_price_html.

3. jQuery removed from front-end by default

WordPress 6.8 stops enqueuing jQuery on the front end by default for performance. Plugins that assumed jQuery would always be available now need to call wp_enqueue_script('jquery') explicitly. About 30% of older shop plugins assumed jQuery globally — those break visibly the moment a customer interacts with anything dynamic.

4. The Site Editor is now the default theme experience

Classic themes still work, but new sites default to block themes. Plugins that registered widgets using the old widget API (not blocks) only show up under "Classic Widgets," which most users never look at. The fix: register a block-based equivalent. The classic widget continues to work for legacy users.

5. WooCommerce admin moved to React-only

The legacy admin pages (built with PHP) for orders, products, and customers are now opt-in. New stores get the React-based "WC-Admin" by default. Plugins that hooked into PHP admin pages with add_meta_box need to also register a slot via the WC-Admin extensibility API to appear in the new UI.

6. REST API now requires permission_callback

WordPress 6.8 made the permission_callback argument mandatory for register_rest_route(). Older plugins that omitted it (a common pattern) silently fail to register their routes. Symptom: REST endpoints return 404 even though the code looks correct. The fix: explicitly add 'permission_callback' => '__return_true' for public endpoints, or a real permission check for private ones.

7. Cookie-based auth deprecated for cross-origin requests

Plugins that used cookie auth for AJAX from a separate frontend (headless setups, mobile companion apps) need to migrate to application passwords or REST API authentication. Cookie auth still works for same-origin admin AJAX.

How to find out if your plugins are affected

Fastest scan: enable WP_DEBUG_LOG on a staging copy of your site, click around the public side and the admin for ten minutes, then read wp-content/debug.log. Almost every breakage above produces a clear "Deprecated" or "Fatal error" line.

For older custom plugins (built by an agency or freelancer years ago and never updated), you have three options:

• Pay the original developer to update — typically €100-€400 per plugin.
• Have a freelancer audit and patch — €200-€600 depending on plugin size.
• Regenerate the plugin from scratch using its functional description — €3-€15, no developer engagement needed. The new version is by definition compatible with WordPress 6.8 and WooCommerce 9 because it is built against the current API surface.

The hidden cost of legacy

The third option is the one most business owners do not consider, but it is often the cheapest. A plugin originally built in 2022 has accumulated four years of compatibility patches in its code, not all of them clean. Regenerating from a fresh description produces cleaner code that is compatible by construction. The catch is you need a clear description of what the plugin does — for plugins your team uses regularly this is easy; for plugins nobody remembers the purpose of, take it as a sign that maybe you do not need them anymore.

Action plan for this week

If you have not done a plugin audit since 2024, schedule two hours this Friday. Enable debug logging on staging, click through your shop, list every plugin that throws errors, and decide one of: update it, replace it with a regeneration, or remove it. Most stores find that 30-40% of installed plugins fall into the "remove it" bucket once forced to justify each one.