DEV Community: jdku sjdu

Stop regenerating the whole page: patching HTML with an LLM using structured DOM operations

jdku sjdu — Tue, 21 Jul 2026 10:39:14 +0000

I build a WordPress plugin that generates landing pages from a prompt. The first version worked the obvious way: user types "make the hero background darker", I send the entire page HTML to the model, the model sends back the entire page HTML, I save it.

It worked. It was also terrible.

Slow. A 900-line page means ~12k output tokens for a one-property change.
Expensive. Output tokens are the costly ones, and I was paying for a full rewrite on every tweak.
Lossy. The model would "helpfully" restructure the footer while fixing the hero. Or drop an aria-label. Or rename a class and break the CSS.

That last one is the real killer. Users don't complain about latency nearly as much as they complain about the thing they didn't ask to change.

Here's what I replaced it with.

The core idea

Don't ask the model for HTML. Ask it for operations on a DOM, then apply them yourself with a real parser.

json
[
{
"op": "setAttribute",
"selector": "#hero",
"name": "class",
"value": "hero hero--dark"
},
{
"op": "replaceInner",
"selector": "#hero h1",
"html": "Ship faster. Build slower."
},
{
"op": "remove",
"selector": "#hero .badge"
}
]

The model emits maybe 200 tokens instead of 12,000. And critically: anything it didn't mention is untouched by construction, not by good behaviour. The blast radius of a bad generation is bounded by the schema.

Applying the operations

I use Symfony's DomCrawler, which wraps DOMDocument with a sane API and CSS selector support.

bash
composer require symfony/dom-crawler symfony/css-selector
php
use Symfony\Component\DomCrawler\Crawler;

final class DomPatcher
{
private Crawler $crawler;
private \DOMDocument $doc;

public function __construct(string $html)
{
    $this->doc = new \DOMDocument('1.0', 'UTF-8');

    // libxml mangles UTF-8 without this, and injects
    // <html><body> wrappers we have to strip later.
    $prev = libxml_use_internal_errors(true);
    $this->doc->loadHTML(
        '<?xml encoding="UTF-8">' . $html,
        LIBXML_HTML_NOIMPLIED | LIBXML_HTML_NODEFDTD
    );
    libxml_clear_errors();
    libxml_use_internal_errors($prev);

    $this->crawler = new Crawler($this->doc);
}

public function apply(array $ops): void
{
    foreach ($ops as $op) {
        match ($op['op']) {
            'setAttribute' => $this->setAttribute($op),
            'replaceInner' => $this->replaceInner($op),
            'remove'       => $this->remove($op),
            'insertAfter'  => $this->insertAfter($op),
            default        => throw new \InvalidArgumentException(
                "Unknown op: {$op['op']}"
            ),
        };
    }
}

private function setAttribute(array $op): void
{
    foreach ($this->crawler->filter($op['selector']) as $node) {
        /** @var \DOMElement $node */
        $node->setAttribute($op['name'], $op['value']);
    }
}

private function replaceInner(array $op): void
{
    $fragment = $this->parseFragment($op['html']);

    foreach ($this->crawler->filter($op['selector']) as $node) {
        while ($node->firstChild) {
            $node->removeChild($node->firstChild);
        }
        foreach ($fragment as $child) {
            $node->appendChild($this->doc->importNode($child, true));
        }
    }
}

public function toHtml(): string
{
    return $this->doc->saveHTML();
}

}

A few things that bit me:

filter() results are live-ish. If your operation removes nodes, iterate over a materialised array first — iterator_to_array() on the DOMNodeList — or you'll skip elements as the collection shifts under you.

loadHTML without LIBXML_HTML_NOIMPLIED wraps your fragment in . With it, you get the raw fragment but malformed input can produce surprising trees. I validate the output length against the input as a crude sanity check before persisting.

HTML5 tags emit libxml warnings.

, , custom elements — libxml's parser is HTML4. The warnings are harmless but you must suppress them or your error log fills up. If you need genuine HTML5 parsing, masterminds/html5 is the drop-in, at a real performance cost.

The selector problem

The whole scheme collapses if the model can't reliably address a node. .btn:nth-child(3) is a coin flip on a page it can only partially see.

So I don't let it invent selectors. On generation, every addressable element gets a stable ID:

php
private function ensureIds(\DOMDocument $doc): void
{
$xpath = new \DOMXPath($doc);
$addressable = $xpath->query(
'//section | //header | //footer | //h1 | //h2 | //h3 '
. '| //p | //img | //a | //button | //ul | //form'
);

foreach ($addressable as $node) {
    if (!$node->hasAttribute('data-pid')) {
        $node->setAttribute('data-pid', $this->nextId());
    }
}

}

The model only ever emits [data-pid="a7f3"] selectors. If it emits something else, I reject the operation rather than guessing. Rejection is cheap — I retry once with the error appended to the conversation, and the second attempt is nearly always valid.

Two-step retrieval

Even with operations, I was still sending the full page HTML as context. On a long page that's most of the input budget and it dilutes attention badly.

So: two calls.

