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.
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.
A hardcoded AI API key in front-end JavaScript is a security hole and a performance drag. This shows how to move the calls to a WordPress server-side proxy using the REST API and wp_remote_post.
How to add AI to a WordPress site with the WordPress AI Client SDK instead of hardcoded API keys and provider-specific code. Covers setup, credentials, and generating text.
A prep checklist for the Core AI table at WordCamp US Contributor Day: the AI Building Blocks, the main project repos, and the Slack channel, so you can build instead of getting your bearings.
Wiring an AI into WordPress through generic CRUD endpoints got confusing and risky fast. Breaking actions into separate, per-post-type abilities with clear permissions gives the AI the precision it needs.
After watching a junior dev burn hours on Gutenberg boilerplate, I finally tried the AI tools for web development everyone talks about. The two that stuck were Copilot and Cursor.
A WooCommerce store stuffed all its product attributes into post meta, and the filters buckled under thousands of products. The fix was a custom taxonomy for the shared, filterable data.
A client tried to just translate their WooCommerce shop into German and it broke. Here is why a multilingual WordPress site needs Multisite or a plugin like WPML, and what those tools handle that manual translation cannot.