Tomek

Hi @amberwellhealth,

Sorry to hear you struggle with the error. However, I’d like to note, that the reports were deprecated long ago, and the amount of support and improvements there may be limited.

I was not able to reproduce it on my test environment. But looking, at the code, I was able to mimic the same error by corrupting/erasing the post_date of one of the orders. It’s worth double-checking if there is not other plugin, or code fiddling with that, or one of the hooks (woocommerce_reports_get_order_report_data, woocommerce_reports_get_order_report_query, woocommerce_reports_get_order_report_data_args).

To help us debug it further, could you try to narrow down the range of orders , by filtering a single date that produces this error? Like: /wp-admin/admin.php?page=wc-reports&tab=taxes&report=taxes_by_date&range=custom&start_date=2024-10-30&end_date=2024-10-31. Then, check those orders for something suspicious.

Hi, I strongly recommend running 2.1.4+. We added this error message there, to help you identify the issue. With the versions <2.1.4, the issue you face would still persist – our extension will not get the product ID and will not add product data for tracking – but without the error message it could go unnoticed.

with your plugin activated but no “Google Analytics Tracking ID” entered everything works as expected

Without your Google Analytics Tracking ID entered, our plugin is effectively disabled. So, I’d say it’s rather a conflict, and the Astra theme is tempering with an add-to-cart button.

Hi @matilavag ,

What tool do you use to inspect gtag? I use https://tagassistant.google.com/ and I tried reproduce your case connecting to my store via VPN from Chile and it looks like that https://snipboard.io/D4bYEw.jpg. So even though the consent mode configuration code for European regions is present, it does not affect visitors from Chile. All consent states are left not set.

Here, you can see it for a visitor from EU https://snipboard.io/y86l7I.jpg

Therefore I’m afraid the underlying problem may be elsewhere, not just in consent mode. Have you checked the browser console for any JS errors?

To double-check if the consent configuration is the problem, you can temporarily add a snippet to explicitly grant consent for Chile:

add_filter(
    'woocommerce_gla_gtag_consent',
    function( $old_config ) {
        $additional_config = "
        gtag( 'consent', 'default', {
            analytics_storage: 'granted',
            ad_storage: 'granted',
            ad_user_data: 'granted',
            ad_personalization: 'granted',
            region: ['CL'], // <--------- SET IT TO YOUR REGION
        } );
        ";
        return $old_config . $additional_config;
    }
);

https://snipboard.io/T1i37P.jpg

Also, you can temporarily remove the consent config completely. with return '';

However, I would not recommend using those on a live store, as Google requires this setting for the EEA and a few other regions. Plus, it may have some legal consequences, which I cannot advise you on.

—-

BTW, I recommend updating to the latest version of the GL&A, as we recently improved the integration with other consent-related plugins via the WP Consent API.

Also, please use the latest version (2.7.4) where we improved the integration with other extensions through the WP Consent API plugin.

• This reply was modified 5 months ago by Tomek.

Hi there,

We fixed this issue recently in the 2.1.1 release. Please update, and check if it works for you.

Hi there,

In 2.1.0 to improve the integration with plugins like Complianz, we implemented the compatibility with WP Consent API. This is a plugin that acts as a bridge between plugins. Thanks to that, the Google Analytics for WooCommerce should work with other compatible plugins, listed on their site. Currentyl, it’s Complianz GDPR/CCPA, Cookiebot, GDPR Cookie Compliance.

If you’re facing problems with Complianz, first, please make sure you’re running the latest version of Google Analytics for WooCommerce (>= 2.1.0), have the Tracking ID set in the setting, and install the WP Consent API.

I’m not sure yet, what’s the problem on your site. Could you share the URL?

Just a guess: If you’re setting your default state by yourself in the theme, then maybe the problem is GA4W overwrites it. You can use woocommerce_ga_gtag_consent_modes filter to set the GA4W’s mode to what you need.

Do you know how Moove updates the consent mode? and what do you mean by “it adds in GA”?

From my brief testing, it seems that GDPR Cookie Compliance’s gtag('consent','update'...) comes too late after we already track the view_item_list and other page-load events. The update it long after DOM content is ready and the whole document is loaded. Runtime events are working fine.

I even tried tweaking the GA4W code, to track its events async 1ms after window load event, but still, it was too early for GDPR Cookie Compliance’s update :/

We’re preparing another release with slight improvement towards integrations, but I’m afraid we need a bit more investigation to solve this one.

Please let me know if it helps, or if you could give more details.

Hi @jtyekettle,
Did you notice any errors, in the browser’s console using 2.0? Did it stop tracking visitors only from EAA (Europe), or also from the other regions?

As per 2.0.0+ we configured the required Google Consent Mode. The configuration by default denies tracking for the visitors coming from EEA, to comply with the local law (like GDPR). So, it is somewhat desired to stop tracking that data until a visitor grants an explicit consent.

The consent could be updated/granted using another plugin. You can also tweak the default consent mode using woocommerce_ga_gtag_consent_modes filter.

Google claims to somewhat fill the gaps in data using their algorithms for visitors who didn’t grand the consent.

Also note, that this mode is required by Google since March 6th. Plus, rolling back to 1.8.14 could help, but non-consensual tracking is violating GDPR.

Hi @dabeecher,
Could you please note what GDPR cookie plugin you use? So we could check the integration.

your plugin adds gtag and doesn’t talk to the cookie acceptance behaviour

That’s true. Our plugin adds gtag. But we’re adding it and using it as a means to “talk to” other plugins regarding the cookie acceptance behavior.

We add the default consent state, then other plugins may update it using the gtag API, according to the visitor’s interaction with a banner.

If that’s not working for you, I’d appreciate more details to be able to investigate it deeper.

You can use the existing woocommerce_ga_gtag_consent_modes?filter. To make Google Analytics for WooCommerce not set any consent modes at all make the filter return an empty array:

add_filter( 'woocommerce_ga_gtag_consent_modes', function ( $consent_modes ) {
   return array();
} );

Hi, could you provide more details on what’s broken?

Real-time data differences
With 2.0.0, we released support for Google’s Consent Mode. We use the new API to block cookies for EEA visitors by default until they individually grant consent to follow European GDPR rules.

So, the drop in tracked visitors may be just a result of not getting data from your European visitors. Google claims they would somewhat fill the gaps with modeled data for the visitors who didn’t consent.

Reverting back to 1.x would result in collecting data without visitors’ consent and may have legal implications depending on the local law.

You can customize your consent mode setup using a PHP snippet, as mentioned in the extensions README.

wcgai.trackClassisPages is not a function error

With the new release, we changed the structure of JS scripts. The error you mention may be a result of some caching or a script-defer plugin you use that may reorder scripts. See the similar report.

Make sure any other extension does not change the order & placement of woocommerce-google-analytics-integration script.

Hi @ninetyninew,

Do you consider WooCommerce’s order attribution (OA) to be related based on the presence of wc_order_attribution in the attached screenshot, or do you have more clues? Like, does disabling OA solve the problem?

The error message and the screenshot of the source code suggest that the offending code is the one concatenated after OA’s code. (AFAIK OA-related JS code does not use import statements.)

Could you share a few lines more? Could you check and share what’s inside the ./chunks/vendor-5edb4194.min.js?

Thank you for reporting!
We’ve made a fix that reduces the number of scripts loaded. It targets the WooCommerce 8.6 release.

The fix was released today with 1.8.10

Hi @carmelobaglieri,

Thank you once again for the report!
I submitted the fix, hopefully, we will release shortly.