Seven lessons ago, this course opened by drawing a line between AI running on the backend, Courses 1 through 8’s territory, and AI running live inside the block editor. Everything since has been the second half of that line: a real block, a Block Bindings source, a sidebar panel, a toolbar action, and an inserter variation. This closing lesson ties both halves together, so the decision of which pattern to reach for isn’t guesswork the next time a feature request comes in.
This lesson assumes you’ve completed, or at least skimmed, Lessons 1 through 7 of this course. It doesn’t introduce new code, it connects what’s already been built.
Step 1: The two patterns, side by side
| Editor-side | Backend-side | |
|---|---|---|
| Where the call originates | JS running in wp-admin, live, while a post is open | PHP running on the server, triggered by a hook, cron, or an ability |
| Who or what is authenticated | The logged-in editor, via cookie and REST nonce | An external MCP client, via Application Password |
| What triggers the AI call | A click: a button, a toolbar action, a panel action | An event: a save, a scheduled task, a tool invocation |
| Typical audience | The person writing the content, right now | An automated process or a remote assistant, no human watching |
| This course’s examples | AI Text block, alt-text binding, tags panel, toolbar rewrite, summary variation | create-draft-post ability, scheduled SEO rewrite, MCP-exposed tools |
Both patterns end at the same place, a call into wp_ai_client_prompt(). What differs
is everything upstream of that call: who’s asking, how they proved who they are, and
what moment in the content lifecycle triggered the request.
Step 2: A decision guide for the next feature request
Reach for the editor-side pattern from this course when the feature is something an author does deliberately, while looking at the content, and expects to see the result immediately: rewrite this paragraph, suggest tags for this post, summarize this block. The author is present, the request is synchronous, and the UI needs to live where they’re already working.
Reach for the backend-side pattern from Courses 1 through 8 when the feature runs without anyone watching, on a schedule, in response to a webhook, or as a tool an external AI agent decides to call on its own: nightly SEO audits, an agent creating draft posts on your behalf, a chatbot answering questions about your site’s content from outside WordPress entirely. Nobody is sitting in the editor waiting for that result, so there’s no editor UI to build in the first place.
Lesson 4’s AI-generated alt text is a good example of straddling the line: the value is generated once (arguably backend-shaped, cached and computed independently of any one editing session) but exposed and eventually regenerated through editor-side UI. Don’t treat the two patterns as mutually exclusive within one feature, treat them as two tools that solve different halves of the same problem.
Step 3: What you built, lesson by lesson
Every one of these pieces reused the same two building blocks: a REST endpoint whose
callback calls wp_ai_client_prompt(), and @wordpress/api-fetch calling that
endpoint from inside an authenticated editor session. Nothing here required a
different entry point per lesson, the variety came from where in the editor’s UI that
same underlying call got wired in.
Test it: confirm your own build still holds together end to end
Open a post that has the AI Text block, an AI-bound image, some tagged content, and a paragraph, in other words, everything from this course, on one screen. Confirm: the AI Text block’s button still rewrites its own content, the bound image still shows its cached AI alt text without a new API call on reload, the AI Suggested Tags panel still applies a real tag, the toolbar action still rewrites a plain paragraph, and the AI Summary Block variation still appears in the inserter. If all five hold up together, the REST endpoints and the editor-side wiring are genuinely solid, not just working in isolation.
Because this course deliberately reused /my-plugin/v1/rewrite across the block, the
toolbar action, and (with a different instruction) the summary variation, a single
busy editor session can trigger several AI calls in quick succession across
unrelated-looking UI. If cost or provider rate limits become a real concern, that’s a
reason to add throttling or a shared in-flight-request guard at the REST layer, not a
reason to duplicate the endpoint per feature.
Recap
The pattern this course taught, an AI call triggered by a click inside the block
editor, authenticated by the logged-in user’s own cookie and nonce through
@wordpress/api-fetch, is the right tool whenever a human is present and expects an
immediate result. The pattern Courses 1 through 8 taught, an ability or a scheduled PHP
call authenticated by an Application Password or run entirely server-side, is the right
tool whenever nothing is watching and the trigger is an event, not a click. Real
WordPress sites doing serious AI work typically need both, and now you’ve built a
working example of each.
Resources & further reading
- WordPress AI Foundations, this track
- LLM Integration in WordPress With the PHP AI Client SDK, this track
- Build a WordPress MCP Server From Scratch, this track
- Block Bindings API reference, developer.wordpress.org