ensure woo analytics checkout event fires for checkout block

[haszari]

Fixes woocommerce/woocommerce-blocks#2031

Changes proposed in this Pull Request:

• Hooks checkout_process to a new hook fired in WooCommerce Blocks - woocommerce_blocks_enqueue_checkout_block_scripts_after.

This is currently hooked on woocommerce_after_checkout_form from WoCommerce Core. Originally we planned to fire this hook from checkout block PHP render() (#2038 - reverted), but this is not appropriate as extensions will likely render content/markup directly to output from the hook.

Is this a new feature or does it add/remove features to an existing part of Jetpack?

*p7Ldg5-ru-p2

Testing instructions:

setup

• This requires WooCommerce to be installed and set up on the site, with some products. Recommend setting up Cash on delivery payment method for easy checkout.
• Also requires WooCommerce Blocks checkout block – this is still in development, so you'll need to build the source
• The events are disabled for development sites. Use an incognito window, or hack this by adding return true; at the start of Jetpack_WooCommerce_Analytics::shouldTrackStore().

test

• Add the checkout block to a page or post.
• Open network tab in browser dev tools, search for pixel.wp.com.
• View a product on the front end of your site.
• View a page/post containing checkout block. You should see a request for woocommerceanalytics_product_view event.

Optional:

• Test that shortcode / traditional checkout event still works correctly.

Proposed changelog entry for your changes:

• WooCommerce Analytics: Ensure checkout event fires for checkout block (currently in development).

[jetpackbot]

Thank you for the great PR description!

When this PR is ready for review, please apply the [Status] Needs Review label. If you are an a11n, please have someone from your team review the code if possible. The Jetpack team will also review this PR and merge it to be included in the next Jetpack release.

Scheduled Jetpack release: April 7, 2020.
Scheduled code freeze: March 31, 2020

Generated by 🚫 dangerJS against 696c378

[nerrad]

Code wise, this looks okay, I did not test.

[nerrad]

While I approved based on the code alone, I am wondering what value this tracking will bring in differentiating between shortcode checkout and block checkout? As far as I can tell when we analyse the data from these fired events, we won't be able to distinguish between what event came from the shortcode checkout and what event came from the block checkout right? Is that important?

[jeherve]

This looks good to me. I rebased to address some unrelated issues with e2e tests that were causing Travis tests to fail here.

I'll let you make the final merge decision based on the discussion above though.

[deltaWhiskey]

Looks good to me. Did not test.

[haszari]

As far as I can tell when we analyse the data from these fired events, we won't be able to distinguish between what event came from the shortcode checkout and what event came from the block checkout right? Is that important?

@nerrad Yes that is important! And we ideally need to know that for all events, e.g. purchase (order completed) also.

In #15127 we added props to all events for whether the store uses shortcodes or blocks for cart and checkout. The plan is to segment the events based on those props.

FYI we've also added the woo version (#15028) so we can segment by that if needed.

@jeherve I'm going to merge this :)

[jeherve]

Cherry-picked to branch-8.4 in 08a964f