Unclear wording: "An administrator must always approve the comment "

[joe.woidpress]

I'm not certain if I should classify this as a bug or as a need to revise wording in the options menu, or if I should put in a feature request for a refined option...

...but...

If, under Settings->Discussion you have "An administrator must always approve the comment" checked, if the author of the post receiving the comment has the "edit_comment" capability, they will receive an email notification to moderate the comment in the queue.

After viewing the wp_notify_moderator function for 3.1 in pluggable.php (and comparing it to 3.0.5's version) I can see this functionality seems to be coded in by design.

What's confusing is that the option reads "An administrator must always approve the comment" and it's difficult to discern if that means the user role of "Administrator" or anyone who can be an "administrator" of the comments.

It's also hard to tell from the reading of the option text whether or not this means that the function is implemented incorrectly, or if the option is simply poorly worded.

In either case, it would be useful to be able to have more granular control over who is getting these email notifications for comment moderation.

Failing that, if the "An administrator must always approve the comment" is checked, that should mean that only users with the "Administrator" role should be able to approve the comment.

...depending on what the expected behavior of this functionality is meant to be.

[scribu]

I believe the intention is something like this:

"Someone who can edit the comment must always approve it before it is displayed"

[linuxologos]

Related #6286 ?

[joe.woidpress]

Replying to linuxologos:

Related #6286 ?

It's certainly related, although I think there's an extra aspect in my ticket relating to who the "administrator" is who needs to approve the comment.

My ticket addresses the "An administrator must always approve the comment" option while the other ticket addresses the email notification options.

[shacker]

In the meantime, authors on multi-author sites who have never seen moderation emails before are being hammered with them (and confused by them), and admins are put in an uncomfortable situation trying to tell authors to ignore them. Until this is fixed, is there anything we can do to disable moderation emails to authors?

[joe.woidpress]

Replying to shacker:

In the meantime, authors on multi-author sites who have never seen moderation emails before are being hammered with them (and confused by them), and admins are put in an uncomfortable situation trying to tell authors to ignore them. Until this is fixed, is there anything we can do to disable moderation emails to authors?

I think the best you could do at this point is to hack wp-includes/pluggable.php and modify line 1121. My guess is if you changed the 'edit_comment' capability so something that only your desired access level can do (check ​http://codex.wordpress.org/Roles_and_Capabilities for something that might work), that would at least patch things for the time being if this is a huge issue for you. (This whole issue seems to stem from the new 'edit_comment' capability added in WordPress 3.)

...best I could come up with for you.

Hopefully there will be more granularity for selecting who gets emailed in the future...

[shacker]

Thanks Joe. I commented out lines 1121-1122, and unfortunately post authors still receive moderation emails. This is puzzling, as it's the only place in that function I can see where the post author's email is obtained. That fix really should work. Any other ideas? Thanks.

[kevinB]

The problem I see is that as of WP 3.2.1

user_can($user->ID, 'edit_comment', $comment_id)

is effectively converted to:

user_can($user->ID, 'edit_post', $comment->comment_post_ID)

...but no moderate_comments requirement is ever imposed.

[kevinB]

map_meta_cap(): for 'edit_comment', append 'moderate_comments' to 'edit_post' caps

[kevinB]

To clarify the original ticket description, 'edit_comment' is a meta capability which should not be assigned as part of a role definition. The real issue is non-requirement of the moderate_comments capability.

[scribu]

The patch is no good. It would mean that authors couldn't edit comments on their own posts, since only editors and admins have the 'moderate_comments' capability.

So, again, the problem isn't the capabilities, but the wording of the option.

[scribu]

For the discussion on wether it's a good idea for authors to be able to edit any comment on their own posts, please open a new ticket.

Anyway, I believe the option should read "The comment should not be published until it's approved".

[kevinB]

Replying to scribu:

The patch is no good. It would mean that authors couldn't edit comments on their own posts, since only editors and admins have the 'moderate_comments' capability.

Actually, the patch is just incomplete.

Without needing to discuss whether it's a good idea, let's just be clear that Authors are currently granted an implicit and unrevokable 'moderate_comments' capability.

A more consistent approach would be to explicitly add 'moderate_comments' to both the Author role and the 'edit_comment' cap map. Then let the the site admin decide if it's a good idea, by removing 'moderate_comments' from the role if desired.

Anyway, that would require a more ambitious patch and more deliberation so I'm not going to pursue it any further here. Will work around the issue via plugin code as needed but I thought the observation/idea might benefit others too. Just take it or leave it.

[jane]

"Comments will not be published until manually approved."

[scribu]

That doesn't really work. There's some text before that setting, which looks like this:

Before a comment appears:

• An administrator must always approve the comment
• Comment author must have a previously approved comment

[RyanMurphy]

patch based off Jane's wording

[RyanMurphy]

Attached patch changes the "An administrator must always approve the comment" to Jane's wording.

[Ipstenu]

"All comments must be manually approved."

That would fit better with the 'Before a comment appears' header. Or even "Comment must be manually approved", full stop.

[edwardw]

Tested on r19236, works fine.

[jane]

It's too late in the cycle to put this in...didn't get put in early enough to get adequate user testing/feedback. Since we're almost at RC, don't want to mess with it now. Sorry it languished, we can look at it again in 3.4 early.

[MikeHansenMe]

refreshed, the file has changed since last revision.

[SergeyBiryukov]

Generally, a refresh is only needed when the patch no longer applies cleanly.

Line numbers may be off, but as long as the content is the same, the patch should still apply cleanly.

[ericlewis]

I agree with scribu - the two comment options in this section sound contradictory. The two have an OR relationship, but that's not visually expressed.

Although the copy change suggested here is an improvement, that's still an issue.

[DrewAPicture]

'Comment must be manually approved

[DrewAPicture]

16705.diff​ changes the label to 'Comment must be manually approved'

This is consistent with the singular use of 'comment' in other labels on this screen. Also the section label 'Before a comment appears' makes the use of 'will not be published' suggested in comment:13 and 16705.2.diff redundant.

[SergeyBiryukov]

In 25295:

Clarify a string in discussion settings. props Ipstenu, DrewAPicture. fixes #16705.

[nacin]

Reopening for final UX review.

[ericlewis]

The presentation is still problematic here.

For example:

[x] Comment must be manually approved
[x] Comment author must have a previously approved comment

The latter setting is ignored, as all comments must always be manually approved. In the case of they are both set, the latter setting has no relevance. Only one should be able to be selected at a time, an interlocking mechanism should be employed, and perhaps visually displayed.

Although this discussion may be off-topic for this ticket, feel free to tell me to make a new one.

[SergeyBiryukov]

Replying to ericlewis:

Although this discussion may be off-topic for this ticket, feel free to tell me to make a new one.

See #23233.

[johnbillion]

UXers: any feedback?

[helen]

I definitely think we can/should continue in #23233, but the new string seems better to me when I look at the admin screen. Good for 3.7.