WordPress.org

Make WordPress Core

Opened 3 years ago

Closed 6 months ago

#16705 closed defect (bug) (fixed)

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

Reported by: joe.woidpress Owned by: SergeyBiryukov
Milestone: 3.7 Priority: normal
Severity: normal Version: 3.1
Component: Text Changes Keywords: has-patch commit ux-feedback
Focuses: Cc:

Description

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.

Attachments (4)

16705-edit_comment_3.3.patch (543 bytes) - added by kevinB 3 years ago.
map_meta_cap(): for 'edit_comment', append 'moderate_comments' to 'edit_post' caps
16705.patch (956 bytes) - added by RyanMurphy 3 years ago.
patch based off Jane's wording
16705.2.diff (957 bytes) - added by MikeHansenMe 18 months ago.
refreshed, the file has changed since last revision.
16705.diff (937 bytes) - added by DrewAPicture 12 months ago.
'Comment must be manually approved

Download all attachments as: .zip

Change History (37)

comment:1 scribu3 years ago

  • Keywords ux-feedback added

I believe the intention is something like this:

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

comment:2 follow-up: linuxologos3 years ago

Related #6286 ?

comment:3 in reply to: ↑ 2 joe.woidpress3 years ago

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.

comment:4 follow-up: shacker3 years ago

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?

comment:5 in reply to: ↑ 4 joe.woidpress3 years ago

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 link 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...

Version 0, edited 3 years ago by joe.woidpress (next)

comment:6 shacker3 years ago

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.

comment:7 kevinB3 years ago

  • Cc kevin@… added

The problem I see is that

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.

Last edited 3 years ago by kevinB (previous) (diff)

kevinB3 years ago

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

comment:8 kevinB3 years ago

  • Summary changed from Authors with "edit_comment" capability receive comment moderation emails for their posts when "An administrator must always approve the comment " is checked to Post Authors lacking moderate_comments capability still receive comment moderation emails

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.

comment:9 scribu3 years ago

  • Summary changed from Post Authors lacking moderate_comments capability still receive comment moderation emails to Unclear wording: "An administrator must always approve the comment "

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.

Last edited 3 years ago by scribu (previous) (diff)

comment:10 scribu3 years ago

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".

comment:11 scribu3 years ago

  • Milestone changed from Awaiting Review to 3.3

comment:12 kevinB3 years ago

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.

comment:13 jane3 years ago

"Comments will not be published until manually approved."

comment:14 scribu3 years ago

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

RyanMurphy3 years ago

patch based off Jane's wording

comment:15 RyanMurphy3 years ago

  • Keywords has-patch added

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

comment:16 Ipstenu3 years ago

"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.

comment:17 edwardw2 years ago

  • Keywords tested dev-feedback added

Tested on r19236, works fine.

comment:18 jane2 years ago

  • Keywords 3.4-early added
  • Milestone changed from 3.3 to Future Release

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.

comment:19 jane2 years ago

  • Component changed from General to UI

MikeHansenMe18 months ago

refreshed, the file has changed since last revision.

comment:20 MikeHansenMe18 months ago

  • Cc mdhansen@… added

comment:21 SergeyBiryukov18 months ago

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.

comment:22 SergeyBiryukov17 months ago

  • Component changed from UI to Text Changes

comment:23 wonderboymusic15 months ago

  • Milestone changed from Future Release to 3.6

comment:24 ericlewis12 months ago

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.

DrewAPicture12 months ago

'Comment must be manually approved

comment:25 DrewAPicture12 months ago

  • Keywords commit added; ux-feedback tested dev-feedback removed

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.

comment:26 ryan10 months ago

  • Milestone changed from 3.6 to Future Release

comment:27 SergeyBiryukov8 months ago

  • Milestone changed from Future Release to 3.7

comment:28 SergeyBiryukov7 months ago

  • Owner set to SergeyBiryukov
  • Resolution set to fixed
  • Status changed from new to closed

In 25295:

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

comment:29 nacin7 months ago

  • Resolution fixed deleted
  • Status changed from closed to reopened

Reopening for final UX review.

comment:30 follow-up: ericlewis7 months ago

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.

Last edited 7 months ago by ericlewis (previous) (diff)

comment:31 in reply to: ↑ 30 SergeyBiryukov7 months ago

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.

comment:32 johnbillion6 months ago

  • Keywords ux-feedback added; 3.4-early removed

UXers: any feedback?

comment:33 helen6 months ago

  • Resolution set to fixed
  • Status changed from reopened to closed

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.

Note: See TracTickets for help on using tickets.