Flow interaction layer
Add Discussions, Replies and Ratings to a Static WordPress Frontend
Static publishing removes the live WordPress comment and rating runtime along with PHP and database writes. Flow keeps content-bound discussions, nested replies, ratings and moderation live through browser-side components backed by a separate service.
Short answer Place the discussion and rating experience in WordPress, then let the published frontend read and write interaction state through Flow. The static page remains cacheable while threads, replies, rating values, aggregation, moderation and optional identity stay dynamic.
The static interaction gap
A static page can render old interaction data, but it cannot accept new state by itself
Comments and ratings are not presentation-only features. They require persistent writes, content identity, participant identity where needed, moderation rules and derived state such as rating totals or averages.
Discussion state
Nested replies need durable relationships
A discussion tree must preserve which reply belongs to which parent and which content item owns the thread. An exported HTML snapshot cannot keep that relationship current after visitors add new replies.
Rating state
Ratings need both writes and aggregation
A rating control is useful only when individual values can be stored and a current result can be calculated or returned to the frontend. That aggregate is application state, not static page metadata.
Permissions
Moderation and owner actions depend on identity
Editing a contribution, deleting it, approving publication or limiting who can rate requires rules about the current viewer. Those controls should live in the interaction runtime rather than in static HTML.
Architecture rule Treat discussion, replies, ratings, aggregation and moderation as one interaction layer attached to WordPress content, with identity added only where the participation model requires it.
Interaction runtime
Bind persistent discussion and rating state to the WordPress content record
WordPress authors the page and places the Flow components. The public frontend remains static while the browser calls Flow-backed endpoints for current interaction state and writes.
WordPress editor | page / post content | Flow Discussion | Flow Form reply / rating input v Static publish | v S3 + CloudFront page | v Flow browser runtime | +--> discussion thread state | nested replies / moderation / owner actions | +--> rating state | individual values / persisted result / aggregation | +--> workflow actions where configured | v Flow Backend / configured API ^ | optional Gatey + Cognito identity
Confirmed scope Flow supports content-bound discussions, nested replies, viewer-dependent edit/delete behavior, moderation and rating fields. The exact aggregation, scoring rules and downstream workflow behavior should follow the configured Flow backend rather than be assumed to match a third-party review platform.
Implementation
Define the participation model before exposing live interaction
Start with content binding and state ownership, then decide who may write, moderate or rate.
- Bind interaction to the correct content — Place Flow Discussion and any related Flow form on the page or post that owns the interaction so the backend can load and persist state against the intended record.
- Define identity and moderation rules — Choose public or authenticated participation, owner edit/delete behavior, moderation requirements and any separate moderator privileges. Use Gatey/Cognito only when the project needs authenticated viewer identity.
- Define rating persistence and aggregation — Choose which rating input is collected, whether repeat ratings are allowed, how the backend stores the values and which aggregate or score the frontend should display.
- Connect workflow actions only where useful — If a discussion or rating should trigger review, notification, scoring, approval or another action, add that workflow after the interaction model itself is stable.
When Flow is a strong static interaction layer
Good fit
Use it when the site must stay static but participation must stay live
- Pages or posts need comments, nested replies, ratings or review threads after static publishing.
- You want the interaction UI to remain part of the WordPress-authored experience instead of embedding a separate hosted community product.
- The project benefits from combining discussion, rating and workflow state in a backend that can remain independent from the public WordPress runtime.
Another model may be simpler
Use native or hosted interaction when
- The site remains a conventional dynamic WordPress installation and native comments already fit the moderation model.
- A third-party hosted discussion or review service is acceptable and its identity/data model is preferred over owning the backend relationship.
- The site only needs occasional feedback, making a simple form or external community channel easier to operate than persistent discussion and rating state.
Buyer questions
Static WordPress discussions and ratings FAQ
Can a static WordPress site support nested discussions?
Yes. Flow Discussion loads and writes content-bound discussion state through a live backend, so nested replies can stay current while the page itself is served as static HTML.
Can ratings persist after static export?
Yes. Rating input can be submitted through Flow to a backend that stores the values and returns the current aggregate or other configured result to the frontend.
Can users edit or delete their own replies?
Flow Discussion supports viewer-dependent owner actions and separate moderation behavior. The available actions depend on the identity and permission model configured for the implementation.
Do discussions and ratings require login?
Not necessarily. The participation model can be public, authenticated or mixed. Gatey and Amazon Cognito can provide identity when owner-specific actions, protected participation or other authenticated behavior require it.
WP Suite Flow
Keep discussion and rating state live after WordPress becomes static
Use Flow for content-bound threads, nested replies, ratings and moderation, then connect the interaction to identity or workflow services only where the project needs them.