Skip to content


Subversion checkout URL

You can clone with
Download ZIP


Remove spam comments and faulty admin logins from primary activity report #472

krogsgard opened this Issue · 8 comments

5 participants


The spam comments and faulty admin login attempts overwhelm the activity stream, making the primary report mostly useless to me.

I'd recommend a) the option to not track that info at all, and/or at least b) Remove it from the primary activity report.

In regard to (b), you could simply keep a count in the report div (22 admin login attempts, 245 spam comments today), but not show the activity itself without drilling down further. That would keep more important information (like posts publishing, real comments, real-username login failures, and page changes) more visible, and therefore the default report would be much more valuable.


Hey @krogsgard - have you tried adjusting the Exclude settings? You can find them in Stream > Settings > Exclude.

schermata 2014-04-28 alle 06 43 04 pm

There's a tick box down the bottom to hide existing entries, too. Does that help?

@lukecarbis lukecarbis self-assigned this

I was apparently looking in the wrong place. I just found Failed Login thanks to your screenshot. Marked as Spam doesn't show up for me though.

Perhaps a legend or (?) indicator or link to docs or something would help people discover what could be useful? Also, perhaps some pre-configured "popular" exclusions could help? Something to help guide users the right direction? I highly doubt I'm the only person that'd want to not see hundreds of spam comments in these reports...

So, in short, perhaps even if we find the answer in exclusions, there are some things worth considering here for default behavior?


Fantastic suggestions, @krogsgard, thanks! We'll be improving our docs over the next little while, and adding references to them as we do. Great idea for us to discuss some potential sensible defaults there too.


@Japh Japh closed this

Weirdly enough, when I went back in to try again, Marked as Spam came up. However, it doesn't appear to actually remove these items from the Stream. You can see my screenshot here (which is a spam comment up top, right after the Activity setting change)

@Japh Japh reopened this

@krogsgard If you tick the checkbox, it should then hide previous entries as well. If that doesn't work, please try without the checkbox ticked (see #475).

Also, as you see above, we've opened a ticket for further discussion on your suggestion in #474.

@fjarrett fjarrett added the question label

I'm closing this as I believe it's being addressed as multiple separate issues:

@lukecarbis lukecarbis closed this

Hey guys,

I think this is still unaddressed, or lost in the fray of those other tickets.

"Marked as spam" as an action doesn't actually trigger the filter.

You can see here where I changed it to that action and the spam came through anyway:

I think it's bypassing it bc marking as spam happens earlier. It's not published comment > spam comment. It's just comment entry > spam.

I talked to @Japh about this some via Skype, but I'd love to see this fixed. Right now I have to block out all comments via the connector, but I'd really love to track legit comments.


Hey @krogsgard,

I think this is a bit tricky to handle, since as you mentioned the 'Marking as spam' action takes place after actually logging the record.

We have a few scenarios here:
1- A comment is added, and Akismet reports that it is a spam comment.
Solution: We can probably delay logging the comment addition to end of session, so Akismet action is account for. A pretty straight forward approach.

2- A comment is added, passed Akismet validation, a user later marks it as spam.
This should probably be logged properly, as a comment added log, then a user update log. Since this is considered 'an admin action' that should be logged via Stream.

I know some would like user-marked spam comments to still be filtered via 'Marked as spam',
so the obvious solution to such a problem would be to update Stream log with comment status after being spammed or approved by the user. But that is something that we'll probably want to refrain from doing, talking about updating records, because if you start going down that path, lots of inconsistencies will be introduced to logs.

I'll experiment with a solution for the first scenario, which i hope would fix your original problem.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.