A client’s custom React admin broke on every core update, so I rebuilt it on what WordPress 6.9 ships instead: DataViews, the wider Fields API, the Abilities API and Block Bindings. Notes from that job.
A Trac ticket listed the bug under 6.8, so I ruled it out. It had been introduced earlier and only found in 6.8. The WordPress 6.9 release comes with a wording fix for exactly that confusion.
A client’s checkout threw a fatal error right after they updated to 6.9, and core wasn’t the cause. Notes on staging updates, and on Trac switching to the version a bug was introduced in.
A WooCommerce store’s next-product links kept reloading the same page after an update. The cause was the WordPress 6.9 tiebreaker in get_adjacent_post(), plus a filter that only swapped the date out of the SQL.
A client updated to WordPress 6.9 the day it shipped and broke their landing page. Here is why I hold major core updates until the first maintenance release, and the filter I use to keep them in staging.
The November 2025 core committers check-in set the direction for WordPress 7.0: PHP 7.4 as the minimum, AI models running in the browser instead of on your server, and a reworked WP Admin.
A pre-release WordPress install killed a client’s publish button. The cause was a core bug in hidden async-upload fields, one of several things the 6.9 release candidates cleaned up alongside alternate cron and REST API errors.
A banned member was back in ten minutes on three new accounts, because a dynamic IP beats a firewall rule. What the site actually needed was an incident response protocol: logging, permissions, and a human who owns the ban button.
Fifty layers of function_exists() held a membership site together until the LMS renamed its methods. The Abilities API in 6.9 gives plugins a registry to declare what they can do instead.
A client pushed WordPress 6.9 RC3 to a live WooCommerce store and lost checkout inside ten minutes. What broke, why my first quick fix made it worse, and where release candidate testing actually belongs.