Module 6 — AI Inside the Block Editor (Gutenberg)
Goal: bring AI into the actual authoring experience, not just admin-side PHP.
Everything in Module 5 was about writing code you’d trust in production. This module is about where that code actually shows up for the people using your site, inside the block editor itself, not a shortcode on the frontend, not an admin settings page.
What’s in this module
- Build Your First AI-Powered Block. A real block, “AI Quote,” with a button in the editor that calls the REST endpoint pattern from Chapter 20 and drops a generated quote straight into the page you’re writing.
- Add “Improve with AI” to Existing Blocks. You don’t always need a new block. This chapter adds an AI-powered toolbar button to a block that already exists, the core Paragraph block, rewriting whatever text is already there.
- AI Image Block, Generate & Insert Images from the Editor. A “Generate Featured Image” block that turns Chapter 12’s image generation into something an editor can trigger with a click, no PHP shortcode required.
Why not the standard @wordpress/scripts setup?
Most real-world block plugins are built with @wordpress/scripts, a build tool that lets you write JSX and modern JavaScript, then compiles it into something the browser can actually run. It’s the genuinely standard, recommended way to build blocks today, and most other tutorials assume you’ll set it up.
This book doesn’t, for one specific reason: every chapter so far has worked by saving a file and reloading a page, no npm install, no build step, no compiler to configure. Introducing a build tool now would mean asking you to set up a whole separate workflow just for these three chapters, then abandon it again once Module 6 ends. That’s a lot of setup cost for a small part of the book.
So this module uses wp.element.createElement() directly instead of JSX. It’s more verbose to write, and it’s not how you’d build a block meant for the WordPress.org plugin directory, but it runs immediately, the same way every other example in this book has. That consistency matters more here than matching how production block development typically looks.
If you go on to build real, distributed blocks after this, @wordpress/scripts and JSX are worth learning properly. The block editor handbook is the right place to start.
One structural change for this module
Every chapter until now has lived in a single PHP file. Block registration is different, it’s real JavaScript logic, not a small dynamic snippet, and cramming it into a PHP string via wp_add_inline_script() gets awkward fast and isn’t really what that function is for. Starting this module, JavaScript lives in its own file, a plain .js file sitting in a new js folder inside includes, loaded with a normal wp_enqueue_script() call. Still no build step, still no JSX, just a real file instead of a string.
On to Chapter 22.