Step 1 — locate. Send a skeleton: tag names, IDs, class lists, and the first ~60 characters of text content. No inline styles, no full copy, no SVG paths. A 900-line page compresses to about 40 lines.

Ship faster. Build slower.…

The page builder that doesn't…

Get started

…

Ask: which data-pids are relevant to this request? Response is a JSON array of IDs. Cheap, fast, and surprisingly accurate — locating is a much easier task than editing.

Step 2 — edit. Send only the full outerHTML of those nodes, plus the relevant CSS rules, and ask for operations.

Combined token cost on a typical edit dropped roughly 80% versus full-page regeneration, and the latency improvement is more than the numbers suggest because output tokens dominate wall-clock time.

The failure mode to watch: step 1 under-selects. The user says "make the buttons consistent" and the locator returns two of five buttons. My mitigation is to expand the selection — if a returned node has siblings sharing its class signature, include them. Not elegant, but it converted the most common complaint into a non-issue.

Storing it in WordPress

Since this is a WordPress plugin, a note on persistence, because the obvious choice is wrong.

I do not put the generated HTML in post_content. Instead:

post_meta holds separated html, css, and js, with distinct draft and published keys. Editing never touches what's live.
post_content holds the text copy only, stripped of markup.

That last decision is the one I'd defend hardest. SEO plugins, search indexing, excerpt generation, and the REST API all read post_content. If it contains a wall of

, every one of those systems gets garbage. Keeping plain prose there means the rest of the WordPress ecosystem behaves normally, for free.

CSS and JS get written to files with content-hashed names:

php
$hash = substr(hash('xxh128', $css), 0, 12);
$file = "page-{$postId}-{$hash}.css";

Immutable filenames mean you can set a far-future Cache-Control and never think about invalidation again. Old files get garbage-collected on a scheduled hook.

What I'd tell you if you're building something similar

Constrain the output format, not the model's behaviour. Every hour I spent adding "do not modify unrelated sections" to a system prompt was wasted. Making unrelated modification structurally impossible took an afternoon and actually worked.

Validate before persisting, always. Parse the model's JSON, check the schema, check every selector resolves, apply to a clone, diff the node count. Reject and retry beats saving something broken.

Locating and editing are different tasks. Splitting them was the single largest win, larger than the operations schema itself.

libxml is old and grumpy but it's already installed. For a plugin that has to run on shared hosting, no-dependencies-that-need-extensions beats elegance.

The plugin is Pagora AI if you want to poke at the result — it's free and the source is on GitHub. Mostly I'm curious whether anyone has found a better answer to the step-1 under-selection problem, because mine is held together with heuristics.

Human + AI: how I now build WordPress pages 10x faster without sacrificing quality

jdku sjdu — Mon, 23 Mar 2026 11:29:13 +0000

We've all heard the fear: "AI is going to replace web designers."

After months of building WordPress sites with AI tools, I think the reality is more interesting — and more optimistic — than that.

AI doesn't replace the human. It removes the parts that were wasting the human's time.

Here's what I mean in practice.

The old workflow (and why it was painful)

Building a WordPress page the traditional way means:

Hunting for a layout that roughly matches your vision
Swapping text, fighting column alignments, debugging spacing on mobile
Searching stock photo sites for images that don't look stock
Writing SEO copy from scratch
Manually rewriting everything if the client wants it in another language

None of this is creative work. It's mechanical work. And it was eating a huge chunk of the actual craft — the part where you think about what will convert, what will communicate, what will actually look good.

The tool that changed this for me is WP AI Builder — a WordPress plugin that generates complete Gutenberg pages from a plain text description.

What "AI + Human" looks like in practice

The workflow shift isn't "AI does everything." It's more like having a very fast, very tireless junior who handles the scaffolding while you focus on the vision.

You describe. AI builds. You refine.

You write a prompt like:

"A homepage for a boutique interior design studio. Warm tones, elegant feel. Include a hero with a full-width image, a services section with 3 cards, client testimonials, and a contact CTA."

Forty-five seconds later, you have a full Gutenberg page — blocks, layout, copy, custom CSS, and even AI-generated images. Not a template. Not placeholder text. An actual first draft of a real page, tailored to your description.

Then you take over. You adjust the headline, swap an image, tweak the spacing, push the colors to better match the brand. The creative decisions stay with the human. The mechanical assembly is gone.

That's the shift. And it's not small — it's the difference between spending a day on a page and shipping it in under an hour.

What the AI actually generates

A few things worth knowing about how WP AI Builder works:

Gutenberg blocks, not proprietary markup.
Everything generated is standard WordPress blocks. No shortcodes, no lock-in. If you stop using the plugin tomorrow, every page you built stays exactly as it is, fully editable, forever. Your content belongs to you.

CSS and JS included.
The AI doesn't just drop text into blocks — it generates custom CSS for each section so the layout actually looks designed. For developers, all of that CSS and JS is fully accessible and editable. You can open it, modify it, and take it wherever you want.

AI-generated images, auto-optimized.
No more switching tabs to Unsplash or Midjourney. Images are generated inline, royalty-free, and automatically compressed for the web. The page is fast from day one.

