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.
Hard-coded breadcrumbs wrecked a client site, which is a decent argument for using the core block instead. The parts of 6.9 I plan to use: breadcrumbs, the Abilities API and theme.json pseudo-classes.
I once ran sponsorships for about fifteen WordCamps and spent more time chasing IBANs than writing code. The 2026 Global Partner Program moves that admin into one invoice and one point of contact.
A client’s migration left the cart broken and half the images 404ing. Here is the checklist I run instead: match the environments, handle serialized URLs properly, serve a 503 during the move, then crawl the whole site.
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.
Notes puts editorial comments on the editor canvas, the Abilities API replaces scattered capability checks for automated workflows, and classic themes finally load block styles on demand.
A Make WordPress Core proposal would allow the PHP short echo tag for single statements. Here is why the old objection stopped applying at PHP 5.4, and how to keep the rule strict in your own phpcs.xml.
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.