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.

[laurelfulford]

Thanks @dkoo!

Something else I noticed while fixing these is that the Donate Button doesn't actually animate for me unless I also have the checkout button block on the same page. When you tested this, did you have both blocks on that donate page? I've made some changes and I'm trying to rule out if it's something I've introduced or something that was already there 😅

[laurelfulford]

Something else I noticed while fixing these is that the Donate Button doesn't actually animate for me unless I also have the checkout button block on the same page.

I figured this out - I was blocking the JS file from loading due to changes I made to the Donate Block 😅 I've tweaked things so it should now work.

[laurelfulford]

Thank you for testing this, @dkoo! I think everything should be fixed.

When you re-check this, I could definitely use a gut-check about the changes in 6aa043d. This is the approach I used to fix the back button "still loading" issue -- I noticed when I started testing that, that the registration modals also would hang around when you clicked "Back".

I ended up moving the "close" const to make it available outside of docReady, but I'm not sure that and the rest is the most elegant way to go about it. Any specific feedback/suggestion on this -- and the rest -- are appreciated. Thanks!

[dkoo]

When you tested this, did you have both blocks on that donate page? I've made some changes and I'm trying to rule out if it's something I've introduced or something that was already there 😅

Yes, I did have both blocks on the same testing page!

[dkoo]

I like the new method of not including hidden fields in the first place when they're not needed!

The Donate and Checkout Button blocks still get stuck in a "loading" state if I click back from the checkout page, but that's a minor issue and we can consider it non-blocking if we can't get it working in this PR.

[dkoo]

Ideally we'd also prevent the ?modal_checkout=1 param from being appended too so we wouldn't need regex to strip it. It might be possible to add a condition here for this, but if it adds too much complication then it's okay as-is.

[laurelfulford]

Thanks @dkoo! I'm digging into the ?modal_checkout=1 bit. For the 'Back' button, can you let me know what browser etc. you're using? It seems to work for me but I feel like I'm missing something silly 🙂 Thanks!

[dkoo]

For the 'Back' button, can you let me know what browser etc. you're using?

I'm testing on Chrome

[laurelfulford]

Thanks @dkoo!

I think I've sorted out the query string issue, and I hope the back button issue, too 🤞

In retesting this, I ran into a new issue where, if you had a unsupported payment gateway enabled and then simply signed in using the button in the header, you couldn't close the modal by clicking the 'Continue' button, only the 'Close' button. That should also be fixed in the Newspack Plugin PR that goes with this one.

Could you please retest when you have a moment and make sure things look good to you, too? I'm kind of paranoid about introducing some weird fresh issue 😬 Thank you!