Support » Plugin: Disqus Comment System » [Plugin: Disqus Comment System] DISQUS disregarding per-post comments allowed setting

Viewing 10 replies - 1 through 10 (of 10 total)
  • Hi Artem,

    To clarify, did you close comments in WordPress or in Disqus itself?

    – If the former, would you kindly verify that the post is closed in the Edit Post window? See for more on that. Mainly what we’re looking for is to make sure the “Allow Comments” checkbox is no longer enabled.

    (I realize you likely already know all of this; these links are mostly to make sure we’ve covered all the bases and also for posterity.)

    – If the latter, have you tried clicking the Settings icon at the top of the embed (while not using Disqus 2012) > clicking “Close thread”?



    Tyler, I closed it in WP by clicking the very same checkbox you’re talking about and unchecking it.

    Closing directly in the Disqus form does work fine. However, the above should be working instead.

    Tyler, I looked through the code, and I’m not sure I follow its logic.

    What is the expected result here? I would expect to see a Disqusified comment list with the exact same words “Comments are closed” as you’d get if you closed comments from within Disqus.

    Looking through the code, I have a suspicion that instead the intention is to not load Disqus at all and rather show the theme’s comment template instead. I may be missing some logic, but the functions I was looking at are dsq_comments_template() and dsq_can_replace().

    Specifically, I verified that $post->comment_status in dsq_comments_template() returns “closed” correctly. The logic then doesn’t enter either if statement and proceeds to set $EMBED=true (see below, I added a few debug statements, out of which only dsq1 was printed).

    The code enters dsq_can_replace() in the 2nd if clause and returns true at else if ( 'all' == $replace ) { return true; } meaning Disqus can indeed replace and the form is embedded.

    This is confusing behavior, but then again, I’m not sure what the end result should be – in my opinion the correct logic should be to pass an additional parameter to the JS form that embeds comments which would then disallow showing of the comment entry field but otherwise show all the comments from Disqus and *not* the local db.

    If the idea behind the logic is indeed what I think it is now, the theme comments would be shown which means comments from the local database, which can be vastly out of sync compared to Disqus due to moderation, editing, spamming, etc. Either way, neither behavior is happening, and the Disqus form shows itself with an open comment box.

    If you need to take a look at all the variables (including disqus_replace = all), I pasted them in the original report.

    // ugly global hack for comments closing
    $EMBED = false;
    function dsq_comments_template($value) {
        global $EMBED;
        global $post;
        global $comments;
    error_log("dsq1: " . $post->post_title . " " . $value . " " . $post->comment_status);
        if ( !( is_singular() && ( have_comments() || 'open' == $post->comment_status ) ) ) {
    error_log("dsq2: " . $post->post_title . " " . $post->comment_status);
        if ( !dsq_is_installed() || !dsq_can_replace() ) {
    error_log("dsq3: " . $post->post_title . " " . $post->comment_status);
            return $value;
        // TODO: If a disqus-comments.php is found in the current template's
        // path, use that instead of the default bundled comments.php
        //return TEMPLATEPATH . '/disqus-comments.php';
        $EMBED = true;
        return dirname(__FILE__) . '/comments.php';

    Hi Artem,

    We’re looking at the same things and coming to similar conclusions. My hunch is that the logic for how/when to replace comments simply needs a bit of updating.

    As for Disqus disregarding equivalency of comment status (either enabled or disabled) in WP itself, this was never how the plugin was meant to be used. Once the plugin is installed, comment threads should be moderated in all senses via the plugin itself and its functionalities; in this case that means the plugin was designed with the assumption that comment threads would be opened/closed in Disqus itself. Fragmenting moderation actions is something we try to avoid and, if anything, we’re looking to make the plugin feel more native.

    We’re still discussing how this could be implemented but the bottom line is we want the overall UX to be more obvious, elegant, and easy. In the meantime you’ll want to continue closing comment threads via Disqus itself.


    Tyler, I’m sorry but the 2nd part of your answer directly contradicts what’s written here:

    Specifically: “Using the WordPress plugin?
    Disqus will respect the WordPress settings with regards to closing comment threads.
    If you’re using WordPress, you can close comments by disabling comments for each post, or setting an Automatic closing timer in your WordPress discussion settings.”

    Imagine a blog with 500 closed comments – you can’t expect people to close them all manually in Disqus one by one, can you? I mean, that’s specifically what the document above is addressing. This functionality is broken.

    I just posted a comment on a pull request along these same lines too, which may be of interest:


    Tyler, I’m not sure that solution in the comment on that request would be ideal either – I’ve just replied there with my thoughts. Here they are, for posterity:

    Tyler, what you’re saying is better, but if the close action is fired from WordPress upon closing comments, that means existing closed comments wouldn’t be supported by this if you’ve migrated to Disqus after having an established comment base.

    Disqus should perhaps try to detect whether a given post has comments closed in WP but not in Disqus, and if they’re not closed on the remote side, issue a close action. Not sure what the best way is, but simply setting a flag that gets passed to the JS form would be a good start. The problem is, spammers can figure this out and unset the flag, unless you have a security mechanism in place that uses hashed API secret/key to pass parameters to the form.

    Thanks Artem. As I said I think that is due to some logic that needs cleaning up. I believe the plugin used to simply not render at all when comments were closed in WP itself and that is somehow now no longer the case (as you also pointed out). This has presented us with an opportunity to step back and take a larger look at what the integration should be and what’s feasible (see my previous pull request comment).

    In other words, this is now part of a larger discussion and rest assured the issue will be fixed either way in the next plugin release.

    Thanks again,

    I’ll respond to your second thought in the pull request.


    That’s great to hear that all of this is not in vain and movement will be made. What I keep finding though is that DISQUS features that are supposed to work are broken as if there is no QA in place for releases, and that’s making me nervous. I can’t even imagine how much I’m going to need to test every plugin update before my paranoia is satisfied. I think you can understand why, given how much time was spent on our integration, you know?

Viewing 10 replies - 1 through 10 (of 10 total)
  • The topic ‘[Plugin: Disqus Comment System] DISQUS disregarding per-post comments allowed setting’ is closed to new replies.