WP Discourse: turning WordPress posts into Discourse topics

What the plugin actually does, and what it refuses to do

WP Discourse acts as an interface between a WordPress site and a Discourse community, and the second line of the README is the one to read twice. The plugin is not a substitute for Disqus-like commenting systems.

That sentence sets the boundary for the whole project. A Disqus-style comment system is a small widget that stores comments in its own database next to the post. WP Discourse does the opposite: it treats Discourse as a separate application with its own user base, its own reputation system and its own moderation, and the WordPress post becomes the thing the forum talks about. A reader who wants to participate ends up in your forum, not in a comment box.

So the audience is a site that already has, or is willing to run, a Discourse instance and wants its blog and its community to be one thing rather than two. The FAQ makes the prerequisite explicit: the plugin does not install Discourse for you, and you need to set up a Discourse forum first, either by following the install guide or by using the one-click application on DigitalOcean.

Three capabilities are described in the README.

The first is automatic topic creation. When a new blog post is published, the plugin creates a forum topic for discussion about it. The post content becomes the topic's starting point, so the discussion lives in the forum with the post attached to it rather than embedded in the post.

The second is account association. The plugin associates WordPress author accounts with their respective Discourse accounts, and importantly it does not require DiscourseConnect for this. That is a meaningful distinction, because DiscourseConnect is the optional and invasive part.

The third is embedding replies back. Replies from the forum discussion can be embedded in the WordPress blog post, and you select which replies to display based on post score and commenter trust level, with the criteria documented in the docs.

That filter is the interesting design decision. Embedding every reply in the post duplicates the forum into the blog, which is noise. Filtering by score and trust level lets a well-liked answer surface on the post while the argument continues in the forum.

The primary language is PHP, the licence is GPL-3.0, and the homepage is discourse.org. Two live sites are listed: blog.discourse.org and boingboing.net.

DiscourseConnect, and why it is the part to be careful about

The plugin also comes with optional DiscourseConnect functionality, which lets you use your WordPress site as the DiscourseConnect provider for your Discourse forum.

The README is direct about the consequence. This will override Discourse's native, and powerful, login flow, and it is only recommended for use cases that strictly require such a setup, for example a site that is already using WordPress for large scale user management.

That is the whole trade in three sentences. DiscourseConnect is a single sign-on system, and the direction the plugin supports here means WordPress holds the accounts, and every login to the forum goes through your blog's login form.

The upside is real when it applies. If your organisation already runs WordPress for staff and student accounts at scale, making WordPress the identity provider avoids a second password store, a second reset flow and a second set of invitations to administer. If you already have a large user base in WordPress, that is a substantial simplification.

The cost is that you give up Discourse's own login flow, which the README calls powerful, and you inherit the properties of WordPress's user system for your forum. User management, password policy, two-factor handling and account recovery all become WordPress's behaviour rather than Discourse's. Two systems that were designed with different assumptions about identity are now sharing one, and the forum inherits the weaker assumptions of the pair.

The word optional in the README is the operative one. The commenting integration works without it, and account association between WordPress authors and Discourse accounts also works without it, as the README states explicitly. So the sensible order of operations is to run the integration first, confirm the discussion workflow is what you want, and treat DiscourseConnect as a separate decision with its own risk assessment.

Installing the plugin three ways

Installation is ordinary WordPress plugin installation, and the README gives three routes.

From the WordPress dashboard, you visit Plugins, Add New, search for WP Discourse, and activate WP Discourse from your Plugins page. From wordpress.org, you download WP Discourse, upload the wp-discourse directory to your /wp-content/plugins/ directory, and activate it from the Plugins page.

The Composer route is for sites that manage WordPress with Composer. You add WP-Discourse to the project's dependencies.

composer require discourse/wp-discourse ~1.3.2

Or you add it manually to your composer.json.

{
  "require": {
    "php": ">=5.4.0",
    "discourse/wp-discourse": "~1.3.2"
  }
}

The version constraint in both cases is worth noting. The Composer instructions point at ~1.3.2, while the tagged GitHub releases listed in the repository metadata are older numbers, with 0.7.0 from 2016 and 0.6.6 from 2015. The package.json in the repository carries version 1.0.0 and a licence field of GPL V2, and the README notes that the plugin requires PHP 5.4.0 or above.

For more detailed setup, the README links to the WP Discourse plugin installation and setup page on the Discourse meta site.

One thing the README does not do is document where the site URL, API key and other connection settings come from, or what the settings screen looks like. Those are the first things you will need after activation, and the plugin's own configuration screen is the place to find them.

Hosting the forum and the blog separately is the recommended shape

One of the FAQ answers is a design recommendation rather than a fact, and it is worth taking seriously.

Do WordPress and Discourse have to be installed on the same server? No. The plugin uses the Discourse API, so your forum and blog can be hosted separately and the integration still works. In fact, the README strongly recommends hosting the two applications separately, since their hosting requirements are very different.

