FluentComments - AJAX Comments, Anti-Spam & Comment Email Notifications

It is free, and there is no pro version. Every feature listed on this page is in the free plugin: the spam protection, all five emails, the template designer and the block. Nothing is held back, and the whole thing is GPLv2 open source on GitHub.

By making the submission itself expensive to fake. Posting a comment requires a short lived, cryptographically signed token that is issued in a separate request and tied to a session cookie, so it cannot be replayed or reused. On top of that there is a honeypot field with an install specific name, a minimum time between opening the form and submitting it, and rate limiting keyed per session with a per IP backstop. Anything posted straight to the default WordPress endpoint without our fields is refused outright. Suspicious submissions are scored and held for moderation rather than thrown away, and every threshold can be changed with a filter.

No. FluentComments is built so your readers never have to prove they are human. The checks happen between the browser and your server, not in front of the person trying to leave a comment.

Yes. Akismet inspects the comment itself and needs nothing from the form, so it runs normally alongside FluentComments.

FluentComments renders its own comment form, so a field another plugin wants to add, like a CAPTCHA or an extra question, is never printed on the page. Because nobody could fill that field in, running its validator anyway would reject every comment on your site. So those validators are skipped for the duration of a FluentComments submission. If you want to keep another plugin's check, add its callback to the fluent_comments/allowed_comment_hooks filter and render its field with the fluent_comments/form_fields action.

Yes. Add the FluentComments block in the Site Editor, or use the [fluent_comments] shortcode. The plugin never edits your templates on your behalf. But the settings screen does work out which template each post type renders through, looks inside it and its template parts, and tells you which ones still need the block.

Yes. Drop the [fluent_comments] shortcode into any builder's shortcode or text widget and the full comment list and form render there.

Yes, and it is designed for it. Nothing visitor specific is printed into the page, so a cached comment form is still a valid one. There is no security nonce anywhere in the plugin, which means a form served from cache can never fail with the "your session has expired" error that nonce based forms hit. Everything per visitor is fetched on demand, only when someone actually goes to comment.

No. The first page of comments is rendered into the page itself, so a visitor who only reads never triggers an extra request. There is no webfont, no external service and no third party script. Comments load in pages rather than all at once.

Yes. FluentComments uses the normal WordPress comments table and the normal WordPress comment functions. Nothing is migrated, copied or moved. These are your existing comments, displayed and protected better. Deactivate the plugin and your comments are still exactly where they were.

Yes. Every color, spacing value and radius is a CSS custom property, so a handful of --fcom-* overrides in your theme will restyle the whole thing. The block also exposes its title, avatars, colors and border radius in the editor sidebar.

Yes, with one exception. Threading depth, moderation keywords, disallowed keywords, the link limit, "comment author must have a previously approved comment", "users must be registered and logged in": all of them are real WordPress options that FluentComments reads and writes in place. The most useful ones are surfaced on the FluentComments screen so you do not have to go hunting for them. The exception is "Comment author must fill out name and email", which FluentComments always applies to its own form whatever that box is set to. See the question below for why.

Yes, all five of them. Rewrite the subject and body of any email, use smartcodes like {{comment.author}} and {{post.title}}, preview it against a real comment from your site, and set a shared logo, color scheme, footer and From/Reply-To address for all of them. WordPress's own two notices are left untouched unless you explicitly choose to replace them.

Yes. Use the fluent_comments/form_fields action to render them and fluent_comments/validate_submission to check them. They work identically on the block, the shortcode and the classic template. Because fields ship with the per request session payload rather than the cached page, anything time sensitive in them stays fresh.

Yes, unless they are logged in. FluentComments always asks a logged out commenter for both, and it does not follow the WordPress "Comment author must fill out name and email" setting, which is why that option is not on our settings screen. The reason is the notification emails: every one of them is addressed by the commenter's email, so an anonymous comment quietly opts its author out of the reply notifications everybody else in the thread receives, and leaves you nothing to moderate on. Logged in commenters are never asked, because WordPress already has both from their account. The WordPress setting itself is untouched and still applies to any post type FluentComments is not handling.

Usually not. Most managed hosts, and the Cloudflare plugin, put the visitor's real address into REMOTE_ADDR for you, and FluentComments reads it from there. If yours does not, every visitor looks like the same address. The limit that matters follows a per visitor cookie rather than the IP, so nobody gets locked out, but the loose per IP ceiling then applies to the whole site at once. You can opt into reading proxy headers: add_filter('fluent_comments/trust_proxy_headers', '__return_true'); Only do that when your origin server cannot be reached directly, bypassing the proxy. This setting trusts the header rather than verifying the proxy sent it, so on a directly reachable origin a visitor could set the header themselves and sidestep the per IP limit. It is also worth narrowing fluent_comments/proxy_ip_headers to the one header your proxy actually sets.