A client spent six months stuck on API plumbing before any AI features shipped. The lesson: build WordPress AI on a proper AI Client SDK, with a standard way to register providers, before chasing features.
Custom capabilities get messy fast on big WordPress sites. The Abilities API, in development for 6.9 as part of Core-AI, gives a structured way to define and manage them.
A client’s AI prototype broke because their site ran PHP 7.2 while our code used PHP 7.4. Here is how the WordPress Core AI team handles the same version gap, and how to build for it.
A client inherited an AI setup that was really just API calls held together with duct tape, and it kept breaking. Here is the architecture I use instead: provider interfaces and DTOs that let you swap AI models without rewriting everything.
parse_blocks() loads an entire post into memory and can take a server down on large content. WordPress 6.9 adds WP_Block_Processor, a streaming parser that reads block content one pass at a time so you can work with big posts safely.
WordPress 6.9 finally makes HTTPS the default in esc_url() and esc_url_raw() when no scheme is given, as long as ‘https’ comes first in the $protocols array. No more str_replace hacks.
A real question from WordPress Core AI work: should a shared AI adapter ship as a canonical plugin or a Composer library, and why that architecture choice shapes maintenance later.
WordPress.org has started running the Plugin Check tool on every plugin update, new and existing. A look at what the automated scans catch and how to run the same checks before you upload.
Tying a WordPress site to one AI provider’s SDK makes switching painful later. This walks through an abstraction layer with per-provider adapters so you can change models without rewriting your core code.
Gutenberg 22.1 ships a native tabs block and an HTML block that can carry its own CSS and JavaScript. Here is what that means for custom code and how it cuts down on extra plugins.