1-click translation.
You can translate an entire page — content, layout, everything — in a single click. The AI adapts the tone for the target language rather than doing a word-for-word swap. Useful for multilingual sites without needing WPML or Polylang.

No API keys, no external accounts.
Everything runs through the plugin. No OpenAI account needed, no Stripe setup for AI services, nothing to configure. Install, sign up, generate.

The quality argument

Speed is obvious. But I want to make the case for quality too, because I think it's underrated.

When you're not spending 80% of your energy on mechanical assembly, you have more headspace for the decisions that actually matter:

Is this copy converting, or just filling space?
Does this layout guide the eye where you want it to go?
Would a real user understand what this page is asking them to do?

The AI gives you a solid, usable first draft fast. Your job as a designer, developer, or agency professional becomes editorial — shaping, elevating, and making the page actually great — rather than building from zero.

The combination produces better output than either would alone. The AI is fast and thorough. The human is discerning and creative. Together, they're a strong team.

Pricing — and yes, there's a free tier

You can try WP AI Builder with 150 free credits on signup — no credit card required. That's enough to generate 2 full pages and see if it fits your workflow.

Paid plans start at $9/month (750 credits) and go up to $49/month (6,000 credits) for heavier use. Individual credit packs are also available at $10 for 750 credits.

Full pricing details here: website-ai-builder.com/pricing

See what it can actually produce

If you want to see the quality of pages the AI generates before you install anything, there's a design gallery with real editable examples:

👉 AI Design Gallery — 10 Editable Style Showcases

Each one shows a different style and use case — from agency pages to e-commerce to portfolios.

The takeaway

The best AI tools aren't the ones that try to remove the human from the equation. They're the ones that make the human more powerful by handling what was never worth their time in the first place.

WP AI Builder is, in my experience, the most capable tool in this category for WordPress right now. It's the only one that generates truly native Gutenberg output — with CSS, with images, with translation — without any platform lock-in.

If you're building WordPress sites and you're still doing it the slow way, it's worth 5 minutes to try.

👉 Download free on WordPress.org

I Built an AI That Actually Generates WordPress Pages From Scratch (Not Just Templates)

jdku sjdu — Tue, 18 Nov 2025 15:33:59 +0000

After months of development, I'm excited to share AI Builder - a WordPress plugin that uses AI to generate complete Gutenberg pages with custom blocks and CSS, tailored to your exact needs.

The Problem with Current AI Page Builders
Most AI WordPress tools just shuffle pre-made templates or combine existing blocks. They don't truly create - they assemble. I wanted something different: an AI that generates 100% custom content for every request, from the blocks themselves to the CSS styling.
What Makes AI Builder Different?

🤖 Chat-Driven Page Creation
A chat interface appears in the bottom-left corner of every page, post, and pattern editor (headers, footers, etc.). Just describe what you want, and the AI generates the complete Gutenberg content on the fly.

🎨 Truly Custom Generation
Unlike template-based builders, AI Builder generates:

Custom blocks tailored to your prompt
Unique CSS for every element
Context-aware content based on your site settings

🧩 Rich Custom Blocks Library
The AI can use specialized blocks that go beyond standard Gutenberg:

Contact forms
Interactive maps
Statistics panels
Carousels
And many more

🖼️ AI Image Generation
Generate images directly from prompts within any block on the editor. No need to leave WordPress or use external tools.

⚡ Smart Content Features

Fill text on demand: Ask the AI to populate any paragraph with relevant content
Insert custom blocks anywhere: Generate specific blocks at any position on your page
Editable CSS: Click the button in the top-right of the chat to modify the generated CSS
Fully editable blocks: Everything the AI creates can be manually adjusted

⚙️ Context-Aware Generation
In the plugin settings, you can provide information that the AI will consider for every request:

Primary and secondary site colors
Site name
Business/site information This ensures consistent, on-brand content across all generations.

🚀 Multi-Page Generator
Need to create multiple pages at once? The Multi-Page Generator lets you:

Enter prompts for multiple pages/posts simultaneously
Generate home, features, contact, and pricing pages in one go
Launch all generations at the same time Perfect for quickly scaffolding entire websites.

Pricing
AI Builder uses a credit-based system:

Free tier: 150 credits on signup
$10/month: 750 credits
$20/month: 2,000 credits
$50/month: 6,000 credits
One-time purchase: $10 for 1,000 credits (available on request)

See It In Action
🎥 Demo video: https://www.youtube.com/watch?v=osEnvVFlDNo&t=1s
🌐 Website: https://website-ai-builder.com/
⬇️ Download on WordPress.org: https://wordpress.org/plugins/ai-builder/

Technical Implementation
The plugin integrates deeply with Gutenberg's block editor, using:

Real-time AI communication through a persistent chat interface
Dynamic block generation with custom attributes
CSS injection and management per block
Asynchronous multi-page generation with queue management

Try It Out
I'd love to hear your feedback! The plugin is free to start (150 credits), so you can test it out on your WordPress site without any commitment.

What features would you like to see added? What challenges do you face with current page builders?