fix(recaptcha): improvements for reCAPTCHA v2 + modal checkout

[dkoo]

All Submissions:

• Have you followed the Newspack Contributing guideline?
• Does your code follow the WordPress' coding standards and VIP Go coding standards?
• Have you checked to ensure there aren't other open Pull Requests for the same update/change?

Changes proposed in this Pull Request:

Along with Automattic/newspack-blocks#2028, implements improvements to the reCAPTCHA v2 integration in a modal checkout context. Also introduces a new option (via environment constant, for now) to allow third-party WooCommerce extensions to load their assets in modal checkout, to allow for greater flexibility. Not all Woo extensions are guaranteed to work with the modal checkout, but many will.

These changes came about due to issues some publishers saw when using the ELEX Address Verification plugin—this plugin triggers actions on the click event of the #place_order button in checkout, which is also bound to our reCAPTCHA v2 widget execution. This causes a conflict where only one of these bound events will fire on click—but because both ELEX and reCAPTCHA can block a checkout request upon failure, enabling both will make it impossible to complete checkout.

This PR avoids such conflicts by creating a clone of the #place_order button in our modal checkout template, hiding the original button element, and binding our reCAPTCHA v2 widget execution to the clone instead of the original. When the reCAPTCHA widget fires its success callback (either upon initial pass or challenge pass), it will trigger a click event on the "real" #place_order button, which will allow other extensions with events bound to that button to do their own thing.

To be clear, this PR doesn't indicate full Newspack support for the ELEX plugin—but it will allow for publishers to test and use plugins like ELEX alongside Newspack, if the resulting experience is acceptable.

How to test the changes in this Pull Request:

Pre-testing setup

1. Add define( 'NEWSPACK_ALLOW_ALL_CHECKOUT_SCRIPTS', true ); to wp-config.php to allow unsupported Woo extensions to load their assets in modal checkout.
2. Connect and enble reCAPTCHA v2 in Newspack > Connections.
3. Install, activate and configure an unsupported Woo extension plugin which would normally conflict with reCAPTCHA v2. To test with ELEX, install the plugin, then sign up for a free EasyPost account to obtain a test API key (or DM me for a key you can use) and enter the key in the API credentials screen (https://siteurl/wp-admin/admin.php?page=wc-settings&tab=elex_address_autocomplete_validation&section=elex-api-credentials). Also make sure to enable address validation via EasyPost in the Address Validation settings page:

4. If using ELEX, make sure to enable address fields in Newspack > Reader Revenue > Donations or ELEX will block all checkout requests due to missing address inputs. Alternatively, test using a shippable product, which will always show both billing and shipping address fields in modal checkouts.

Testing steps

1. Check out this branch and fix(recaptcha): use clone of #place_order button to trigger checkout newspack-blocks#2028.
2. As a reader, start a modal checkout via Donate or Checkout Button blocks.
3. Fill in all required address fields but using a fake (non-existent) address on modal screen 1.
4. On modal screen 2, complete payment details and click "Complete transaction" to start the checkout request.
5. Confirm that you see a reCAPTCHA v2 widget challenge (make sure your reCAPTCHA settings in Google are set to highest security to ensure that you'll always be challenged).
6. After completing the reCAPTCHA challenge, confirm that you get an error response: Address verification failed
7. Go back to modal screen 1 and update the address fields using a real address (I tested with a US-based address—non-US addresses are currently untested).
8. Go back to modal screen 2 and submit payment details again. Confirm that you get another reCAPTCHA v2 challenge.
9. After completing the reCAPTCHA challenge, this time confirm that the address verification succeeds with a popup:

10. After accepting the suggested address, confirm that the transaction completes successfully.
11. Smoke test transactions with reCAPTCHA v3 enabled, and reCAPTCHA disabled entirely. In both cases the address verification should occur as soon as you first click "Complete transaction" with all required fields filled out.

Other information:

• Have you added an explanation of what your changes do and why you'd like us to include them?
• Have you written new tests for your changes, as applicable?
• Have you successfully ran tests with your changes locally?

---

• To see the specific tasks where the Asana app for GitHub is being used, see below:
  • https://app.asana.com/0/0/1209184701915831

[laurelfulford]

Overall things look good! I ran into one maybe-issue that I included at the end.

I ran these checkouts with ELEX and Braintree, and ELEX and Stripe. In most cases, things work as described; I:

• Entered the wrong address fine on the first screen
• Got and passed reCAPTCHA v2 prompt, entered my Braintree test code when using that gateway, and got the Address failed message (not sure if we can change this to remove the colon?):

• I hit the back button, corrected it, entered the credit card info again.
• Got reCAPTCHA checked again, and then saw the email correction screen:

• I picked the original address, entered the Braintree code again when using that gateway, and the transaction went through.
• I also smoke tested without reCAPTCHA and with v3 with both gateways.

The only issue I ran into was using Braintree and subscription products with free trials. I get this error when I try to submit the first screen (it comes from the Braintree plugin):

I found this suggestion, and it does seem to fix the issue but it means no payment method is collected on checkout; best I can tell, readers would be prompted to add payment information later on, which seems subpar:

I don't think this will be an issue for publishers who currently need this support, but I wanted to flag in case it's something that should be fixed before this is merged. I'm making this as "request changes", but that's the only issue I ran into so it should be OK if that's OK!

[dkoo]

@laurelfulford thanks for the testing and feedback!

got the Address failed message (not sure if we can change this to remove the colon?):

The message can be customized in ELEX plugin settings ("Customise" tab).

Re: the issue with Braintree + free trial subscription products, since this seems to be a bug in the Braintree plugin itself and isn't introduced by the modal checkout flows, I don't think think we should let that block us from moving ahead. We should ensure that sites who want to use Braintree are aware of this limitation. For the record, I did attempt to tweak the priority value on the woocommerce_cart_needs_payment hook, but while this allowed the transaction to complete, Braintree still failed to collect payment, resulting in a failed order and on-hold subscription being created.

Also noting a bug I noticed in the ELEX plugin, which you can actually see in the screenshots of the address validation popup above: validated addresses drop the "Street 2" field, so that

999 Street Name
#123
City, CA, 99999

becomes

999 STREET NAME
CITY, CA, 99999

Again, this is a bug originating in the ELEX plugin, so fixing it isn't within the scope of our code.

[laurelfulford]

Thanks for following up on all that stuff, @dkoo!

The message can be customized in ELEX plugin settings ("Customise" tab).

Ah! That's perfect -- nice that they can add some direction there, too 🙂

Re: the issue with Braintree + free trial subscription products, since this seems to be a bug in the Braintree plugin itself and isn't introduced by the modal checkout flows, I don't think think we should let that block us from moving ahead.

Agreed! Thanks for verifying this.

Also noting a bug I noticed in the ELEX plugin, which you can actually see in the screenshots of the address validation popup above... Again, this is a bug originating in the ELEX plugin, so fixing it isn't within the scope of our code.

Good catch, and totally fair! As an aside, Canada Post has an address autocomplete thing you can use here that always bungles my address 😆 These things aren't infallible!

This all looks good to me - giving it a 🚢