Evan Zellner

All projects

Case study

Bludit Wizard

AI-assisted writing, editing, and SEO work inside Bludit — with a human approval step before anything changes.

Bludit Wizard is a native plugin that lives in the Bludit admin sidebar. It turns a short instruction into a draft, a revision, or an audit, then shows the original and proposed content side by side. Nothing is saved or published until the publisher approves it.

It is deliberately not an autonomous site manager. There is no page deletion, no scheduled publishing, and no background loop. The plugin connects only to the OpenAI-compatible endpoint the site owner configures, and the provider key stays on the server.

The goal was not to add AI to a CMS for its own sake. It was to remove the copy-and-paste loop between a chat window and the page editor without giving up the diff.

The Bludit Wizard workspace inside the Bludit admin, showing a task selector, page selector, and instruction field.
The wizard workspace inside Bludit. Tasks that change content require a page and an instruction.

01The problem

The work happened in the wrong window.

Writing and editing inside a CMS means leaving the page you are working on: open a chat window, paste the content, explain the context again, copy the result back, and hope you kept the original. The context is lost, the diff is invisible, and it is far too easy to overwrite a newer edit.

Most AI publishing tools solve that by taking over the publishing step. That is the wrong trade for a site owner who wants assistance, not an autonomous editor. The plugin needed to be useful inside the admin area while leaving every decision with the person who owns the site.

02The approach

Assistance inside the CMS, with the approval step intact.

Bludit Wizard is a native PHP plugin that runs inside the Bludit admin, not a separate service. It talks directly to an OpenAI-compatible endpoint configured by the site owner, so no third party holds the site credentials or the content.

Twelve tasks are grouped into Write & Create, Edit & Improve, SEO & Quality, and Ask Wizard. Tasks that touch content select a real Bludit page first and receive only that page’s context. The result is rendered as original and proposed content side by side; applying it is a separate, explicit action.

Analysis tasks — SEO and clarity, internal links, content freshness — are read-only. Page deletion is not implemented at all. Server-side request handling keeps the provider key out of the browser, and a configurable network policy blocks private address ranges unless the owner deliberately opts in.

03What it does

Twelve tasks, one approval boundary.

  • Twelve guided tasks across writing, editing, SEO, and question answering
  • Page selection and task-specific instructions for every page-aware task
  • Original and proposed content shown together before an edit is applied
  • Stale-edit protection and a deliberate no-deletion policy
  • Read-only SEO, internal-link, and content-freshness audits
  • Provider presets, searchable model discovery, and a connection test
  • Safe behaviour when JavaScript or a versioned asset fails to load

04What was hard

Four things that were not obvious until they broke.

Making review feel like part of the work
A confirmation dialog is easy to ignore. The review step had to show the actual difference, keep the original readable, and make the consequence of applying a change obvious without turning every task into a form.
The RC1 dispatch regression
The first 1.1.0 release candidate lost a hidden action field. When JavaScript failed or a stale asset was cached, the workspace returned an unknown-action error and the page selector stayed hidden. RC2 fixed the dispatch path and versioned every asset so an old script cannot silently pair with new markup.
Provider compatibility is a surface, not a checkbox
OpenAI-compatible APIs differ in model discovery, tool support, and error shapes. OpenRouter and LLM Gateway were verified in live use; other providers remain compatibility guesses until someone tests them.
Network safety inside a CMS
A provider URL is user-controlled input. The plugin validates destinations, refuses private address ranges by default, and fails closed on DNS truncation rather than silently resolving somewhere unexpected.

05What I learned

Four things worth keeping.

  • Human approval is a product feature, not a disclaimer. It has to be fast and legible, or people will route around it.
  • Version every front-end asset. The failure mode is not the bug — it is an old script running against new markup.
  • Test the installed ZIP, not only the working tree. The package and both Bludit editions are part of the product.
  • “No page deletion” removed a class of catastrophic mistakes and made the rest of the interface easier to reason about.

06Status and limits

What is true today, and what is not.

v1.1.0 is a stable public release on GitHub, licensed GPL-3.0-only, with the installable ZIP attached. The release gate covered 441 HTTP, API, security, and task checks, 33 Playwright tests on Bludit Community and 33 on Bludit Pro, 98 network-policy assertions, and an installed-ZIP browser smoke test on both editions.

The plugin was submitted to the official Bludit plugin directory. The pull request is open and has not been accepted, so the project is not described as officially listed.

Live acceptance of all twelve tasks, provider discovery, and testing was performed by the maintainer on a disposable Hostinger installation. That acceptance is reported, not independently re-run by a second party.

Known gaps

  • Bludit plugin-directory acceptance is pending; the listing is not live.
  • Only OpenRouter and LLM Gateway were verified in live provider use.
  • No independent security audit has been performed.
Side-by-side original and proposed content with Apply this change and Discard suggestion buttons.
Original and proposed content, with apply and discard as separate actions.

Where to find it

Status, version, and links were checked against GitHub on 18 October 2026.