Forms for static WordPress
Run Dynamic Forms on a Static WordPress Frontend
Static publishing should not force teams to give up useful forms or bring a public PHP runtime back just to receive submissions. WP Suite Flow keeps form authoring in Gutenberg while the live browser runtime talks directly to the endpoint responsible for submissions, drafts, files and workflows.
Short answer Use Flow when WordPress should remain the place where editors build the form, but production should be served as static HTML and JavaScript. The Flow frontend can post directly from the browser to a configured endpoint, and the optional Flow Backend can provide durable form operations from infrastructure deployed in your own AWS account.
The static form problem
Static WordPress removes PHP from the request path. Your forms need a new runtime boundary.
A static export preserves rendered pages, but server-side WordPress form handlers do not automatically become static-safe application services.
Problem 01
The exported form still expects WordPress to execute
Many conventional form flows rely on PHP, admin-ajax, WordPress REST handlers, database writes or plugin-specific server behavior. If production no longer routes visitors through WordPress, those assumptions must be replaced or the form breaks.
Problem 02
External embeds solve runtime but change ownership
A hosted form service can be an excellent shortcut, but the form experience, submission data and workflow runtime then follow that provider’s operating model instead of the WordPress and AWS architecture you already control.
Problem 03
Custom form APIs become one-off glue
A hand-built endpoint can receive a static form, but projects often accumulate separate code for validation, drafts, uploads, notifications, admin review and downstream integrations as requirements grow.
Architecture implication The key question is not whether static pages can contain a form. They can. The real question is which browser-accessible service owns the dynamic lifecycle after the static HTML has been delivered.
Static-safe runtime
Separate static delivery from dynamic form execution.
Flow is designed around a browser runtime and configurable submission target. Static Publisher can deliver the rendered WordPress site from S3 and CloudFront while Flow continues to call an endpoint that remains live independently of the WordPress/PHP server.
Private / editorial WordPress
└─ Gutenberg + Flow Form
↓ render / publish
Static production frontend
└─ HTML + JavaScript + Flow runtime
↓ browser request
Configured form endpoint
├─ custom API you own
├─ WordPress endpoint, if intentionally kept reachable
└─ Flow Backend in your AWS account
├─ submissions + statuses
├─ save / load drafts
├─ presigned uploads
├─ email + webhooks
└─ workflow events / AI steps
Optional delivery path:
WordPress → Static Publisher → Amazon S3 → CloudFront
Recommended architecture For a fully static production site, keep the public form runtime independent of WordPress. A custom endpoint is sufficient for simple projects. Use the Flow Backend when the site needs durable submissions, draft persistence, admin tooling, templates, workflow automation or a repeatable customer-owned AWS operating model.
Implementation path
Make every dynamic dependency explicit before you publish static.
A static form architecture is easiest to operate when authoring, delivery and execution are treated as separate responsibilities.
- Build the form in Gutenberg — Use Flow Form, Wizard, conditional rules and the field set you need. Keep the editorial experience inside WordPress so content and form structure can be reviewed together before publishing.
- Choose the live submission endpoint — Configure Flow to post directly from the browser to the service that should own the request. That can be your own API or the Flow Backend; Flow does not inherently require submissions to be stored in WordPress.
- Publish the frontend as static output — Use your static publishing pipeline to render and deploy the page and required browser assets. With WP Suite Static Publisher, the supported production direction is S3 and CloudFront delivery while browser-side WP Suite capabilities remain available.
- Add durable workflow features only when needed — Introduce backend sync, drafts, presigned uploads, templates, email, webhooks and event-driven workflows when the process requires them. Keep simple contact flows simple; do not deploy an application backend merely because the page is static.
When browser-to-backend forms are a strong fit for static WordPress
Best fit
Choose this model when WordPress is an editor, not the public application server.
- Production pages are served statically from S3, CloudFront, Netlify, another static host or a similar delivery layer, but visitors still need real forms.
- You want the form to remain Gutenberg-authored instead of replacing it with a separately managed embedded SaaS form.
- The project may need customer-owned AWS submissions, drafts, files, workflow events, webhooks or AI-assisted processing without reopening public access to WordPress.
Another approach may be better
Use a simpler hosted or conventional form path when ownership is not the main requirement.
- The site remains a normal dynamic WordPress installation and the existing form plugin already satisfies the process.
- A hosted form service is acceptable and the team values turnkey form operations more than keeping the runtime inside its own architecture.
- The page only needs a minimal contact endpoint and a small serverless function or hosted form receiver is easier to maintain than a full workflow backend.
Static WordPress forms FAQ
What changes when the frontend becomes static?
Can Flow forms work when WordPress is not serving public requests?
Yes, when the form’s browser runtime can reach its configured endpoint. Flow submits directly from the browser, so the receiver does not have to be the WordPress server. This is the core reason the form experience can survive static publishing.
Does a static Flow form need the WP Suite Flow Backend?
No. Flow can post to any configured endpoint. The Flow Backend is the supported Pro path when you need durable submissions, backend form definitions, admin tooling, drafts, file uploads, templates and workflow automation in your own AWS account.
Where are submissions stored on a static WordPress site?
That depends on the endpoint you choose. Flow does not inherently store submissions in WordPress. Your custom receiver defines its own storage, while the Flow Backend provides its own backend-backed submission model.
How does Static Publisher relate to Flow?
Static Publisher handles rendering and deploying the WordPress frontend. Flow handles browser-side forms and workflow-connected actions. Used together, they let WordPress stay private or editorial while the production site is static and selected dynamic behavior is provided through live APIs.
Static pages, live workflows
Keep WordPress forms useful after static publishing.
Build the form where editors already work, publish the frontend as static output, and connect only the dynamic operations that the visitor experience actually needs.