That is a small sentence with real consequences. Discourse is a separate application with its own upgrade cycle and its own hosting requirements. WordPress with a plugin is a PHP application on shared hosting in many cases. Putting a Discourse instance on the same box as a WordPress site means the forum's memory appetite competes with the blog's traffic, and every Discourse upgrade becomes a WordPress site's problem as well.

Separating them also means the plugin's dependence on the Discourse API becomes a network dependency rather than a function call, so the blog and forum are only as available as the link between them. That is the price of the separation, and it is the price that buys independent scaling, independent upgrades and independent hosting choices.

The plugin's own file layout reflects a substantial codebase rather than a thin bridge. There are admin/, lib/, templates/, blocks/, assets/, js/, css/ and tests/ directories, a scoper.inc.php file for namespacing bundled dependencies, an uninstall.php, and vendor_namespaced/ for vendored libraries. The templates/ directory is what the FAQ refers to when it explains template customisation.

Template customisation and what the plugin leaves fixed

The FAQ does answer one question about extending the output, and it answers it by pointing at the theme.

Is it possible to customize the comment templates? Yes. The html templates used for publishing posts on Discourse and for displaying comments on WordPress can be customized in your theme, and this is done by hooking into the filters that are applied to each template. The README links to the WP Discourse template customization page on the meta site for more detail.

So there are two sides to the integration, and both are themable. The template that publishes your WordPress post to Discourse is a filter, and the template that renders the embedded replies on the WordPress side is a filter. That means you can change what a topic looks like when it is created from a post, and you can change what an embedded reply looks like, without forking the plugin.

This is a genuinely useful property for a plugin whose output is visible on every post of your site. The default rendering is not a black box, and a site with an existing theme already knows how to override filters.

The other FAQ answer is a flat no, and it is worth knowing before you migrate. Can I import old WordPress comments as Discourse comments, that is, replies? No.

So there is no path from a comment archive into a forum. If you are moving from a WordPress site with a comment section, those comments stay where they are. The Discourse side starts empty and is populated by new posts. That is a one-way transition rather than a migration, and it should shape how you plan a cutover, because the traffic and the history of the old comments do not come with you.

Where WP Discourse is the wrong choice

There are three limits, and the first is the one the project states in its own README.

The first is that this is not a commenting system. If your requirement is a lightweight comment form that keeps readers on the blog, this plugin is the wrong shape. It requires a separate Discourse instance that you host and maintain, it creates topics and accounts and posts in a second application, and it moves your readers into that second application to participate. That is a large operational commitment for what many sites treat as a sidebar feature. The alternative in that case is a hosted comment service, which is a service rather than a second application you run.

The second is the coupling of the two applications. Even hosted separately, the two are linked by the Discourse API, and the plugin is at the mercy of the forum's availability for the comment features to render. If the forum is down or slow, the embedded replies on every post of the blog are affected. The README also does not document a caching or offline behaviour for the embedded replies, so the sensible assumption is that they are fetched when the page is served.

The third is the version picture, and here the README and the repository metadata disagree in a way you have to interpret. The Composer instructions ask for ~1.3.2, the package.json in the repository says version 1.0.0 with a GPL V2 licence field, and the plugin licence per the repository metadata is GPL-3.0 while the README states the plugin requires PHP 5.4.0 or above. The recent tagged releases are from 2016 and 2015. The last push was on 2026-09-14, so the code is being worked on, but the released versions are a decade old, and a plugin that touches WordPress authentication and Discourse API calls is exactly the kind of code that needs to track changes in both platforms.

The honest alternative for a WordPress site that wants forum discussion is to run Discourse as your community and link to it, with the blog posts cross-posted by a purpose-built integration or by hand, and the sign-in handled by a well-supported DiscourseConnect setup with Discourse as the identity provider. The difference in approach is that DiscourseConnect is then configured in the direction Discourse expects, and WordPress does not override a login flow it was not designed to own. That gives up the automatic topic-per-post behaviour, which is the feature people actually want from this plugin, so it is a trade rather than a clear winner.

For anyone who only needs comments, a hosted service such as the kind of system the README names as the thing this plugin is not is the honest answer, and it costs one account instead of a second application.

Editorial conclusion

Adopt WP Discourse if you already run Discourse and want your WordPress posts to spawn real forum discussions rather than a comment widget, since it maps WordPress authors to Discourse accounts and lets you choose which replies to embed. Do not adopt it as a Disqus replacement, because the README says plainly that it is not a substitute for Disqus-like commenting systems. Before you install, note the plugin requires PHP 5.4.0 or newer and a separate Discourse instance, and check that the last push on 2026-09-14 is recent enough for your WordPress version.

Frequently asked questions

Official sources

1. discourse/wp-discourse on GitHub
2. License: GPL-3.0
3. Project website
4. README
5. Releases