fix: add supported gateways check

[laurelfulford]

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-plugin#3650, adds a check to see if there's an unsupported payment gateway enabled in WooCommerce. If there is, the Donate Block and Checkout Button block will use the regular checkout instead of the modal checkout.

See 1205234045751551-as-1208992708114862

How to test the changes in this Pull Request:

Testing set up

1. Set up a test page with a regular Donate Block, a tiered Donate block, and a couple different Checkout Button Blocks -- one with a regular product, and one with a variable product.
2. Apply this PR and fix: add supported gateways check newspack-plugin#3650, and run npm run build for each.
3. Under WooCommerce > Settings > Payments, install and activate at least one unsupported payment gateway -- right now, this includes any gateways not listed here.

---

Testing with unsupported gateways

It's a lot, but ideally most of these steps should be repeated with a couple different block types, including Checkout Button block + simple product, Checkout Button block + product with variations, Donate Block, and Donate Block with tiers.

Account creation required & create account

Please test this with a simple product, a product with variations, and one of the donate blocks.

1. Under Newspack > Engagement > Advanced Settings, check "Require sign in or create account before checkout" under the Checkout Configuration header.
2. In an incognito window, run through a checkout.
3. When prompted, create a new account.
4. Confirm that while the modal is processing, it maintains the 'loading' faded out appearance.
5. Confirm that the modal redirects to the full checkout page, with no "cruft" in the URL (no query string related to the modal checkout, like with the after_success params.

Account creation required & log in

Please test this with a simple product, a product with variations, and one of the donate blocks.

1. In a new incognito window, run through a checkout.
2. When prompted, log into an existing account.
3. Confirm that while the modal is processing, it maintains the 'loading' faded out appearance.
4. Confirm that when you hit different steps (the OTP stage, or password stage, or clicking the 'Back' button) the faded out 'loading' appearance is not used. You may want to use a couple different users to test the different blocks, so you can test both OTP and password steps.
5. Confirm that the modal redirects to the full checkout page, with no "cruft" in the URL (no query string related to the modal checkout, like with the after_success params.

Account creation required & already logged in

Please test this with a simple product, a product with variations, and both donate blocks.

1. While still logged in to the above account, run through a checkout.
2. In the Donate Block and Checkout button block with a simple product, confirm that the button displays a rotating animation until the page reloads:

3. For the checkout button block with a product with variations, the initial modal should open, and then the variation-specific button should display the animation until the page reloads.
4. Confirm that you're redirected to the regular checkout page.

Account creation required & login failures

Smoke test a few scenarios where the login is not successful, like:

1. In an incognito window, try to sign in with an email that's not associated with an account yet.
2. In an incognito window, try to create an account with an email that's already used.
3. In an incognito window, try to create an account with a malformed email.
4. In an incognito window, try to log in and mess up the password or OTP step.

... plus any other cases you can think of. Most of these are to spook out any issues with my messing with the registration modal (making it not close, or messing with the loading styles 🙂 ).

---

Account creation not required

1. Under Newspack > Engagement > Advanced Settings, uncheck "Require sign in or create account before checkout" under the Checkout Configuration header.
2. Repeat a couple of the test scenarios above (making a purchase when not logged in, making a purchase when already logged in). You should have a similar experience to the "Account creation required & already logged in" section, where you see a "loading" style on the button, and are brought to the /checkout page.

---

Testing with supported gateways

Before testing this section, navigate to WooCommerce > Settings > Payments, and deactivate any unsupported payment gateways.

Run through the following with 1-2 blocks each, just to smoke test and make sure no new issues have been introduced:

1. Retest the steps under "Account creation required & create account".
2. Retest the steps under "Account creation required & log in".
3. Retest the steps under "Account creation required & already logged in".
4. Retest the steps under "Account creation required & login failures".
5. Run a purchase with the 'Newsletter Coda' enabled.
6. Run a purchase with some different Checkout Button Block settings enabled (eg. redirecting after the purchase is complete).

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?

[dkoo]

Ran into a few minor issues here. Aside from these, the redirect is working in all test scenarios.

1. After creating a new account, when being directed to the regular checkout page the _newspack_checkout_registration param is still appended to the URL.

2. When logging into an existing account via OTP, if you click "Continue" without filling in the code or after entering an incorrect code, the auth modal still has a translucent overlay on it that doesn't go away:

3. If I get redirected to the regular checkout page and then hit the "back" button in my browser, the Checkout Button or Donate block remains in the "loading" state and the extra params are appended to the URL.

[dkoo]

Nit: rather than relying on regex and text manipulation of the URL, a cleaner way to do this might be to not append the modal checkout-related hidden fields if there's an unsupported payment gateway.