How best to engage Discourse for a larger WordPress magazine?

Hey. Hey,
I run a larger technology-focused online magazine,, and we’ve tried in the past to bring several community options (notifications, user reviews, karma, etc) to our users. But WordPress doesn’t natively support these features, and third-party solutions always run into problems after a while.

That’s why we decided to leave WordPress purely for the magazine feature, which will just display content. As quickly and cleanly as possible. And completely move all the community stuff for users to Discourse, which handles this job much better.

This setup seems absolutely ideal to me. But we’ve been running the magazine for about 13 years, and in that time we’ve had hundreds of thousands of comments and tens of thousands of registered users. I’d like to hear your thoughts on how to make the Discourse integration the most elegant and, from the users’ point of view, the most effective?


  • The magazine on WordPress runs at
  • We run the Discourse community here
  • we want to use Discourse to manage user accounts, we find it better
  • we publish about 5 to 15 articles every day
  • we have tens of thousands of articles (and we’ve already deleted a lot of them :slight_smile:
  • actively commenting, there are tens to small hundreds of users
  • We have the WordPrees plugin for Discouse set up and everything seems to work fine, the only thing we haven’t set up yet is SSO
    • articles we publish on WordPRess magazine are automatically published to Discourse as hidden

What do I need to address and how do I address it? Can you think of a better solution?

User login
Using WordPress plugins, I’ll set up the DiscourseConnect Client and hope it doesn’t break or block access for my editors :). I hope not. Just kidding, but it’s true that this is about the only place that even after carefully reading the discussions, I’m still not 100% clear.

I’ll hope that if a user wants to log in to the WordPress magazine site (they already have a WordPress account), an account will automatically be created for them in Discourse as well.

If by chance that doesn’t happen, it’s probably OK for me to ask those few dozen users to forget their existing WordPress user accounts and create new ones in Discourse

Comments on the topic of articles
Currently, I haven’t found any elegant way to transfer our users’ comments that are already published in WordPress to the newly launched Discourse. If I am wrong, please direct me.

Therefore, already published comments will remain in WordPress and any new ones will already be published to Discourse.

We will not be transferring comments published to Discourse back under WordPress articles, but will only place a link under each WordPress article that will link to Discourse (for that particular Discourse article).

The way we currently have it, all published articles are carried over to Discourse as hidden and only become visible when someone adds a new comment to it in Discourse. This solution is not bad, but in our case it means that I as admin will see thousands of hidden threads in Discourse :(.

Isn’t there some more elegant way to solve this? For example, that a WordPress article will not be transferred to Discourse as hidden after publishing, but a Discourse thread will be created only when someone clicks on the link below the WordPress article and adds a comment?

That way there wouldn’t be thousands of invisible threads on the forum.

And if it were to be absolutely perfect, then via a “magic link” from WordPress, the Discourse thread would only be created temporarily, and if by chance a comment wasn’t added and the user changed their mind/left, the thread would be deleted after some time.

Thanks for reading this far (I’m sending an AI picture as a reward) and I look forward to your ideas and insights.


The DiscourseConnect client functionality works in a similar way to how other forms of social login work. For example, it’s similar to logging into WordPress through Facebook, but with your Discourse site as the authentication provider instead of Facebook. That means that before users can login to your WordPress site with DiscourseConnect, they will need to create an account on your Discourse site. Not creating a Discourse account won’t prevent any users from logging into your WordPress site though. When the WordPress site is the DiscourseConnect client, the normal username/password login on WordPress is still available.

Since you have a lot of users who are used to logging into your WordPress site, it might be worth considering using your WordPress site as the DiscourseConnect provider for your Discourse site. If you set things up that way, all of your existing users will be able to easily login to your new Discourse site. All they will have to do is click a link on your WordPress site. Details about how to construct a link to do that are here: Create a DiscourseConnect login link.

It sounds like you want to completely move the social aspect of your site from WordPress to Discourse, so possibly that would be a reason to not use your WordPress site as the DiscourseConnect provider. My concern is that requiring users to create new accounts on Discourse, instead of just logging into their WordPress account and clicking a link to access the forum, might prevent some users from joining the new site.

The main thing to be aware of if you use WordPress as the DiscourseConnect provider is that when things are configured that way, it becomes the only login method for Discourse. That means that you can’t have some users logging into Discourse through WordPress and other users logging into Discourse by registering accounts with a username/password on the Discourse site. All users will have to have accounts on WordPress to access the Discourse site.

Let me know if the distinction between using WordPress as the DiscourseConnect client and DiscourseConnect provider is not clear to you.

It’s technically possible, but I don’t think there is a well tested method of doing it. There might be some other members of this community who have ideas about how to approach it.

It might be possible. My sense is that it could lead to problems.

On your Discourse site, you can filter out unlisted topics by adding the following query string to a URL: ?status=listed. For example There is an existing theme component that can be used to toggle between viewing “open” and “closed” topics: Topic Status Filter. If it doesn’t already exist, it would be fairly easy for someone to add “listed” and “unlisted” status’s to that filter. But I guess for that case you would only want the filter to be seen by staff users.

This could be accomplished from WordPress with an API request that was handled by a cron job.


Thank you for your time and response.
About DiscourseConnect it is already clear to me, thank you for the detailed explanation. So let’s set up DiscourseConnect in WordPress as a client.

The old comments probably don’t add enough value to make it worth the effort to transfer them from WordPress to Discourse.

But those discussions based on published articles are still on my mind :). The filter is indeed a solution to the admin not seeing the “hidden” threads, but somehow I can’t give up the idea that there might be another way.

You mentioned that it could lead to problems, would it be possible to list some problem states you are worried about please?

With the API it’s probably a solution, but as we’re not a programmer, I can’t imagine well enough how it would work.

The way I imagine it working is that when a user clicks a link to the (not yet published) Discourse topic, a function would be triggered on the WordPress back end to publish the post to Discourse. Triggering the post to be published to Discourse when a user clicks a link is doable.

The problems I’m imagining:

  • what is the link pointing to if the post hasn’t been published yet? We don’t know the topic’s URL on Discourse until after the topic has been published. Something would need to be developed so that when the user clicks the link, the topic is published in the background, then based on the response that is received from Discourse, the user is redirected to the Discourse topic.

  • I’m not sure what would happen if your site was very busy and many users were clicking links that triggered the publishing of Discourse topics at the same time. It would probably be fine, but it feels like a risk.

Edit: one way to deal with the first issue would be to just let the user know what’s going on and display a “please wait while we publish the topic” message. Once the topic was published, a link to the topic could be generated and the user could be prompted to click it. The process might take a few seconds.


So the whole thing could cater to a little javascript that would place a normal link for engaging in discussion under the article on a WordPress site. First the javascript would call a function (create thread on Discourse, which the WP plugin already does) and show the user that a thread is being created, and when the javascript gets the information from Discourse that the thread is created, it would redirect the user to the comments thread on Discourse.

Is that right, or am I imagining it too simply? :slight_smile:

It would be simpler to not automatically redirect the user, but yes what you have outlined is correct. After the user clicks the link to generate the topic, the script would make periodic requests to get the topic URL from the WordPress server. Once it had the URL, it would redirect the user to the Discourse topic.