How I Shipped a Full WordPress Site With an AI Agent

I just delivered a complete WordPress website for a restaurant client, and I built almost all of it by pairing with an AI agent inside my code editor.

Not a landing page. A full site: a custom plugin, a WhatsApp ordering system, a 170-item menu, an Elementor design system, and a proper deploy pipeline to live hosting.

Here is exactly how the process works, the one mistake that broke the live site, and the lesson that would have saved me an entire day.

The Old Way vs the New Way

The old way of building a client WordPress site looks like this: install a theme, wrestle with a page builder, glue on ten plugins, and pray nothing conflicts.

The new way is calmer. I treat the site as two separate things:

• Code - a custom plugin and a child theme. This is version-controlled and flows one direction: local to live.
• Content - the database and uploads. This is edited on the live site and never gets overwritten by my code pushes.

Get that split right and the whole thing stops being scary.

What I Actually Built

Everything with real logic went into one custom plugin, not into functions.php.

The plugin holds the menu, the WhatsApp cart, and the Elementor widgets. The child theme only handles the header, footer, and styling glue. That is it.

Why a plugin and not the theme? Because a plugin survives a theme switch. Your business logic should never depend on which theme is active.

The design system lives in Elementor's Site Settings: global colors, fonts, typography, and button styles. Then I build pages with native Elementor widgets that pull from those globals. Change one color in settings, and it cascades across the whole site.

The Build Loop

I build locally on WordPress Studio. It spins up a local WordPress install in seconds.

One thing worth knowing: Studio runs on SQLite under the hood, with a phpMyAdmin fork adapted to read it. It feels like MySQL, but it is not. Keep that in your back pocket for launch day, because your live host runs real MySQL.

The agent and I drive the whole thing headlessly with WP-CLI. Install plugins, activate the theme, import 170 menu items from a JSON file, even build Elementor pages by script. No clicking around.

The Deploy Pipeline

Here is the setup that makes "build locally, publish live" a one-command job.

Step 1: version only the code.

I init Git at the WordPress root with a .gitignore that tracks nothing except my plugin and child theme. No WordPress core, no uploads, no database.

/*
!/wp-content
/wp-content/*
!/wp-content/plugins
!/wp-content/themes
/wp-content/plugins/*
!/wp-content/plugins/my-plugin
/wp-content/themes/*
!/wp-content/themes/my-child-theme

The result: a repo with 31 files instead of 20,000. Push that to a private GitHub repo and GitHub becomes your source of truth.

Step 2: use one script to publish.

A small deploy.sh rsyncs the plugin and theme to the live server over SSH, then flushes caches. It never touches the live database.

./deploy.sh

That is the whole pipeline. Code flows up. Content stays on live. No manual copying.

The Mistake That Broke the Live Site

Now the part that cost me the day.

For the first launch, I moved the whole site at once. I used WordPress Studio's built-in export. It packages every file plus a standard SQL database into one bundle, and I restored that on Hostinger.

It took 14 hours. A site this small should take 15 minutes. That was the first red flag.

The second red flag: the live site loaded the header, then died with:

There has been a critical error on this website.

I SSH'd in and reproduced the real error with WP-CLI:

Fatal error: Uncaught Error: Class "Elementor\Modules\Interactions\Cache\Interactions_Postmeta" not found

Elementor was calling one of its own classes, and the file was not there.

The bundle had arrived with a nested folder missing, dropped somewhere in the export or restore. Elementor was half-installed. Every front-end page crashed on it.

The fix took two minutes:

wp plugin install elementor --version=4.1.4 --force
wp rewrite flush --hard
wp elementor flush-css

Force-reinstalling Elementor pulled a fresh, complete copy from source. Site back up.

Do Not Move a Site as One Big Blob

Here is what I should have done from the start, and what I will do every time now.

Do not trust transferred plugin files, not even from an official export. Moving every file as one bundle, yes, even Studio's own export, can silently drop nested files in transfer or restore. You will not know until something fatals.

Instead:

1. Start with a blank WordPress install on the host.
2. Install core and plugins fresh from source with WP-CLI. Clean, complete files, guaranteed.
3. Deploy your custom code with the deploy script.
4. Move only the database. Studio exports standard WordPress SQL, so import that into MySQL.
5. Run search-replace for the domain and rewrite flush for permalinks.

Files come from source. Only the data travels. That one change removes the exact failure I hit.

The even better version is to do the blank install, hand the agent SSH access, and let it run the migration with WP-CLI: fresh plugin installs, a database import, a search-replace, and a permalink flush. Ten minutes, no dropped files, no 14-hour archive.

The Takeaway

An AI agent can deliver a full WordPress site now: the plugin, the design system, the pages, and the deploy pipeline. That part is real.

But it does not remove the fundamentals. You still have to respect how WordPress works. Split code from content. Version the code. Migrate the database, not a mystery blob. Reinstall heavy plugins from source after any big move.

Do that, and shipping updates to live becomes one command instead of one long, nervous afternoon.