WordPress.org

Make WordPress Core

Opened 6 years ago

Last modified 17 months ago

#9117 new enhancement

Spam queue doesn't distinguish between filter sources

Reported by: tellyworth Owned by:
Milestone: Future Release Priority: normal
Severity: normal Version: 2.7
Component: Comments Keywords: needs-patch
Focuses: administration Cc:

Description

  1. On the Settings / Discussion tab, go to the Comment Blacklist box, and add the string "the".
  1. Post a comment containing the word "the". It will be caught as spam.
  1. Visit the Comments / Spam tab. Your comment is there, but there is nothing to indicate whether it was caught by the Comment Blacklist, or by Akismet, or by another spam filter.

Result: neither the user nor WordPress knows how to prevent that comment from being caught in future. Many users will forget about the Blacklist feature and assume their spam filter plugin is faulty.

Suggested fix: comments caught as spam should record the reason. This should be displayed to the user, and used internally by spam filter plugins to decide how to handle false positives.

Change History (11)

comment:1 @tomontoast6 years ago

Sounds like a sensible idea to me. I don't know how you would implement it. Would you have a new column in the comments table? or would you put this information in the comment_approved column?

comment:2 @mrmist6 years ago

  • Version set to 2.7

Best would be a new column rather than overloading comment_approved. Otherwise every search on comment_approved will become more costly.

comment_spam_reason maybe.

comment:3 @mrmist6 years ago

  • Keywords needs-patch added

Also is this really a bug? The anti-spam works it's just not particularly intuitive. Seems more like an enhancement to me.

comment:4 @tellyworth6 years ago

A new column would be cleaner, yes. There was some talk of a comment_meta table, that would work also (but I don't think that idea has any traction).

Whether or not you consider it a bug is a matter of definitions I suppose. It does cause unexpected behaviour, and there's no real way for the user to work around it. People do sometimes blame their spam plugins for catching things incorrectly, when it was in fact the comment blacklist (or a different plugin).

A more subtle but related issue is that it's difficult for spam plugins to accurately count the number of spam and ham comments caught. They really need to be counted at the time the comment is deleted to get it right, otherwise you can't correctly account for false positives that are discovered and approved by the user. But right now there's no way to know which comments were caught by what method.

comment:5 @tellyworth6 years ago

Another possibility would be to overload a different column: perhaps either comment_karma or comment_type.

Specific values for comment_karma could be used as a flag to indicate the filter that spammed the comment.

comment_type could have a prefix or suffix to work as a flag, perhaps something like "a:trackback" or "b:trackback" to indicate a comment caught by Akismet or the Blacklist respectively.

comment:6 @Viper007Bond6 years ago

  • Component changed from General to Administration
  • Milestone changed from 2.8 to Unassigned
  • Type changed from defect (bug) to enhancement

Definitely an enhancement.

comment:7 @FFEMTcJ6 years ago

  • Milestone changed from Unassigned to Future Release

comment:8 @tellyworth6 years ago

I wrote a proof-of-concept plugin as a bandaid fix in the meantime:

http://thresholdstate.com/threshold/4341/tw-blacklight-plugin-for-wordpress

It doesn't solve the underlying problem but it might provide some useful feedback.

comment:9 @ryan4 years ago

commentmeta exists now.

comment:10 @nacin3 years ago

Comment history (like what Akismet has now) would be sweet for core. It could handle why an item was spammed, or who approved/unapproved/trashed/spammed it. I've mused about this in a few other places: 19495#comment:2, 15534#comment:4.

comment:11 @jeremyfelt17 months ago

  • Component changed from Administration to Comments
  • Focuses administration added

I like this a lot. More context around how comments are filtered would be great.

Note: See TracTickets for help on using tickets.