Hi,
Can you share the URL of your site where this is happening?
I can, but I cant. I rolled back to 1.13 and intend to keep it that way until after Christmas sorry. You will have to do some testing or wait for other users to report…
BUUUT. I have a staging site for you. It’s kinda wonky in some places, and I know this wont site dont fire view_item_list (I fire this based on URL). But all other events should be fine.
I updated the plugin to 1.14.1 on staging site and did some tests myself, and it’s same. No event firing, no add to cart, no view item etc. Only ‘pageview all’ is firing.
This is URL of a product page on staging: https://earthworm.templweb.com/sv/produkter/vali-sakerhetshyvel/
Thanks for the staging link, I am checking it right now…
For some reason the GTM container code gets encoded and never executed therefore the whole tracking setup is not loading at all:
https://www.awesomescreenshot.com/image/18551693?key=cae22b212a3d2e3049204ce2f8428609
As far as I can see you are using Perfmatters to optimize site content.
I wonder why it encodes the container code and why it does not decode and execute later…
Could you try adding gtm.js to the exclusion list of Perfmatters?
https://perfmatters.io/docs/defer-javascript-wordpress/
Hi, thank you for the help.
You are correct. I tried disabling the plugin and it “fixed it”.
I had tried earlier to delay the scripts until user interaction (using perfmatters):
/wp-content/plugins/duracelltomi-google-tag-manager/js/gtm4wp-woocommerce-enhanced.js
/gtm.js
/gtag/js
gtag(
/gtm-
But that didn’t work.
And I now recall speaking to Brett over at Perfmatters, he said something about:
“It looks like the format of that inline script on your site is slightly different, so try adding a line like this to our JS Delay:
googletagmanager.com
”
And so I did, the scripts got delayed and it worked fine. Until now that is.
With your recent update something shifted. Seems like it is like you say, it isn’t executing anymore after the 1.14 update. I am sending a support mail to perfmatters aswell regarding this issue.
Hello again, I spoke with Perfmatters and they took a closer look into why this is happening following the latest update to 1.14.
Basically, you have added a DOMContentLoaded wrapper around the majority of the script. This is causing Perfmatters individual JS delay to break. They can’t do anything about this at the moment since the load event trigger is now triggered behind the wrapper.
Perhaps it’s something they will address in the future since it will require a complete rewrite.
Can you share your thoughts on this or if this is something you can consider leaving out for next patch?
Kind Regards,
Hi,
I guess I see where the problem is.
If I post a link here to an updated JS file that needs to be replaced on your test site, can you do that?
Hi Thomas,
Sure we can do that.
You mean I paste and replace with the old js file.
Hi again,
Just wanted to add a feature request related to this issue as a sidenote.
As you are using DOMContentLoaded, why not use the load event? (https://developer.mozilla.org/en-US/docs/Web/API/Window/load_event)
This way the scripts loads last, after images and css. And I wouldn’t really feel the need to defer or lazyload anything.
Perhaps users could dynamically change this in back-end, so the user picks when they want the scripts to load, after the DOM or after everything.
Just a suggestion I came to think about, might be something you want to consider for performance optimization.
Hi,
My idea is to keep the DOMCOntentLoaded event handler but check whether this has already processed due to situations like yours and in this case there will be a backup firing for the loaded event.
Okay! That seemed to work. I did some quick testing and the events are firing properly know. Thank you.
Will you implement this in an upcoming patch or should I update the livesite with this?
Kind Regards,
If everything goes well, v1.14.2 will be released on 27th December
