• Hello,

    All e-commerce events stopped firing when updating from 1.13 to 1.14.1.

    I rolled back to 1.13 and everything is fine.

    Am I only the one with this issue?

Viewing 14 replies - 1 through 14 (of 14 total)
  • Plugin Author Thomas Geiger

    (@duracelltomi)

    Hi,

    Can you share the URL of your site where this is happening?

    Thread Starter madjedo

    (@madjedo)

    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/

    Plugin Author Thomas Geiger

    (@duracelltomi)

    Thanks for the staging link, I am checking it right now…

    Plugin Author Thomas Geiger

    (@duracelltomi)

    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…

    Plugin Author Thomas Geiger

    (@duracelltomi)

    Could you try adding gtm.js to the exclusion list of Perfmatters?

    https://perfmatters.io/docs/defer-javascript-wordpress/

    Thread Starter madjedo

    (@madjedo)

    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.

    Thread Starter madjedo

    (@madjedo)

    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,

    Plugin Author Thomas Geiger

    (@duracelltomi)

    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?

    Thread Starter madjedo

    (@madjedo)

    Hi Thomas,

    Sure we can do that.

    You mean I paste and replace with the old js file.

    Thread Starter madjedo

    (@madjedo)

    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.

    Plugin Author Thomas Geiger

    (@duracelltomi)

    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.

    Plugin Author Thomas Geiger

    (@duracelltomi)

    Thread Starter madjedo

    (@madjedo)

    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,

    Plugin Author Thomas Geiger

    (@duracelltomi)

    If everything goes well, v1.14.2 will be released on 27th December

Viewing 14 replies - 1 through 14 (of 14 total)
  • The topic ‘Update 1.14.1 broke E-commerce events’ is closed to new replies.