DEV Community: Andrea Tasselli

The WordPress Plugin Stack I Install on Every Single Site (And Why)

Andrea Tasselli — Thu, 09 Apr 2026 14:08:25 +0000

After 200+ WordPress sites, my plugin stack has converged to the same 9 plugins. Every time.

Not because I'm lazy. Because I've tried the alternatives, broken things in production, dealt with plugin conflicts at 2am, and slowly eliminated everything that wasn't essential.

This is the stack I install on every site I build — including the ones generated by Megify, the AI platform I'm building. Every plugin here earns its place. If it doesn't solve a real problem, it's not on the list.

The rules

Before the list, the rules I follow:

Fewer plugins = fewer problems. Every plugin is a potential security hole, a performance hit, and a compatibility risk. If I can do it without a plugin, I do.
No plugin does two jobs. SEO plugin does SEO. Cache plugin does caching. I don't want an "all-in-one" plugin that does 17 things badly.
Free tier must be usable. If the free version is crippled to the point of uselessness, the plugin is a sales funnel, not a tool.
Active maintenance. If the last update was 6 months ago, it's dead. WordPress core updates break unmaintained plugins.

1. Rank Math (SEO)

What it does: Meta titles, descriptions, schema markup, sitemap, redirects.

Why not Yoast: I used Yoast for years. Rank Math does the same things with a cleaner UI, better schema markup options, and the free version includes features that Yoast locks behind premium (redirects, multiple keyword tracking, schema types).

The setup I use: Enable only the modules you need. I typically turn on: SEO Analysis, Sitemap, Schema, Redirections, and 404 Monitor. Everything else stays off. Rank Math with all 15 modules enabled is bloated. With 5, it's lean.

One thing people miss: The "Instant Indexing" module. It pings Google via the Indexing API when you publish or update content. Pages get indexed in minutes instead of days. You need a Google API key, but it's free and takes 10 minutes to set up.

2. WP Rocket (Caching + Performance)

What it does: Page caching, browser caching, GZIP compression, CSS/JS minification, lazy loading, database optimization.

Why it's worth paying for: This is the one paid plugin on my list (€59/year for a single site). I've tried every free caching plugin — W3 Total Cache, WP Super Cache, LiteSpeed Cache. They all work. But WP Rocket works out of the box with zero configuration. Install, activate, done. No 47 settings tabs, no breaking your site because you enabled the wrong option.

The setting most people miss: "Preload Cache" — it crawls your site and generates cached versions of every page in advance. First-time visitors get a cached page instead of waiting for PHP to render. Combined with "Preload Links" (prefetches pages on hover), navigation feels instant.

If you can't afford it: LiteSpeed Cache if your host supports LiteSpeed (many do now). Otherwise WP Super Cache — ugly interface, reliable caching.

3. Wordfence (Security)

What it does: Firewall, malware scanner, login security, brute force protection, real-time threat intelligence.

Why it matters: WordPress is 40% of the web. That makes it target #1 for automated attacks. Without a security plugin, you're relying on hope. Wordfence's firewall blocks most attacks before they reach your site.

The free version is enough. Premium adds real-time firewall rules (free users get them 30 days later) and real-time malware signatures. For most sites, the free version with 30-day delayed rules is perfectly adequate.

The settings I change:

