u/Sensitive_Draft_5651

I know a lot of people don't really enjoy starting pages in Gutenberg, or the Site Editor itself, so I built a browser-based WordPress playground where ChatGPT, Codex, or another MCP agent can help you put together your first Gutenberg draft. The idea actually came from the browser-based Plugin Check setup I saw while getting my plugins approved on WordPress.org - I thought it was a really neat way to run WordPress and started wondering what else you could do with it.

Agent Composer - a completely free WordPress plugin - sits between the agent and WordPress. It takes requests from the agent and turns them into native Gutenberg markup, but only using the actions, structures, and rules the site owner allows in the settings, so the AI isn't roaming around WordPress with admin access. Composer keeps the editing controlled and predictable, validates the result, and only creates drafts - only humans can publish.

The playground is here: https://preview.wpsuite.io/

Edit: Fair criticism on the wording. I over-polished the first version, so I shortened it a bit and kept it closer to the actual technical point. This is based on a real implementation we built and run. It's easy to find from my profile if anyone wants to check the context.

------------

Hey everyone,

I've been following the recent WordPress 7.0 / native AI discussion with mixed feelings.

On one hand, AI inside WordPress sounds genuinely useful. On the other hand, the more powerful WordPress becomes on the server side, the less comfortable I feel about exposing the whole stack directly to the public web.

About a year ago, we started moving in a different direction: we kept WordPress as the editorial/admin system, but removed it from the public request path.

The public site is exported as static HTML/CSS/JS and deployed to S3 + CloudFront. Visitors never hit PHP, never touch the database, and cannot attack wp-login, XML-RPC, plugin endpoints, or admin-ajax.

For gated/private content, we use Cognito authentication and CloudFront signed cookies, so specific private URL patterns can still be served from the static site without making WordPress dynamic again.

For many frontend interactions - forms, modals, and interactive blocks - we built our own Gutenberg-native solution, which keeps those features working without requiring protected APIs. The block library is completely free, and if anyone is interested, I'd be happy to share the WordPress.org link.

For things that genuinely need backend processing - automations, chatbots, AI tools, forms, and other dynamic services - we use separate serverless APIs authenticated with Cognito/JWT, or at least protected by reCAPTCHA where authentication would be unnecessary or create too much friction.

The biggest wins so far:

• no public PHP execution
• no public database access
• no wp-login attack surface
• much less plugin risk
• cleaner frontend output
• faster global delivery through CloudFront
• fewer "plugin update broke the site" situations

Of course, this is not right for every project. WooCommerce, complex dashboards, LMS platforms, forums, and highly personalized apps may still need a dynamic runtime. But for business sites, documentation, marketing pages, gated content libraries, and lightweight member areas, static + serverless WordPress feels like a much safer default.

I think WordPress is still excellent as a content/admin system. I'm just less convinced it should always be the public runtime. Happy to compare notes if anyone is working on similar static/serverless WP setups.