WordPress AI 1.3.0 Ships Translation, Slugs, Custom Abilities

🇹🇷 Türkçe: Bu yazının Türkçesini oku →

Twenty years in, “put AI in the CMS” has been said by everyone from junior interns to Series A founders, and the useful version usually arrives without a headline. WordPress AI 1.3.0 shipped on August 18, one day before WordPress 7.1, and I nearly missed it entirely — which, given how it is written, is probably the point.

Three things caught my attention. Content translation lives inside the block editor now, not in a separate SaaS. Slug generation is a real feature rather than a cute demo. And a Custom Abilities toggle says out loud what the model is allowed to read on your site — five items, each one named, each one off by default. That last part is the tell. This is a plugin whose authors have clearly spent time thinking about the day something goes wrong.

I lived through the multi-language CD-ROM era in the nineties. Director, Lingo, three script languages, six locale folders, one voice actor in Bratislava recording German narration on a landline. Translation was always the throat of the whole project — the thing that ate your last week and your first launch. Watching WordPress fold that piece into the editor in a way you can actually govern is, quietly, the more interesting AI story of the month.

What is actually new

WordPress AI 1.3.0 was published on August 18 by Jeffrey Paul on Make/AI. The GitHub release notes pin the same date and reference the underlying pull requests. The plugin sits at over 40,000 active installs today per the WordPress.org plugin page, and 1.3.0 bumps tested-up-to to WordPress 7.1.

Three experiments landed under the editor’s Experiments tab.

Content translation. Select paragraphs and headings, pick a target language, and the plugin translates the selection. Post titles are optional. It is scoped to text blocks — no attempt to rewrite navigation, no button that “translates the whole site” — which is the correct scope for a first cut (pull request #747).

Slug generation. Suggests a permalink from the post title and body. Not a paragraph-level regeneration engine, not an “AI SEO score” gimmick — one slug, generated on request (pull requests #897 and #932).

Custom Abilities. A single opt-in toggle exposes five named abilities to the plugin: ai/get-post-details, ai/get-post-terms, core/read-settings, core/read-users, core/read-content. Off by default. Named. Auditable (pull request #881).

The release also ships a settings import/export tool (sensitive credentials excluded), an AI section in Site Health, a public WordPress\AI\log_ai_request() API for MCP servers, and two security fixes with GHSA identifiers — one for nonce verification on bulk operations, one for image URL validation on alt-text generation. The AI_Service class is deprecated in favour of wp_ai_client_prompt(), and meta keys have been renamed from the ai_ prefix to wpai_.

The AI Contributor Weekly Summary the following Wednesday documents four connector releases the same week — Anthropic 1.0.4, Google 1.1.1, Ollama 1.2.0, OpenAI 1.1.0 — and confirms the next major surface: a CRUD-shaped ability set (core/content-query, core/content-create, core/content-update, core/content-delete) targeted at WordPress 7.2 in December.

Why it matters for WordPress / WooCommerce people

The interesting choice is not the features. It is the shape.

Content translation delivered as a first-party WordPress plugin, running against whatever model provider you have already registered a key with, means you stop paying a per-seat SaaS to translate your own text. For agencies running multilingual client sites, that is a real line item off the bill. For WooCommerce merchants trying to publish product descriptions in three languages, that is one fewer plugin to license and one fewer contract to renegotiate at the end of the year.

The Custom Abilities toggle matters more than the translation. Every other AI CMS plugin I have looked at this year has taken the “let it read everything” approach, which is convenient right up until the moment a client asks what the model saw. Named abilities that are off by default make that conversation possible. When 7.2 lands CRUD-shaped abilities in December, the same discipline can be applied to write and delete surfaces — and the difference between “the model may query products” and “the model may delete products” stops being a policy footnote and becomes an actual toggle you can show an auditor.

What I would do (or not do) about it

I would install it on staging this week, not production. The plugin needs a separate connector plus your own API key, so nothing runs against a live database until you have decided which provider you trust and where you want the request billed. Turn on content translation for one draft, one language, see how it handles your voice. Then turn on slug generation for a batch of ten posts and read the output honestly. If it saves you thirty seconds each, it pays for itself; if it produces slugs you would not ship, you keep the plugin off.

I would leave Custom Abilities off until you have written down what you actually want the model to see. Two of the five (core/read-users, core/read-settings) belong nowhere near a client site’s editorial workflow. The three content-shaped ones (ai/get-post-details, ai/get-post-terms, core/read-content) are fine on an internal knowledge base or a single-editor blog; on a multi-author WooCommerce site, they deserve the same review your GDPR data map got.

I would not build a client-facing “AI content” feature on top of this yet. It is an experiments tab for a reason. The CRUD abilities landing in 7.2 are what a production feature should target, and December is close enough to wait for. Ship translation to your own team, not to your client’s marketing lead who will discover the “regenerate” button at eleven at night.

The headline release last week was WordPress 7.1. The one that changes what “AI in WordPress” actually means is this quiet 1.3.0 update the day before. Watch the December cut.