Enable 2FA for all admin accounts. Non-negotiable.
Set "Lock out after how many login failures" to 5.
Enable "Rate Limit" for crawlers and humans.
Disable XML-RPC in the firewall settings (it's an attack vector nobody needs in 2026).

4. UpdraftPlus (Backups)

What it does: Automated backups to remote storage (Google Drive, Dropbox, S3).

Why it's critical: Your hosting provider probably does backups. But can you access them easily? Can you restore a specific page from 3 weeks ago? Can you download a full backup to your local machine? With UpdraftPlus, yes to all.

My setup: Full backup every week to Google Drive. Database-only backup daily. Keep the last 4 weekly backups and 7 daily database backups. This means I can restore to any day in the last week, or any week in the last month.

The mistake I see constantly: People install a backup plugin but never test a restore. A backup you can't restore is not a backup. Every 3 months, download a backup, spin up a local WordPress, and restore it. Make sure it works.

5. WPForms Lite (Forms)

What it does: Contact forms, with drag-and-drop builder.

Why this and not Contact Form 7: CF7 works. I used it for a decade. But every time I set up a form with CF7, I spend 20 minutes fighting with the markup and the mail configuration. WPForms Lite lets me build a contact form in 2 minutes with a visual builder. For a contact form — which is all most sites need — the speed difference matters when you're building sites at scale.

The limitation of the free version: No payment forms, no multi-step forms, no conditional logic. If you need any of these, you need Pro. But for a standard "Name, Email, Message, Send" form, Lite is all you need.

Alternative: Fluent Forms free version if you need more fields without paying.

6. Imagify (Image Optimization)

What it does: Compresses images on upload. Supports WebP conversion.

Why it matters: Images are typically 60-80% of a page's weight. An unoptimized 3MB hero image kills your Core Web Vitals, your Lighthouse score, and your user experience on mobile. Imagify compresses images on upload with no visible quality loss.

The setting that saves bandwidth: Enable WebP conversion. WebP images are 25-35% smaller than JPEG at equivalent quality. All modern browsers support WebP. Imagify creates the WebP version and serves it automatically — no code changes needed.

Free tier: 20MB/month of image optimization. For a small site with occasional uploads, it's enough. For an ecommerce with hundreds of product images, you'll need the paid plan.

Alternative: ShortPixel does the same thing with a similar free tier.

7. Redirection (URL Management)

What it does: Manages 301 redirects and tracks 404 errors.

Why you need it: Every time you change a URL, delete a page, or restructure your site, old URLs break. That's lost SEO value and a bad user experience. Redirection catches 404s and lets you redirect them to the right page with two clicks.

The thing most people don't know: Redirection can automatically create a redirect when you change a post's permalink. Enable "Monitor permalink changes" in settings. Now you never have to worry about changing a URL — the redirect is created automatically.

This is free. Fully featured, no premium version, no upsells. One of the best free plugins in the WordPress ecosystem.

8. WooCommerce (When Needed)

What it does: Turns WordPress into a full ecommerce platform.

When I install it: Only when the site needs to sell something — physical products, digital downloads, services, bookings. I don't install it "just in case." WooCommerce adds significant database tables and admin complexity. If you don't need it, don't install it.

The configuration that matters most: Stripe as primary payment gateway (lowest fees for European cards: 1.4% + €0.25), PayPal as secondary (some customers don't want to enter card details). Shipping zones configured correctly for the target market. Tax settings using a tax plugin or manual rates.

The plugin I add to WooCommerce: Just one — a shipping plugin specific to the client's country (for Italy, I typically use one that integrates with BRT or GLS rates). Everything else WooCommerce does natively.

9. Elementor (Page Builder)

What it does: Visual drag-and-drop page editing.

Why: Because clients need to edit their pages. And "edit in Gutenberg" still means "learn a block editor that changes every WordPress update." Elementor's interface is stable, visual, and understood by millions of users. When I hand off a site, the client can edit text, swap images, and rearrange sections without calling me.

Free vs Pro: The free version handles most landing pages and basic sites. Pro (€59/year) adds theme builder, popup builder, WooCommerce widgets, and custom fonts. For a business site, Pro is usually worth it. For a simple site, free is fine.

The performance concern: Yes, Elementor adds weight — extra CSS, JS, and DOM elements. But with WP Rocket's minification and a good hosting setup, the impact is manageable. A well-built Elementor site scores 85-90 on Lighthouse. Not perfect, but good enough for a business site where editability matters more than a 100 Lighthouse score.

What I don't install

This list is as important as what I install:

No "all-in-one" plugins. Jetpack does 30 things. I need 0 of them badly enough to install a plugin that big. Same for plugins that combine security + performance + SEO. Do one thing well.

No social sharing plugins. They add bloat for minimal value. If someone wants to share, they'll copy the URL. The share buttons with counters showing "0 shares" do more harm than good.

No analytics plugins. Google Analytics is a script tag, not a plugin. Adding a plugin to insert one script tag is unnecessary. I add the GA4 tag via Google Tag Manager, which is also a single script tag. If the client needs a dashboard in WordPress, I use Site Kit by Google — but only if they ask.

No maintenance mode plugins. A maintenance.html file and an .htaccess rule does the same thing without a plugin.

No database optimization plugins. WP Rocket includes database cleanup. Adding another plugin for the same job is redundant.

The stack in production

This is the exact stack running on the sites generated by Megify. When the AI creates a WordPress site, these plugins are pre-installed and pre-configured with the settings described above. The user gets a site that's fast, secure, SEO-ready, and backed up — without installing or configuring anything.

It's not the most exciting part of the platform. But it's the part that keeps sites running reliably at 3am when nobody's watching.

What's your WordPress plugin stack? I'm always curious about what other developers have converged on after years of trial and error.

I Got Tired of Clicking "Accept" 100 Times a Day in Claude Code. So I Built a Menu Bar App

Andrea Tasselli — Wed, 18 Mar 2026 13:41:25 +0000

If you use Claude Code in VS Code, you know the pain.

Claude wants to edit a file. "Allow?" Click. Claude wants to run a command. "Allow?" Click. Claude wants to read a directory. "Allow?" Click.

On a productive day, I click "Accept" 50-100 times. It breaks flow, interrupts thinking, and adds up to minutes of pure friction.

So I built a macOS menu bar app that does it for me.

What it does

Claude Auto Accept sits in your macOS menu bar and monitors Claude Code for permission prompts. When one appears, it either:

Auto-accepts it (fully automatic mode) — Claude runs uninterrupted. At the end, you get a notification with the total count of accepted prompts.
Accepts via keyboard shortcut (⌘⇧⌥0 to Accept, ⌃⇧N to Reject) — you stay in control but don't have to reach for the mouse.

How it actually works

The app doesn't inspect the VS Code UI at all. Instead, it monitors Claude's own log files.

Claude Code writes JSONL logs to ~/.claude/projects/. Every time Claude requests a tool use (edit a file, run a command, read a directory), it writes a "type":"tool_use" entry with the specific tool name.

The app polls these log files every 2 seconds, detects new tool use requests, and sends the appropriate keyboard event to VS Code to accept or reject them.

The stack is straightforward macOS native:

AppKit (NSStatusBar, NSMenu) for the menu bar app — no SwiftUI, just classic Cocoa
CGEvent for registering global hotkeys and sending keyboard events to VS Code
UserNotifications for the summary notification when auto mode finishes
File system monitoring for the JSONL logs

The 2-second polling interval means there's a small delay between Claude asking for permission and the app accepting it. In practice, you barely notice it.

The honest part: it's rough

This started as an internal tool at our company. We use Claude Code daily to build Megify, an AI platform that generates WordPress sites. We needed something that worked for us, not something polished for the world.

It works. We use it every day. But:

Multiple VS Code windows can confuse it — it doesn't always target the right one
2-second polling means occasional visible delay before acceptance
No prompt filtering — in auto mode, it accepts everything. You can't say "auto-accept file edits but ask me about terminal commands"
macOS only — it uses native APIs that don't exist on Windows or Linux
VS Code only — no support for Claude Code in the standalone terminal

I'm open-sourcing it because every Claude Code user has the same problem, and I'd rather have 10 people improving it than try to polish it alone.

Setup

You'll need macOS 13+ and Xcode command line tools:

xcode-select --install
git clone https://github.com/andreata/claude_vscode_accept_mac.git
cd claude_vscode_accept_mac
chmod +x install.sh && ./install.sh

Grant Accessibility permissions when prompted (System Settings > Privacy > Accessibility). The app needs this to send keyboard events to VS Code.

Shortcuts:

⌘⇧⌥0 — Accept current prompt
⌃⇧N — Reject current prompt

Fair warning: auto mode means Claude executes everything without asking. Use it on projects where you trust Claude's judgment, or use shortcut mode for more control.

What I want to add (and need help with)

The roadmap, roughly in priority order:

Prompt filtering. Auto-accept file edits and directory reads, but pause for terminal commands and destructive operations. This requires parsing the tool name from the JSONL entries and maintaining an allow/deny list. Most requested feature from my team.

Better window targeting. When you have 3 VS Code windows open, the app needs to send the keyboard event to the right one. Probably requires accessibility API inspection of the window hierarchy.

Prompt history/log. A scrollable list in the menu bar dropdown showing what was accepted, when, and what tool was used. Useful for reviewing what Claude did while you were getting coffee.

Faster polling or file system events. Replace the 2-second polling with FSEvents or DispatchSource.FileSystemObject for near-instant detection.

Terminal support. Claude Code works in the regular terminal too, not just VS Code. The JSONL monitoring would still work, but sending the accept keystroke requires a different mechanism.

Homebrew formula. brew install claude-auto-accept would be the dream.

If any of these interest you, PRs are very welcome. Even bug reports help — the more macOS versions and VS Code configurations we test against, the more reliable it gets.

The bigger picture

The permission system in Claude Code exists for good reason — you don't want AI silently deleting files or running arbitrary commands. But the current UX is designed for safety, not productivity. Every developer who's been using Claude Code for months has muscle memory for "Accept" — the permission prompt is a speed bump, not a safety check.

The right solution is filtering: auto-accept safe operations (read files, edit code, create files) and require confirmation for dangerous ones (delete files, run destructive commands, access network). That's what we're building toward.

Until Anthropic adds this natively (please?), this menu bar app is the workaround.

The repo: github.com/andreata/claude_vscode_accept_mac

If you use Claude Code daily and this sounds useful — or if you've built something similar — I'd love to hear about it.

I Built a Headless WordPress Multisite Platform. It Worked Perfectly. Then the Server Bill Arrived.

Andrea Tasselli — Mon, 16 Mar 2026 11:54:37 +0000

This is a story about building something technically impressive that couldn't survive as a business. Everything worked. The architecture was solid. The client loved it. And we still had to abandon the model.

If you're building platforms on top of WordPress — especially headless — this might save you six months of work.

The idea

A few years ago, before AI-assisted development was a thing, my team and I set out to build a platform that would let anyone spin up a fully functional ecommerce store through a guided wizard.

The pitch was simple: answer a few questions, pick a template, and get a live WooCommerce store with sample products, payment gateway configured, and a custom domain — all automated. No technical knowledge required.

The twist: the frontend was headless. Every store ran a decoupled frontend that pulled data from WordPress via the REST API. The result was a shopping experience that felt like a native app — instant page transitions, snappy product filtering, smooth cart interactions. No full page reloads, no WordPress frontend overhead.

We were proud of it. Rightfully so — it was a serious piece of engineering.

The stack

We ran everything on OVH Cloud with Docker. The core architecture:

WordPress Multisite as the backend. Each new store was a subsite on the network. This gave us centralized plugin management, shared user tables, and a single WordPress installation to maintain. When we updated a plugin, every store got it.

Automated provisioning. When a user completed the wizard, the system created the multisite subsite, pointed a domain via DNS API, installed WooCommerce with preconfigured settings, populated sample products and categories, and generated the headless frontend build.

Decoupled frontend. Each store had its own static frontend (built with Gridsome — a Vue-based static site generator that was popular at the time) that consumed the WordPress REST API. This was pre-rendered and served from a CDN. Page loads were sub-200ms. Product pages felt instant. The checkout was smooth.

Docker orchestration. Everything ran in containers — the WordPress multisite, the database, Redis for object caching, Nginx as reverse proxy, and the build pipeline for the frontends.

It was beautiful. It was fast. It worked.

The client

We sold the platform to one of our agency clients. They wanted a way to offer ecommerce stores to their small business customers without building each one from scratch.

They're still using it today — you can see the original platform at megicart.it. Their customers love the speed of the frontend. The admin is standard WooCommerce, so anyone can manage products and orders. Updates are centralized. Support is straightforward.

One client, one multisite, a manageable number of stores. It works great in that context.

Where it broke

The first client worked great. One store, manageable product catalog, builds running smoothly. We were confident.

So we added two more test stores to the multisite to simulate what a real platform would look like. Three stores total on a €68/month OVH Cloud instance. Not a cheap server — decent specs, solid performance for most workloads.

Then all three stores triggered builds around the same time. A product update on store one. A page edit on store two. A theme change on store three.

The server froze. Completely. CPU pegged at 100%, memory exhausted, SSH unresponsive. We had to hard reboot from the OVH panel.

Three stores. Not thirty. Not three hundred. Three.

The problem was fundamental: a headless frontend needs to be built. Every time a store owner changes a product, updates a page, or modifies anything, the static frontend regenerates. That means pulling every product from the WordPress REST API, rendering every product page, every category page, every filtered view. For a store with hundreds of products, a single build consumes several GB of RAM and a full CPU core for minutes.

One build at a time? Fine. Two or three concurrent builds on the same server? Everything dies.

The math that killed it

We did the math we should have done before building the platform.

To run just 10 stores without builds crashing each other, we needed a server with enough CPU and RAM to handle 3-4 concurrent builds. That meant upgrading to an instance 4-5x more expensive — €250-350/month minimum.

For 50 stores, we'd be looking at €500-600/month in infrastructure alone. At that point, each store needs to pay €10-12/month just to cover servers. Add development, support, and margin, and the price per store hits €25-40/month.

Meanwhile, a traditional WordPress site with good hosting (not headless, just well-optimized with caching and a CDN) delivers sub-500ms page loads at €5-8/month per site. The headless frontend was objectively faster — sub-200ms — but was that extra speed worth 4-5x the infrastructure cost? For a small business owner selling candles or running a restaurant menu? No.

What we got wrong

We never tested concurrent builds before building the platform. We tested one store, it worked, and we assumed three would work three times as well. That's not how shared server resources work. One build is fine. Three concurrent builds on the same machine is a completely different problem.

We optimized for the wrong metric. We were obsessed with frontend performance (sub-200ms loads) without calculating whether that performance justified the infrastructure cost. A well-configured traditional WordPress site with a CDN delivers sub-500ms loads at a fraction of the cost.

Multisite amplified the problem. WordPress Multisite shares everything — database, PHP processes, memory. When one store triggers a heavy build, every other store on the network competes for the same resources. Isolated instances would have been more resilient, but then you lose the centralized management that made multisite attractive in the first place.

We fell in love with the architecture. The headless setup was technically beautiful. The frontend was objectively faster. The developer experience was great. But none of that matters if three stores crash a €68/month server. We kept trying to optimize the build pipeline instead of questioning whether headless was the right choice for this business model.

What I'd do differently

If I were building this today, I'd make three different choices.

Skip headless for this use case. A traditional WordPress frontend with a good theme, proper caching, and a CDN delivers "fast enough" for small business ecommerce. The difference between 200ms and 500ms page loads doesn't move the conversion needle for a store selling artisanal candles.

Isolated instances instead of multisite. Each store gets its own containerized WordPress environment. No shared resources, no noisy neighbors, predictable performance. This is actually what I ended up building with Megify — every generated site runs in its own isolated environment.

Let AI handle the content generation. Back then, we had to manually create templates and sample content for each store type. Today, AI generates unique designs, copy, and product structures from a text description. The provisioning that took us hours of template work now takes minutes.

The lesson

The project wasn't a failure. One client is still happily using it years later. We learned Docker orchestration, headless WordPress architecture, API optimization, and build pipeline management. All of that knowledge directly informed what I'm building now.

But the business model was flawed because we didn't do the infrastructure math until we'd already built the platform. By then, we were emotionally invested in the architecture and kept trying to make it cheaper instead of asking whether headless was the right approach for the market we were targeting.

The takeaway: run the unit economics before you write the first line of code. Especially for platform businesses where infrastructure costs scale with usage. The most elegant architecture in the world doesn't matter if you can't charge enough to pay for the servers.

I'm now building Megify, which evolved directly from that failed platform — even the name comes from MegiCart, the original headless project. Megify generates WordPress sites and ecommerce stores using AI. Traditional WordPress, not headless — because the infrastructure math works. Each site is isolated (not multisite), AI handles the content generation, and the hosting cost per site is predictable and sustainable. There's a technical breakdown of the architecture if you're curious how it works under the hood.

I also open-sourced a tool we built along the way: Figma to Avada — converts Figma designs to WordPress/Avada shortcodes using AI.

Sometimes the boring architecture is the right architecture.

If you've had similar experiences — building something technically impressive that didn't survive contact with business reality — I'd love to hear about it.

Using LLMs to Generate Structured Data for WordPress (Not HTML)

Andrea Tasselli — Fri, 13 Mar 2026 14:44:32 +0000

Most tutorials about AI + web development show the same pattern: give the LLM a prompt, get back HTML, paste it somewhere. It works for prototypes. It breaks in production.

I've been building a system that generates full WordPress sites from text descriptions. Early on, I made the obvious choice: have the AI generate HTML. It took about two weeks to realize that was a terrible idea.

Here's what I learned, and the architecture I ended up with instead.

Why generating HTML is a trap

When you ask an LLM to generate a web page, it produces markup. Something like:

<div class="hero-section" style="background: #1a1a2e; padding: 80px 40px;">
  <h1 style="color: white; font-size: 48px;">Artisan Gelato</h1>
  <p style="color: #ccc;">Handcrafted flavors since 1987</p>
  <a href="/menu" class="btn" style="background: #e63946;">View Menu</a>
</div>

Looks fine. Now try to:

Edit it with a visual editor. Elementor, Gutenberg, or any page builder will choke on inline styles and non-standard class names. The user can't drag-and-drop edit something that wasn't built with the editor's data model.
Update the theme. When the theme updates, your generated HTML stays frozen in time. Fonts change, spacing changes, colors change — everywhere except your AI-generated sections.
Make it responsive. The AI generated desktop markup. Mobile? Tablet? You need media queries that reference the AI's arbitrary class names. Good luck maintaining that.
Keep it consistent. Generate 5 pages with 5 separate prompts. Each one uses slightly different class names, different heading hierarchies, different spacing values. There's no design system — just 5 independent HTML blobs.

HTML generation works for one-off demos. It doesn't work for production sites that need to be maintained, edited, and updated by non-technical users.

The alternative: generate data, not markup

Instead of asking the AI to produce HTML, I have it produce a structured JSON schema that maps to WordPress constructs.

Here's the same hero section, but as structured data:

{
  "type": "section",
  "template": "hero",
  "settings": {
    "background_color": "#1a1a2e",
    "padding": {"top": 80, "bottom": 80, "left": 40, "right": 40},
    "text_align": "center"
  },
  "elements": [
    {
      "type": "heading",
      "content": "Artisan Gelato",
      "tag": "h1",
      "style": {"color": "#ffffff", "font_size": 48}
    },
    {
      "type": "text",
      "content": "Handcrafted flavors since 1987",
      "style": {"color": "#cccccc"}
    },
    {
      "type": "button",
      "content": "View Menu",
      "url": "/menu",
      "style": {"background": "#e63946", "color": "#ffffff"}
    }
  ]
}

This JSON gets translated by a rendering layer into whatever the target system needs — Elementor widgets, Gutenberg blocks, WooCommerce products, WordPress custom fields.

Why this works better

1. The visual editor understands it

When the JSON is translated into Elementor's data format, the result is a native Elementor section. The user opens the page builder and sees editable widgets — not a frozen HTML block. They can drag elements, change colors, edit text, exactly like any other Elementor page.

JSON schema → Translator → Elementor data model → Native editable page

The translator is a mapping layer that knows how to convert each JSON element type into its Elementor equivalent:

"type": "heading" → Elementor Heading widget
"type": "text" → Elementor Text Editor widget
"type": "button" → Elementor Button widget
"type": "section" with "template": "hero" → Elementor Section with specific column structure

2. Theme changes don't break anything

The JSON doesn't contain theme-specific code. The translator reads the current theme's settings (fonts, colors, spacing defaults) and applies them during rendering. When the theme updates, the translator re-renders with the new settings. Nothing breaks.

3. Consistency is built in

Every page goes through the same translator. The same "type": "heading" always produces the same Elementor widget with the same base settings. No more five-pages-five-different-approaches problem.

4. The AI's job is simpler

Generating valid JSON with a known schema is much easier for an LLM than generating valid, semantic, accessible, responsive HTML. The error rate drops dramatically.

With HTML generation, about 8-12% of outputs had issues — unclosed tags, broken nesting, inaccessible markup. With JSON generation against a strict schema, the error rate is under 1%.

The prompt architecture

Getting an LLM to produce reliable structured output requires more than "generate JSON." Here's the approach that works in production.

System prompt: define the schema

You are a web architect. You generate website structures as JSON.

Every response must be valid JSON matching this schema exactly:
- Root: array of sections
- Each section: type, template, settings, elements
- Each element: type, content, style (optional), children (optional)

Valid section templates: hero, features, testimonials, pricing, 
  cta, gallery, team, faq, contact, footer
Valid element types: heading, text, button, image, icon, list, 
  card, column, spacer, divider, form

NEVER include HTML tags in content fields.
NEVER add properties not in the schema.
ALWAYS use the exact property names specified.

User prompt: describe the project

Generate a website structure for:
"Artisan gelato shop in Florence. Seasonal ingredients from 
local farms. Open since 1987. Need: homepage with hero, 
menu page, about page with our story, contact page."

For each page, generate the complete section structure 
with appropriate templates and real, relevant content.

Key prompt engineering decisions

Temperature 0.5 for structure, 0.7 for content. I actually make two passes. First pass: generate the page structure (which sections, which templates, how many elements) at low temperature for consistency. Second pass: generate the actual copy at slightly higher temperature for creativity.

Explicit constraints reduce errors. "NEVER include HTML tags" catches the LLM's tendency to sneak in <br> and <strong> tags inside content fields. "NEVER add properties not in the schema" prevents hallucinated fields that the translator doesn't know how to handle.

Examples in the system prompt. I include 2-3 examples of correctly formatted output. This alone reduced schema violations by ~60%.

WooCommerce: where structured data really shines

For ecommerce, the gap between HTML generation and structured data is even bigger.

An AI-generated WooCommerce product as HTML is useless — it's just text that looks like a product page. An AI-generated product as structured data actually creates a WooCommerce product:

{
  "type": "product",
  "name": "Pistachio Gelato - 500ml",
  "price": 8.50,
  "category": "Classic Flavors",
  "description": "Made with Bronte pistachios...",
  "sku": "GEL-PIST-500",
  "weight": 0.6,
  "stock_status": "instock",
  "images": ["pistachio-gelato.jpg"],
  "attributes": {
    "size": "500ml",
    "allergens": "Tree nuts, Milk"
  }
}

This gets imported directly via the WooCommerce REST API. The product appears in the shop with all its data — price, SKU, categories, attributes — correctly set. The user can manage it from the standard WooCommerce dashboard.

Compare that to generated HTML of a product card. What do you do with it? Paste it somewhere? It doesn't connect to inventory, it doesn't process orders, it doesn't show up in the WooCommerce product list.

The translator in practice

The translator is the bridge between the AI's JSON output and WordPress. Here's a simplified version of how it works for Elementor:

def json_to_elementor(section):
    """Convert a JSON section to Elementor data structure."""

    template_map = {
        "hero": {"columns": 1, "min_height": 500},
        "features": {"columns": 3, "min_height": 0},
        "testimonials": {"columns": 1, "min_height": 0},
        "pricing": {"columns": 3, "min_height": 0},
    }

    element_map = {
        "heading": "heading",      # Elementor widget type
        "text": "text-editor",
        "button": "button",
        "image": "image",
        "icon": "icon",
    }

    config = template_map.get(section["template"], {})

    elementor_section = {
        "elType": "section",
        "settings": {
            "background_color": section["settings"].get("background_color"),
            "padding": section["settings"].get("padding"),
            "min_height": {"size": config.get("min_height", 0)},
        },
        "elements": []  # Columns with widgets
    }

    # Create columns and distribute elements
    for element in section["elements"]:
        widget = {
            "elType": "widget",
            "widgetType": element_map[element["type"]],
            "settings": translate_settings(element)
        }
        elementor_section["elements"].append(widget)

    return elementor_section

The actual production translator is more complex (handles nested elements, responsive settings, theme integration), but the principle is the same: map structured data to platform-native constructs.

Error handling

Even with good prompts, LLMs occasionally produce invalid output. The system handles this with three layers:

Layer 1: JSON validation. Parse the response. If it's not valid JSON, retry with the same prompt (up to 2 retries). This catches ~90% of failures.

Layer 2: Schema validation. Validate against the expected schema. If a required field is missing or a value is the wrong type, fill in sensible defaults rather than failing. A missing font_size gets the theme default. A missing background_color gets transparent.

Layer 3: Rendering validation. After the translator produces Elementor data, validate that the output is well-formed. Check for empty sections, orphaned elements, or invalid widget types. Remove anything that would break the page builder.

In production, about 98.5% of generations succeed on the first attempt. Another 1% succeed on retry. The remaining 0.5% need manual review — usually because the AI generated content that's valid structurally but doesn't make sense contextually.

Results

Some numbers from production:

Metric	HTML generation	JSON + translator
Valid output rate	~88%	~98.5%
Editable in page builder	No	Yes
Theme-compatible	Fragile	Fully
Average generation time	~45s	~60s (two passes)
User edit rate after generation	~15%	~65%

The last metric is the most telling. When users receive a generated page they can actually edit (because it's native Elementor), 65% of them make at least one modification. When they receive an HTML blob, only 15% try to change anything — most give up because they can't figure out how.

The extra 15 seconds of generation time (for the two-pass approach + translation) is worth it.

Takeaways

If you're building anything that uses LLMs to generate web content for a CMS:

Don't generate markup. Generate structured data and translate it to the target platform's native format.
Define a strict schema. The tighter the schema, the more reliable the output. Give the LLM less room to improvise on structure.
Use two passes. Structure first (low temperature), content second (higher temperature). Mixing them in one pass increases both structural errors and content blandness.
Build a robust translator. The translator is where the real engineering lives. It needs to handle every edge case, fill defaults for missing values, and produce output that the visual editor treats as first-class.
Validate at every layer. JSON parsing, schema validation, rendering validation. Each layer catches a different class of errors.

The AI generates the what. The translator handles the how. Keeping them separate is what makes the system reliable at scale.

I've been running this architecture in production at Megify, where we generate WordPress sites and WooCommerce stores from text descriptions. If you want to see how the structured data maps to actual WordPress constructs, there's a technical overview here.

Happy to answer questions about the schema design, prompt engineering, or the translation layer.

I Open-Sourced a Figma-to-Avada Shortcode Converter (AI + Claude Code)

Andrea Tasselli — Wed, 11 Mar 2026 16:52:50 +0000

I spent 14 hours last month converting a Figma design into Avada Builder shortcodes. Fourteen hours of matching padding values and clicking through dropdown menus.

So I built a tool that does it with AI. Then I open-sourced it.

Repo: github.com/andreata/figma-to-avada

The workflow

Export Figma frames as SVG
Feed to Claude Code with optimized prompts
Get back paste-ready Avada shortcodes

A page that took 14 hours manually now takes ~30 minutes.

How it maps

The conversion isn't random. SVG structure from Figma maps predictably to Avada's shortcode hierarchy:

Figma frame (auto-layout: horizontal)
  └── Child 1 (width: 33%)          →  [fusion_builder_column type="1_3"]
  └── Child 2 (width: 66%)          →  [fusion_builder_column type="2_3"]
      └── Text layer "Heading"       →  [fusion_title size="2"]...[/fusion_title]
      └── Text layer "Body"          →  [fusion_text]...[/fusion_text]
      └── Rectangle (fill: #432df4)  →  background_color="#432df4"

Figma's auto-layout properties (padding, gap, direction) translate almost 1:1 to Avada's container settings. The AI reads these from the SVG attributes and generates the correct parameters.

What's in the repo

Optimized prompts — this is where the value is. Generic prompting gives you generic output. The prompts in /prompts contain:

Avada's complete shortcode syntax and parameter names
Mapping rules from Figma properties to Avada settings
Common patterns (hero sections, feature grids, pricing tables)
Edge case handling (overlapping elements, absolute positioning)

Prompt variants:

File	Use case
`full-page.md`	Entire page conversion
`single-section.md`	One section at a time
`ecommerce.md`	WooCommerce + Avada layouts
`responsive.md`	Mobile + tablet breakpoints
`theme-match.md`	Match existing Global Options

Examples — before/after for a restaurant page, portfolio, and WooCommerce store.

What works well

Container/row/column structure with correct widths
Typography (family, size, weight, line-height, spacing)
Colors (backgrounds, text, borders from Figma color styles)
Spacing (padding/margin calculated from the design)
Avada-specific elements (buttons, pricing tables, testimonials, counters)
WooCommerce grids
Per-element custom CSS

What doesn't work (yet)

Complex animations (Avada's animation system is limited anyway)
Mega menus
Dynamic content / conditional logic
Designs that are 100% custom CSS with no Avada element equivalents

Realistically it covers 80-90% of the work. The remaining 10-20% needs human judgment.

Tips for best results

Name your Figma layers. "hero-section" and "cta-button" give the AI context. "Frame 47" and "Rectangle 12" don't.

Use auto-layout. The AI reads auto-layout properties directly. Without them, it has to guess the layout intent from absolute positions — which works but is less reliable.

Stick to Avada's grid. Avada uses 1/6 columns. If your Figma uses a 12-column grid, the mapping is nearly perfect. Odd column widths require creative workarounds.

Use Google Fonts. If the font exists on Google Fonts, the AI generates the correct Avada typography settings automatically.

The prompt engineering is the product

I want to be transparent: the "tool" is really a set of well-crafted prompts + a workflow. There's no custom software, no API wrapper, no build step. It's Claude Code + structured prompts + SVG files.

That's intentional. The AI does the heavy lifting. The prompts provide the domain knowledge. You provide the design. The combination is what makes it work.

If you have better prompts for specific Avada elements or edge cases, PRs are very welcome. The more Avada-specific knowledge we encode in the prompts, the better the output gets.

Why I open-sourced it

The Figma-to-Avada conversion problem is universal in the WordPress agency world. Keeping this internal would save me hours. Open-sourcing it saves everyone hours. And selfishly, more users means more edge cases discovered, more prompt improvements contributed, and a better tool for everyone — including me.

Repo: github.com/andreata/figma-to-avada

MIT license. Star it if it's useful.

If you work with Avada and Figma, I'd love to know: how do you currently handle this conversion? Manual rebuild? Some other workflow? Curious how others approach it.

WordPress in 2026: Why I Still Choose It Over Custom CMS (And When I Wouldn't)

Andrea Tasselli — Mon, 09 Mar 2026 15:05:16 +0000

I've built products on both sides. Custom CMS from scratch, headless architectures, static site generators, and WordPress. After three years of running a platform that generates WordPress sites programmatically with AI, I have opinions. Strong ones.

This isn't a "WordPress is the best" post. It's a breakdown of when WordPress is the right engineering decision, when it's not, and why the answer in 2026 is different from what it was in 2020.

The Case Against WordPress (Let's Get This Out of the Way)

I'll start with the reasons NOT to choose WordPress, because I think intellectual honesty makes the rest more credible.

The database schema is a mess. wp_posts stores pages, posts, attachments, revisions, menu items, and custom post types all in one table. wp_postmeta is an EAV anti-pattern that makes queries slow at scale. If you're building something that needs to handle 500K+ records with complex filtering, you'll fight WordPress every step of the way.

The plugin ecosystem is a double-edged sword. 60,000 plugins sounds great until you realize that 90% of them are poorly maintained, inject inline styles everywhere, and load 14 JavaScript files on every page. Plugin conflicts are still the number one cause of WordPress sites breaking.

PHP. I know, I know. PHP 8.3 is actually good. But if your team writes TypeScript all day and you're building a product from scratch, forcing them into PHP is a cost. Hiring PHP developers is harder than hiring JS developers in most markets.

The admin UI shows its age. Gutenberg improved things, but the WordPress admin still feels like a 2010 app compared to modern CMS dashboards. If your end users are developers or tech-savvy people, they'll notice.

If any of these are dealbreakers for your specific project, stop reading and go build your custom CMS. Seriously. There's no shame in it.

Why I Still Choose WordPress (For Most Projects)

Now here's why, despite all of that, I keep coming back.

1. The Ecosystem Is the Product

WordPress isn't a CMS. It's a platform with an ecosystem. And in 2026, that ecosystem is the moat.

WooCommerce alone powers roughly 25% of all ecommerce stores. That means every payment gateway, every shipping provider, every accounting tool, every marketing platform has a WordPress integration. Not "we'll build one if you ask" — it exists, right now, maintained and documented.

When I built Megify, I evaluated building a custom CMS. The AI generation part would have been easier — I could design the data model from scratch, optimize every query, skip all the WordPress legacy cruft.

But then I listed everything I'd need to rebuild:

Ecommerce (products, cart, checkout, payments, shipping, taxes, refunds)
SEO (sitemaps, meta tags, schema markup, redirects)
Email integration (transactional, marketing, automation)
Forms (contact, lead gen, multi-step)
Analytics integration
Caching and CDN
User management and roles
Media management and optimization
Multilingual support
Accessibility compliance

That's not a CMS. That's a decade of work. WordPress gives you all of it, battle-tested at scale, for free.

2. Portability Is a Feature

This is underrated and I'll die on this hill.

When a user creates a site on Megify, they get a standard WordPress installation. Full admin access. SSH. SFTP. WP-CLI. Database access. They can install any plugin, any theme, export their entire site, and move it to literally any hosting provider on earth.

If Megify disappeared tomorrow, their site would keep working.

Try doing that with Wix. Or Squarespace. Or Webflow. Or any proprietary CMS.

Portability isn't just a philosophical stance — it's a sales argument. When I tell a potential customer "the site is yours, no lock-in, you can leave anytime," the trust barrier drops dramatically. They're not buying into a platform. They're getting a WordPress site with AI superpowers.

3. Programmatic WordPress Is Underrated

Here's what changed my mind about WordPress for product development: WP-CLI and the REST API.

Most developers interact with WordPress through the admin panel. Click, click, click. It feels slow and manual because it is.

But WordPress is fully programmable. Every operation — creating posts, configuring plugins, setting options, managing users — can be done via CLI or API. When you treat WordPress as a headless backend that you configure programmatically, the experience is completely different.

Our generation pipeline doesn't touch the admin UI. It provisions a container, installs WordPress via CLI, configures plugins via CLI, creates pages and products via the REST API, and sets theme options via the database directly. The entire process takes 90 seconds and produces a fully configured site.

# This is what "creating a WordPress site" looks like in 2026
wp core install --url="$DOMAIN" --title="$TITLE" --admin_user="$USER"
wp plugin install woocommerce elementor --activate
wp option update blogdescription "$TAGLINE"
wp rewrite structure '/%postname%/'

If you're evaluating WordPress and your mental model is "click through the admin panel," you're evaluating the wrong thing.

4. WordPress + AI = The Complexity Problem Is Solved

The number one argument against WordPress has always been complexity. "It's too hard for non-technical users."

In 2026, this argument is dead.

AI can generate the initial site (design, content, structure) from a text description. AI can handle ongoing modifications through natural language — "add a testimonials section," "change the color scheme," "create a new product category." The visual editor (Elementor, Gutenberg) handles everything else.

The user never needs to see PHP, never needs to understand hooks and filters, never needs to configure a database. They get the full power of WordPress with an interface that's simpler than Wix.

This is what we built with Megify — and it's what I think the future of WordPress looks like for 80% of users. The platform stays powerful; the interface becomes invisible.

When I Would NOT Choose WordPress

Being honest about limitations is more useful than cheerleading.

High-performance web apps. If you're building a SaaS dashboard, a real-time collaboration tool, or anything that needs sub-100ms response times with complex state management — don't use WordPress. Use Next.js, SvelteKit, or whatever your team is fastest with.

Developer-facing products. If your users are developers who expect Git-based workflows, preview deployments, and infrastructure-as-code — WordPress will frustrate them. Look at headless CMS options like Sanity, Strapi, or Payload.

Pure API backends. If you just need a content API with no frontend, WordPress is overkill. A headless CMS or even a simple database with an API layer is cleaner.

Very large content databases. If you're dealing with millions of records that need complex querying and relationships, the wp_postmeta EAV pattern will be your enemy. Use a proper relational schema.

When your team actively dislikes PHP. Team happiness matters. If forcing WordPress on a team that hates PHP results in slower development and worse code quality, the ecosystem benefits aren't worth it.

The Decision Framework

Here's the mental model I use in 2026:

Choose WordPress when:

Your project serves end users who need to edit content
You need ecommerce (WooCommerce is unbeatable for SMB)
SEO matters (WordPress SEO tooling is the best in class)
Your users need to own their site (portability matters)
You need integrations with third-party services
Time to market matters more than architectural purity

Choose custom when:

You're building a product, not a website
Performance requirements are extreme
Your data model doesn't fit posts/pages/meta
Your team has strong opinions about their stack (and they're right)

Choose headless CMS when:

You need content management + custom frontend
Your team is frontend-focused (React/Vue/Svelte)
You want Git-based content workflows
Preview deployments are important

A Note on "WordPress at Scale"

People love to say "WordPress doesn't scale." This is technically incorrect and practically misleading.

WordPress.com (Automattic) serves billions of pageviews per month on WordPress. The White House website runs on WordPress. TechCrunch, BBC America, Bloomberg — all WordPress.

What doesn't scale is cheap shared hosting + 47 unoptimized plugins + no caching. That's not a WordPress problem. That's an infrastructure problem.

With proper hosting (containerized, with object caching, CDN, and database optimization), WordPress handles serious traffic without breaking a sweat. I've seen WordPress sites serve 50K concurrent users on a single optimized server.

Final Thoughts

WordPress in 2026 is not the same product as WordPress in 2018. The Block Editor matured. The REST API is solid. PHP 8.x is genuinely fast. The hosting ecosystem (both traditional and managed) is excellent. And AI tools have eliminated the complexity barrier that kept non-technical users away.

The real question isn't "is WordPress good enough." It's "do I need something different enough to justify building it myself?"

Most of the time, the answer is no. And that's not a compromise — it's engineering pragmatism.

Building something interesting with WordPress? Or deliberately chose not to? I'm genuinely curious about the decision frameworks other developers use. Drop a comment — especially if you disagree.

How I Built an AI-Powered System That Generates Full WordPress Sites in Under 5 Minutes

Andrea Tasselli — Thu, 05 Mar 2026 11:16:59 +0000

I've spent the last three years building infrastructure automation tools for WordPress deployments. Somewhere around project number 200, I realized I was solving the same problems over and over — and so was every other developer I knew.

This post is a technical breakdown of how I built a system that automates the entire WordPress site generation pipeline: from server provisioning to AI-driven content scaffolding. No fluff, no hype — just architecture decisions, tradeoffs, and lessons learned.

The Actual Problem (It's Not What You Think)

The bottleneck in launching a WordPress site was never "creativity" or "design skills." It was the operational overhead.

Here's what a typical client project looked like before automation:

Task	Time spent	Value added
Server provisioning + DNS	30-60 min	Zero
WordPress install + hardening	20-30 min	Zero
Theme install + child theme setup	15-20 min	Low
Plugin stack (SEO, cache, security, forms, analytics)	30-45 min	Low
WooCommerce + payment gateway config	45-60 min	Low
SSL + performance optimization	20-30 min	Zero
Initial page structure + navigation	60-90 min	Medium
Content creation (copy, images, meta)	2-4 hours	High
Total	6-10 hours	Mostly low

The pattern was obvious: 70-80% of the time went into tasks with zero or low creative value. The same stack, the same plugin configurations, the same performance tweaks — project after project.

I started automating the zero-value tasks first. Then the low-value ones. Then I realized AI could handle the medium-value layer too.

Architecture Overview

The system has three layers, each handling a different part of the pipeline.

Layer 1: Infrastructure Automation

This is the foundation. When a new site is requested, the system:

Provisions a containerized environment with pre-optimized PHP, MySQL, and Nginx configurations. No shared hosting compromises — each site gets isolated resources.
Deploys WordPress with a hardened configuration: security headers, XML-RPC disabled, file editing disabled, auto-updates configured, database prefix randomized.
Installs and configures the plugin stack programmatically via WP-CLI. The stack is opinionated but battle-tested: caching, SEO, security, backup, and performance monitoring — all pre-configured with sane defaults.
Handles SSL provisioning and DNS automatically. No manual certificate management, no waiting for propagation.

The entire infrastructure layer completes in under 90 seconds. What used to take an hour of clicking through admin panels is now a single API call.

Layer 2: AI Content Generation

Once the WordPress environment is live, the AI layer takes over. This is where it gets interesting.

The input is a natural language description of the project. Something like:

"Artisan gelato shop in Florence. We use seasonal ingredients from local farms. We've been open since 1987. We need a menu, an about page, and online ordering."

From this, the system generates:

Site structure: pages, navigation hierarchy, internal linking
Copy: headlines, body text, CTAs, meta descriptions — all tailored to the business type and tone
Layout decisions: which sections go where, what content patterns fit the business type (hero, features, testimonials, pricing, etc.)
WooCommerce configuration (when applicable): product categories, sample products with descriptions and pricing, shipping zones, payment gateway selection

The key architectural decision here was not generating raw HTML or theme files. Instead, the AI outputs a structured JSON schema that maps to WordPress constructs (pages, blocks, custom fields, WooCommerce objects). This means the output is always valid WordPress data, not fragile markup that breaks on the next theme update.

Layer 3: Visual Editing + AI Iteration

The generated site is fully editable through two interfaces:

A drag-and-drop visual editor for people who want direct control
A conversational AI interface where users can request changes in natural language: "Make the hero section taller," "Add a testimonials section after the pricing," "Change the color palette to something warmer"

Each AI edit produces a diff against the current state, so changes are reversible and auditable.

Technical Decisions and Tradeoffs

Why WordPress (and not a custom CMS)?

I get this question a lot. The short answer: ecosystem and portability.

WordPress powers roughly 40% of the web. Its plugin ecosystem is unmatched. Users can install any of 60,000+ plugins, hire any WordPress developer, and migrate to any host. There's no lock-in.

Building a custom CMS would have been faster to develop initially, but it would have created a walled garden. I wanted the opposite: generate the site with AI, then give users complete ownership. Full SSH access, full database access, full file system access. Export your site anytime and run it anywhere WordPress runs.

The tradeoff is complexity. WordPress has quirks, legacy patterns, and a database schema that wasn't designed for programmatic generation. Working around these adds engineering cost. But the user value of "this is standard WordPress, you own it completely" outweighs the developer convenience of a custom system.

Why Not Headless?

Headless WordPress is great for teams with frontend developers. But my target users don't have frontend developers — they're small business owners, solo entrepreneurs, local shops. They need something that works out of the box, with a visual editor they can understand.

A traditional WordPress setup with a good theme and block editor gives them exactly that. No build step, no deployment pipeline, no React hydration issues.

AI Model Selection

I use Claude (Anthropic) for content generation. The reasoning:

Instruction following: when I need structured JSON output with specific schemas, Claude is remarkably consistent. Fewer parsing failures, fewer retry loops.
Long context: site generation requires holding the full project context (business description, existing pages, style preferences, product catalog) in a single prompt. Large context windows matter here.
Quality of copy: the generated text reads like it was written by a human copywriter, not a language model. This matters because the output goes directly onto live websites.

I tried several models during development. The main differentiator wasn't "intelligence" — it was reliability of structured output at scale. When you're generating hundreds of sites per day, a 2% parsing failure rate means dozens of manual interventions.

What I Learned

Start with the boring stuff. The infrastructure automation (the least exciting part) delivered the most value. Shaving 60 minutes off every deployment compounds fast.

AI is a first draft machine, not a final product machine. The generated sites are good — genuinely good — but they're starting points. The best results come from users who take the AI output and refine it. The system is designed for this: generate fast, iterate easily.

WordPress is messy and that's fine. I spent months trying to make WordPress "cleaner" before accepting that its messiness is a feature. The ecosystem exists because WordPress is flexible enough to be messy. Fighting it is a waste of time.

The real moat is the integration, not the AI. Anyone can call an LLM API. The hard part is connecting AI output to real infrastructure: DNS, SSL, databases, payment gateways, email, caching, backups. That operational layer is where the actual engineering lives.

Performance Benchmarks

Some real numbers from the production system:

Metric	Value
Time from request to live site	< 5 minutes
Infrastructure provisioning	~90 seconds
AI content generation	~60-120 seconds
WordPress configuration	~30 seconds
Average TTFB (after optimization)	< 400ms
Lighthouse performance score (generated sites)	85-95
Uptime (last 12 months)	99.97%

The Platform

I've been running this system in production as Megify. It's designed for small businesses, freelancers, and agencies who need to launch WordPress sites and ecommerce stores fast.

A few things that might be relevant if you're building something similar:

The AI site generation is exposed through a conversational interface — describe your project and the system builds it
WooCommerce is fully supported: products, categories, payments (Stripe, PayPal), shipping
Every generated site is standard WordPress with full admin access, SSH, SFTP, and WP-CLI
There's a technical breakdown of the WordPress integration if you want to see how the AI-generated output maps to WordPress constructs

What's Next

Three things I'm working on:

Multi-model orchestration: using specialized models for different parts of the pipeline (one for copy, one for layout decisions, one for SEO optimization). Early tests show 15-20% quality improvement over single-model generation.
Automated A/B testing: the system generates variant pages automatically and routes traffic to measure conversion. The goal is sites that optimize themselves over time.
Plugin-aware generation: teaching the AI to understand and configure the 200 most popular WordPress plugins, so it can set up complex workflows (membership sites, booking systems, LMS) without manual configuration.

If you're working on similar problems (AI + infrastructure automation, programmatic CMS generation, or WordPress tooling), I'd love to hear about your approach. The space is moving fast and there's a lot of room for different architectures.