A VAT fix hardcoded into a core file vanished on the next WooCommerce update. Thin docs are how that happens. Includes the hook-based way to add a cart fee, and what the December office hours cover.
A client’s admin was three AI plugins deep, each with its own API key and settings page. The AI Experiments plugin v0.1.0 offers a registry and a base class instead, so features get built once against a standard API.
A WooCommerce shop doing 500 orders a day broke at 2 AM under a stack of decoration plugins and a 14-second LCP. Which holiday plugins are worth keeping, and how to limit where their scripts load.
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 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.