Woo Analytics: use core WP function to enqueue script

[jeherve]

Related: #13039

Changes proposed in this Pull Request:

• For third-parties to be able to interact with our tracking script, it is easier if it is registered using core WP functions instead of just added to wp_head.

Using wp_enqueue_script makes it easier to dequeue the file if needed, or modify its output with the script_loader_tag filter (one could add an async parameter for example, or add extra data attributes like the Cookiebot plugin.

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

• @psealock I'd appreciate your review on this, to be sure I am not missing anything obvious with this enqueue. Thank you!

Testing instructions:

• Install and activate the WooCommerce plugin on your site.
• Connect Jetpack to WordPress.com
• With or without this patch, you should see the same file being enqueued in the head: <script type='text/javascript' src='https://stats.wp.com/s-201931.js'></script> (note that the exact filename changes week after week).

Proposed changelog entry for your changes:

• WooCommerce Analytics: use core WP function to enqueue script

[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: September 3, 2019.
Scheduled code freeze: August 27, 2019

Generated by 🚫 dangerJS against d184acf

[psealock]

Hi @jeherve, thanks for the ping. I'm trying to test this locally but am having trouble turning off development mode so I can connect to wp.com.

I tried these with no luck:

define( 'JETPACK_DEV_DEBUG', false );
add_filter( 'jetpack_development_mode', '__return_false' );

My url is http://tangaroa.ngrok.io. Do you have any suggestions?

[jeherve]

@psealock What happens if you just comment out all those filters / constants? By default, if your site is publicly accessible, you should be offered the option to connect to WordPress.com.

[psealock]

Thanks @jeherve, this a more legitimate way to load the script. I tested locally and the script is loading correctly. I'm not forseeing any issues around dependencies or load order. Requests for t.gif are firing as they should.

[psealock]

By default, if your site is publicly accessible, you should be offered the option to connect to WordPress.com.

Hmm. Something, which I can't find, is applying the jetpack_development_mode filter. I ended up hardcoding is_development_mode to false.

[kbrown9]

I tested this change using the provided testing instructions, and the file was enqueued as expected.

Do you think there's any value in adding the async attribute using the script_loader_tag filter in this PR? Or should that be a separate PR? Google's Page Speed Insights tool flags the https://stats.wp.com/s-2019xx.js file as a render-blocking resource now that the async attribute has been removed.

[psealock]

Do you think there's any value in adding the async attribute

Good catch @kbrown9! Yes, definitely.

[jeherve]

@kbrown9 That's a good point, you're right! I've just pushed d184acf to add a utility we can reuse in the future to make more scripts async if needed.

[kbrown9]

I tested this PR with commit d184acf using the provided testing instructions. The file was enqueued in the head, and the file's script tag included the async attribute, as expected!