Add "X-akismet-pro-tip" support to Activity Akismet integration

[DJPaul]

See the "spam response example" on ​http://akismet.com/development/api/#comment-check and ​http://blog.akismet.com/2014/04/23/theres-a-ninja-in-your-akismet/

We already have the headers in an array, it should be fairly easy to add a check for this header in.

[slaFFik]

A spam response may also include the X-akismet-pro-tip header. If the X-akismet-pro-tip header is set to discard, then Akismet has determined that the comment is blatant spam, and you can safely discard it without saving it in any spam queue.

Related file: class-bp-akismet.php

@DJPaul
So is this task basically about taking into account "Strictness" setting in Akismet admin area and automatically removing comments with a X-akismet-pro-tip: discard response header from Akismet, when "Silently discard the worst and most pervasive spam so I never see it." is selected?

[DJPaul]

It's been too long to remember the conditions for this to happen (I'd have to look at the implementation in the Akismet plugin again), but something like that, yes.

[netweb]

Related: ​#bbPress2853

p.s. There's an initial patch there that may, or may not help for this ticket

[slaFFik]

I would like to do this for 2.8.

[djpaul]

In 11890:

Activity, Akismet: add support for Akismet's "discard worse spam" feature.

Fixes #6594

Thanks to slaFFik, and via bbPress, netweb and Otto42, for historical contributions towards this change.

[r-a-y]

Trunk was causing a never-ending AJAX request when posting any activity update.

I used git bisect to determine where this bug originated and git bisect returned this changeset (r11890).

To duplicate:

1. Run BP trunk.
2. Activate the Akismet plugin and configure Akismet with a valid Akismet API key
3. Navigate to the Activity Directory and attempt to post an activity update.
4. The activity update is never posted because the AJAX request never ends.
5. If you refresh the page, you'll see that the activity update was posted several times, depending on the amount of time you left the AJAX request running.

I don't have time at the moment to look into this, but can we revert r11890 or get more testers to verify?

[DJPaul]

Can I have the log or the backtrack please? Ta.

[r-a-y]

Can I have the log or the backtrack please? Ta.

What specifically do you need a log of?

If it is for $response = Akismet::http_post( $query_string, $path );

Here's what I get:

Array
(
    [0] => Requests_Utility_CaseInsensitiveDictionary Object
        (
            [data:protected] => Array
                (
                    [server] => nginx
                    [date] => Sun, 25 Mar 2018 01:43:19 GMT
                    [content-type] => text/plain; charset=utf-8
                    [content-length] => 5
                    [x-akismet-guid] => XXX
                )

        )

    [1] => false
)

After some more debugging, I've found that this line is the cause of the hang-up:

$activity_data['bp_as_result_headers'] = $response[0];

Once I comment this line out, the activity update is able to post normally.

Since $response[0] is an instance of the Requests_Utility_CaseInsensitiveDictionary class, I tried using the ​getAll() method to fetch the headers:

$activity_data['bp_as_result_headers'] = $response[0]->getAll();

But, this also causes the infinite loop. I'm not too familiar with the Akismet API, so I'm not sure how to set the headers properly.

Hope that helps somewhat. Let me know if you need anything else from me.

[r-a-y]

Decided to look at how the Akismet plugin sets its headers. They only set the 'akismet_pro_tip' header and that's it:
​https://plugins.trac.wordpress.org/browser/akismet/tags/4.0.3/class.akismet.php#L187

So that's what 01.patch does. Did some tests and this fixes the infinite loop problem.

[DJPaul]

Nice. I want to test this and look at the headers -- I'll spin up a test site and look sometime this/next week.

[djpaul]

In 11950:

Activity, Akismet: fix infinite loop introduced in r11890

Props r-a-y

Fixes #6594