wpDiscuz Support Forum - Recent Posts

RE: Whitelisting commenters

Asti — Sat, 12 Sep 2026 09:57:58 +0000

Hi,

I'm sorry, but wpDiscuz does not have such a feature. This is a WordPress setting and should be configured from Dashboard > Settings > Discussion.

RE: Live-update notification (bubble) never notifies two guest commenters when both leave the comment author email field blank

Asti — Sat, 12 Sep 2026 09:53:45 +0000

Hi,

Thank you for letting us know.

This will be fixed in the next update.

Live-update notification (bubble) never notifies two guest commenters when both leave the comment author email field blank

wpdiscuzuser2258 — Sat, 12 Sep 2026 04:49:10 +0000

wpDiscuz version: 7.6.69
Environment: WordPress (ClassicPress-based), PHP, LiteSpeed server, no caching plugin active

Summary:
The bubble/live-update REST endpoint (wp-json/wpdiscuz/v1/update) never returns
newly posted comments in its "ids" field when two different guest visitors post
comments without filling in an email address. The overall "all_comments_count"
does update correctly, but the "ids" array (which drives the notification
bubble/toast) stays empty forever for these visitors, even though the new
comments are approved and clearly exist with a higher comment_ID than the
client's lastId.

Root cause (found by reading includes/class.WpdiscuzDBManager.php):
getNewCommentIds() builds its query with:

... AND `comment_ID` > %d AND `comment_author_email` != %s ...

where %s is the requesting visitor's own email (from $_COOKIE
"comment_author_email_" . COOKIEHASH, or the logged-in user's email).
This is meant to exclude a visitor's own comments from their own
notification feed. However, when a guest commenter does not enter an
email address, comment_author_email is stored as an empty string (‘’).
If a SECOND, completely different guest visitor also leaves the email
field blank, their request also sends email = ''. The exclusion filter
then matches "comment_author_email != ''" as FALSE for the other
visitor's new comment (because it also equals ''), so that comment is
incorrectly treated as "my own" and excluded from `ids` — even though
it was posted by a different person in a different browser.

Steps to reproduce:
1. Open the same post in two different browsers/profiles as two
different anonymous guests (not logged in).
2. In both, submit a comment WITHOUT filling in an email address
(only a display name).
3. Wait for the bubble's live-update poll (wp-json/wpdiscuz/v1/update)
to fire in either browser.
4. Observe: `all_comments_count` increases correctly, but `ids` and
the notification bubble/toast never show the other guest's new
comment — because both share the same blank email identity.
5. For comparison, if one of the two commenters is logged in (so their
email is a real, distinct value), notifications work correctly in
both directions.

Expected behavior:
Two different guest visitors who both leave the email field blank
should still be notified of each other's new comments — an empty
email should not be treated as a shared "identity" for the
self-exclusion filter. Suggested fix: only apply the
`comment_author_email != %s` exclusion when the requester's email is
non-empty, or use a more reliable per-visitor identifier (e.g. a
random per-session cookie/nonce) instead of email for this
self-exclusion check.

Impact:
On a public site where many visitors comment as anonymous guests
without an email address, this silently breaks the live comment
notification feature for a large share of real visitors, not just in
a synthetic multi-browser test.

Happy to share captured network requests/responses (from Chrome
DevTools/Firefox DevTools) and the exact wp_comments rows (comment_ID,
comment_author, comment_author_email) that reproduce this if useful.

Whitelisting commenters

daniellerch — Fri, 11 Sep 2026 00:01:52 +0000

Following up on this thread from 3 years ago: https://wpdiscuz.com/community/troubleshooting/whitelisting/#post-21326

I'm interested in a way for my comment moderators to whitelist users either automatically after a certain number of approved posts, or manually from either wpDiscuz Settings in the backend or the wpDiscuz Frontend Moderatoin add-on. (We use volunteer moderators on our site, so they don't have access to Settings > Discussion.) Is there an option for this?

RE: Same-IP voting restriction in recent versions blocks logged-in users and breaks legitimate scenarios

Hakob — Wed, 09 Sep 2026 13:52:50 +0000

@doctorbr , Thanks — your analysis is correct on both scenarios, and the fix is in for the next release (7.6.70).

You pinpointed it exactly: the Walker resolved the guest denial reason from shouldDenyGuestVoteFromSameIP() alone, while voteOnComment() rejects on isGuestCanVote before it ever reaches the IP check. So with guest voting disabled, a same-IP guest got the "same IP" tooltip and a "Login To Vote" toast, and a different-IP guest — the normal production case — got fully live buttons that answered the same way on click.

The Walker now resolves the cause in the order the AJAX handler checks it, and

$args carries the first guest check, as you suggested:

