django-comments-xtd is a pluggable Django application that adds threaded, moderated comments to a Django project, and it is intended for Django developers and teams who want a self-hosted comment system inside their own application rather than a hosted third-party service.
What it is
django-comments-xtd lives in the Django ecosystem and is published as a pluggable application, which means it is installed alongside an existing project and attached to the models that should carry comments. It extends the original Django Comments Framework, distributed as django-contrib-comments, rather than starting from a blank slate. Where the bare framework gives a project a basic comment model and the surrounding plumbing, this package layers nesting, notifications, moderation, reactions and frontend integrations on top of it. It is the layer a team adds instead of writing those features itself against the baseline framework.
The concrete problem it solves is the gap between a working comment table and a comment system that a real audience can use. A Django project using only django-contrib-comments has no nesting, no way to notify a commenter that someone replied, no way to let an anonymous visitor comment without exposing the database to spam, and no API for a JavaScript frontend. django-comments-xtd supplies each of those, and it does so on a per-app.model basis so that different models in the same project can be configured differently. Authentication is deliberately not a prerequisite: an unauthenticated visitor can post, but the comment reaches the database only after email confirmation.
Key capabilities
- Thread support, so comments can be nested, with a customizable maximum thread level configured per
app.model.
- Optional notifications to commenters when a follow-up comment is posted, delivered by email, plus mute links that let a recipient cancel those notifications.
- Comment confirmation via email for users who are not authenticated, with the guarantee that comments hit the database only after they have been confirmed.
- Comment reactions, comment votes and comment flagging, each enabled per
app.model, with the set of reactions visitors may choose being customizable and defaulting to thumb up and thumb down.
- Several bundled themes for rendering the comment interface.
- A plain vanilla JavaScript plugin, a ReactJS plugin, and Bootstrap 5.3 styling for building the frontend.
- A ReST API that supports a custom frontend of your own instead of the supplied clients.
Who uses it and how
- Django sites running any of the officially supported versions, Django 6.0, 5.1, 5.0 and 4.2, on Python 3.14, 3.13, 3.12 or 3.11.
- Projects that already depend on the Django Comments Framework and want threading, notifications and moderation without replacing their existing comment models.
- Sites with anonymous readership, where the email confirmation step is the mechanism that keeps unconfirmed and unauthenticated submissions out of the database.
- Applications whose frontend is not Django templates, using the ReST API to serve comments to a ReactJS or plain JavaScript client.
- Teams evaluating the package, who can read the tutorial and examples in the documentation and inspect the
e2e_project under the main branch.
Getting started
The package is installed as django-comments-xtd, which requires django-contrib-comments version 2.2 or later and djangorestframework between 3.12 and 3.17. The tutorial and example projects in the documentation at django-comments-xtd.readthedocs.io cover configuration and running.
How it compares
The only comparable tool named in this material is django-contrib-comments, the framework this project extends rather than competes with. The distinction is scope: the base framework provides the comment model and core plumbing, while django-comments-xtd adds threading, email notification and confirmation, moderation flags, reactions and the ReST API on top of it.
When to use it — and when not to
A self-hoster must run a Django application, a database, and working outbound email, because confirmation messages and follow-up notifications both depend on SMTP. Anyone who wants comments without operating that stack, or who needs a stable feature-frozen API today, should look elsewhere. Work on version 3.0 is happening on the main branch with points still listed in TODO.md, and the repository carries 68 open issues, so the current stable line is the safer choice for production.
