Expose honeypot protection via service

Patch no longer applies cleanly.

Re-rolled patch.

Re-rolled to include change from 090a23353b28b5c30c68dd171d2a03bf12a81d47.

This is working as expected in my testing.

This looks good to me in general, but a cursory glance shows a few coding standards issues (comments and spacing, mostly, in the new class). I will try to test a little further then merge soon!

@geerlingguy Thanks for catching that. Updated patch attached.

Troubleshooting test failures.

This looks perfect to me, RTBC++

+++ b/honeypot.module
@@ -119,84 +119,10 @@ function honeypot_get_protected_forms() {
+ * @deprecated Use honeypot service instead

Only thing I can think of is that we should communicate this clearly (ie write a change record, or bold letters on the release notes), just in case someone is using it on their custom code.

We should implement some deprecation items:

- A @deprecated PHPdoc tag;
- A @trigger_error('...', E_USER_DEPRECATED) at runtime
- A unit test proving the deprecation notice will be triggered when the deprecated code is called;

See https://www.drupal.org/core/deprecation

I think this is a good idea.

This does represent an API change, so it would have to be deprecated in one version then removed in the next. In principle we could deprecate it in 8.x-1.x then remove it in 2.0.x. because this is a major version change.

New features should go into 2.0.x first at this point in time. That means it would have to be deprecated in 2.0.x and removed probably in 2.1.x or even 3.0.x.

This properly deprecates ALL the Honeypot API functions and moves them into a service. It also adds tests for the deprecations.

This patch is significantly larger and different from the previous patches, and all of those are >3 years old, so I'm essentially starting from scratch. I still want to clean up the code, but posting here to get feedback from the testbot and from any users who want to try this out.

My intention is to create a 2.1.x branch for API changes like this. That's reflected in the deprecation messages.

It is a never-ending source of frustration for me that code copied from Drupal core contains an excessive number of coding standards violations. Here is a new patch with many of those fixed, and hopefully with the test failure fixed as well.

Again.

Again. Debugging this on DrupalCI ...

Progress, but everything since #20 is simply debugging the test case on the testbot - nothing is being changed in the actual code.

Turns out the test actually found a bug in original version of honeypot_get_protected_forms(), which sometimes improperly returns a NULL instead of an array. Here's a new patch which includes a fix for that.

As an aside, the deprecation coding standard warnings are incorrect, and are being fixed in #3192093: Deprecation error messages don't allow module:n.n.n versions

#3192093: Deprecation error messages don't allow module:n.n.n versions is fixed, so when Core uses the next version of Coder, which will be 8.3.15 these coding standards messages will be gone.

Thanks jonathan!

Re-roll to account for the fix in #3264627: honeypot_get_protected_forms() doesn't always return an array

I forgot I also added an interface for the service.

Re-rolled against current 2.1.x branch.

Correct the arguments to expectDeprecation() in the new test.

Committed #39.