if ($currentUserID) {
    $voteDenialCause = $currentUserID === (int)$comment->user_id ? "self_vote" : "";
} else if (!$canUserVote || trim($currentUserIP) === "") {
    $voteDenialCause = "login_required";
} else {
    $voteDenialCause = WpdiscuzHelper::shouldDenyGuestVoteFromSameIP($comment, $currentUserIP) ? "same_ip" : "";
}

Three notes on the details:

- One more case is folded into that middle branch: a guest whose IP resolves to

empty is also answered with wc_login_to_vote by the handler (!$userID &&

!$hasUserIP), so that now renders disabled with the same tooltip instead of

live buttons.

- wpdiscuz_hide_readonly_vote_buttons gains "login_required" as a third $voteDenialCause value alongside "self_vote" and "same_ip", in case you switch on it.

- .wpd-vote-disabled deliberately sets only opacity and cursor, no pointer-events: none, and the click handler is untouched — so the buttons stay clickable and the toast still appears. That matters on touch devices, where the tooltip never fires and the tap is the only way to get the explanation.

Verified across all six combinations (guest / logged-in × guest voting on / off × same / different IP): tooltip and toast now agree in every one.

Thanks again for the precise report — the file and line references made it quick

to confirm, and it's good to hear the v7.6.68 changes worked out for you.

RE: How to get latest Google icon to show in social login

cdsingalong — Tue, 08 Sep 2026 11:06:46 +0000

The latest update of wpDiscuz has resolved this problem and now shows the newer Google icon. Thanks so much!

RE: Nonce invalid when marking comment as sticky

Asti — Tue, 08 Sep 2026 06:53:24 +0000

Hi,

Please update the plugin to the latest version and check again.

This issue should be solved.

RE: Same-IP voting restriction in recent versions blocks logged-in users and breaks legitimate scenarios

DoctorBR — Mon, 07 Sep 2026 22:22:29 +0000

Thank you for implementing both suggestions in v7.6.68: the disabled state with reduced opacity and tooltip, plus the `wpdiscuz_hide_readonly_vote_buttons` filter, are exactly what I proposed. The implementation is clean and I've removed my CSS override from v7.6.67 since it's no longer needed. 👍

However, I found an inconsistency between the tooltip and the toast message when a guest tries to vote while "Allow Guests to Vote for Comments" is disabled.

Steps to reproduce:

Disable "Allow Guests to Vote for Comments" in wpDiscuz > Settings > Comment Thread Features.
Open any post with comments in an incognito/private window (not logged in).
Hover over a vote button on a comment that shares the visitor's IP (always the case in localhost, but also possible in production with CGNAT or corporate networks).
The tooltip shows: "You are not allowed to vote for this comment (Voting from same IP)"
Click the button.
The toast shows: "Login To Vote"

Root cause:

The Walker (`class.WpdiscuzWalker.php`, line 305) determines the disabled state and tooltip for guests using only `shouldDenyGuestVoteFromSameIP()`. It never checks the `isGuestCanVote` setting. When guest voting is disabled AND the IPs match, the Walker concludes "same_ip" is the reason and sets the tooltip accordingly.

But the AJAX handler (`voteOnComment()`, lines 712–713) checks `isGuestCanVote` FIRST, before the IP check. Since guest voting is disabled, it returns `wc_login_to_vote` immediately, never reaching the IP check. The visitor sees two different explanations for the same denial.

There's also a related scenario in production: when guest voting is disabled but the visitor's IP does NOT match the comment author's IP (the normal case), `shouldDenyGuestVoteFromSameIP()` returns false, so the Walker renders the buttons as fully active, no disabled class, no tooltip. But clicking triggers the AJAX, which returns "Login To Vote" because guest voting is disabled. The visitor sees fully functional buttons that don't work.

I noticed that `$args` is already computed correctly in `getCommentListArgs()` (`class.WpdiscuzCore.php`, line 2043) and passed to the Walker, but it's never read inside `WpdiscuzWalker::start_el()`.

Suggested fix: the Walker should check `$args`(or the `isGuestCanVote` option directly) before falling through to the IP check. When a guest cannot vote because guest voting is disabled, the buttons should show the disabled state with the `wc_login_to_vote` phrase as the tooltip, matching what the AJAX handler will return on click.

Conceptually:

```

if ($currentUserID) {

// logged-in: check self-vote by user_id (already correct)

} else {

if (!$args) {

// guest voting disabled → disabled state with "login" tooltip

} else {

// guest voting enabled → check same-IP (already correct)

}

```

Everything else in v7.6.68 looks correct and well-structured. The server-side vote checks, rate limiting, the new filter, and the disabled CSS are all solid.

```

Disclosure: This reply was drafted with the assistance of an AI coding assistant (Antigravity v2.12.2 / Claude Opus 4.6) based on my review and testing of the wpDiscuz v7.6.68 source code. The analysis was reviewed and approved by me before posting. All described behaviors were tested in my development environment (WampServer64 / WordPress 7.0.4 / PHP 8.3.30).

````