Change the logic flow for the order confirmation thankyou screen

[coreymckrill]

Changes proposed in this Pull Request:

On the heels of #38983 and #39191, this changes the flow a bit so that the "thank you" message will always be shown when loading the "order received" URL. However, the verification requirement still prevents the details of the order being shown unless the customer is verified, either by confirming the email or by logging in. If unverified, the login/email form is shown on the thank you screen instead of the details of the order.

This attempts to solve cases where a newly created order has a customer record attached to it (i.e. is not a guest checkout) but the customer is not actually logged in. Currently this can cause the customer to see a login screen right after completing checkout, rather than an acknowledgment that the order has been received. This ensures that the customer gets that acknowledgment. Further, it allows developers to modify this part of their custom checkout flows, if necessary, by customizing the thankyou template file.

See this conversation for more details on the issues this is attempting to resolve.

To do

• If this seems like a worthwhile change to pursue, the e2e tests will probably need to be updated.

How to test the changes in this Pull Request:

The instructions in #39191 apply to this PR as well. The only change should be that the "Thank you. Your order has been received." message should be shown even when viewed as an unverified customer.

Changelog entry

• Automatically create a changelog entry from the details below.

Significance

• Patch
• Minor
• Major

Type

• Fix - Fixes an existing bug
• Add - Adds functionality
• Update - Update existing functionality
• Dev - Development related task
• Tweak - A minor adjustment to the codebase
• Performance - Address performance issues
• Enhancement - Improvement to existing functionality

Message

Change the order confirmation screen to always show the 'Thank you for your order' message, even if the viewer must log in or confirm the order email to see the details of the order.

Comment

[github-actions]

Hi @barryhughes,

Apart from reviewing the code changes, please make sure to review the testing instructions as well.

You can follow this guide to find out what good testing instructions should look like:
https://github.com/woocommerce/woocommerce/wiki/Writing-high-quality-testing-instructions

[github-actions]

Test Results Summary

Commit SHA: 3b782fe

Test 🧪	Passed ✅	Failed 🚨	Broken 🚧	Skipped ⏭️	Unknown ❔	Total 📊	Duration ⏱️
API Tests	259	0	0	2	0	261	1m 9s
E2E Tests	189	0	0	19	0	208	15m 59s

---

To view the full API test report, click here.
To view the full E2E test report, click here.
To view all test reports, visit the WooCommerce Test Reports Dashboard.

[barryhughes]

This seems like a nice tweak, since we always acknowledge the order was received. Left a suggestion, otherwise I think this is worth moving ahead with.

[coreymckrill]

@barryhughes Ok, I committed your suggestion and fixed up some phpcs issues. This is ready for another pass.

[barryhughes]

Something I think we should pause and consider (apologies for not raising this during my first pass) is that, in 7.9.0, if we decided extra verification was needed before showing the order details we would either:

• Render the form-verify-email template (for non-guest orders)
• Or, render a notice plus the login form (for guest orders)

We then returned early and did not render any of the thankyou template. Whereas, in this change, we always render at least some of the thankyou template (and of course it may return early after embedding either of the above).

I think this may work against the motivation for adding verification checks because, if the order exists but the shopper is unverified, we are still going to trigger the woocommerce_before_thankyou action via code found close to the start of the thankyou template (and a third party extension or similar may unwittingly expose information via that hook that perhaps should not be exposed to the as-yet unverified visitor).

There's also some asymmetry in these scenarios where verification is needed in the sense that we do still trigger woocommerce_before_thankyou but not woocommerce_thankyou_<METHOD> or woocommerce_thankyou. However, this is less of a concern than the previous point.

What do you think of an alternative in which we essentially roll back to the previous structure, but add the 'your order has been received' messaging before rendering either the email verification or login forms?

Also, though far less pressing/less essential: the 'your order has been received' verbiage and its accompanying hook is already duplicated twice, so that could possibly also be encapsulated into a function of its own.

[barryhughes]

...yet another alternative could be restructuring the template to something like:

if ( order ) {
    # PRINT THANK YOU/ORDER RECEIVED

    if ( needs_verification ) {
        # VERIFICATION
    } else {
        # SHOW ORDER DETAILS
    }
} else {
    # FINAL FALLBACK
}

With the possible disadvantage that sites with existing template overrides will not gain this additional layer of protection.

[coreymckrill]

@barryhughes

What do you think of an alternative in which we essentially roll back to the previous structure, but add the 'your order has been received' messaging before rendering either the email verification or login forms?

Also, though far less pressing/less essential: the 'your order has been received' verbiage and its accompanying hook is already duplicated twice, so that could possibly also be encapsulated into a function of its own.

This sounded worth trying, so I've opened #39758 as an alternative to this, and added you as the reviewer.

[barryhughes]

• Resolved via Checkout: show "thank you" message regardless of verification status #39758.
• Closing this one.