Jetpack: Search: tracks js lib sometimes failing and breaking search overlay

Created on 17 Mar 2020  路  9Comments  路  Source: Automattic/jetpack

Intermittently fails and is maybe related to an old version of the cached s.js file that we use for Tracks. Or maybe it is an error in the loading order. Completely prevents the overlay from opening and so completely breaks search.

The error is:

Screen Shot 2020-03-17 at 11 06 04 AM

The code chain is the call from instant search:

window._tkq.push(["clearIdentity"]),

is then failing on the "API" line here:

    p.prototype.push = function(t) {
        if (t)
            if ("object" == (void 0 === t ? "undefined" : o(t)) && t.length) {
                var n = t.splice(0, 1);
                API[n] && API[n].apply(null, t)
            } else
                "function" == typeof t && t()
    }
    ;

May need @bperson to help here.

Instant Search Search WooCommerce Analytics [Pri] High [Type] Bug

Most helpful comment

The version you're loading still contains the bad API calls. https://stats.wp.com/s-202014.js isn't, so it should sort itself out next week. If you want to double check, hardcode 202014 in your test.

All 9 comments

This is an edge case caused by the site not loading the Tracks library properly; it looks like parts of the library were intentionally omitted in their bundling process and led to this error.

For most of our users, we expect our users to load and instantiate Tracks via this line.

I think we actually have a collision with this happening: https://github.com/Automattic/jetpack/blob/master/modules/woocommerce-analytics/classes/wp-woocommerce-analytics-universal.php#L69

s.js and w.js are maybe colliding? WooCommerce analytics tracking.

@psealock known issue?

@psealock known issue?

Not that I can tell in a quick look. s.js does have outdated dependencies. Do you have steps to replicate?

I can confirm it's coming from s.js directly. If we look at the version on SVN, there is:

API[n] && API[n].apply(null, t);

with no other sign of the initial API. The way it's "set up" in the analytics repo looks weird as well with API only being a local name in the default exported function ... which sounds like it would be optimised away by a bundler / minimiser.

@psealock the easiest way I found to test is to follow instructions for enabling instant search from https://jetpack.com/support/beta-instant-search-and-filtering-prototype/

And then just add the following into functions.php (or some equivalent):

function enable_jetpack_instant_search() {
    define( "JETPACK_SEARCH_PROTOTYPE", true );

    $filename = sprintf(
        'https://stats.wp.com/s-%d.js',
        gmdate( 'YW' )
    );

    // phpcs:ignore WordPress.WP.EnqueuedResourceParameters.MissingVersion
    wp_enqueue_script( 'woocommerce-analytics', esc_url( $filename ), array(), null, false );
}
add_action( 'muplugins_loaded', 'enable_jetpack_instant_search' );

Then when you do a front end search you will see the error. I tried to figure out how to enable woo analytics but I kept running into problems so figured I would just try this. Thanks!

Thanks @gibrown, I'm devoting time to woo analytics code next week:
p90Yrv-1BS-p2

I can look into this as well.

@psealock is there something that needs to be done in Jetpack? I am still seeing http://gibrown.wpsandbox.me/main/?FAIL fail.

The version you're loading still contains the bad API calls. https://stats.wp.com/s-202014.js isn't, so it should sort itself out next week. If you want to double check, hardcode 202014 in your test.

This one is fixed and caches will clear over the weekend. I'll close this one out.

Was this page helpful?
0 / 5 - 0 ratings