Alex Kladov

@malayladu I just wanted to add that a point of confusion for some users might be the fact that even after the v1.5.21 release, when you create a new temporary login, you are given an incorrect URL by default, without the special iThemes token.

You’ll only get the correct URL if you click on the “Copy login link” under Actions column.

Here is a screenshot of what I mean:

As you can see, the box that appears after adding a new login displays incorrect URL (without the itsec-hb-token).

@dexter97 omg, THANK YOU! That actually worked! I would 100% prefer server-side validation tbh, but I would take this temp solution over a broken site any day!

Just ran into the same problem.

@mailmechanic’s suggestion helped, thanks!

Hi @stevenjmcconnell ,

Unfortunately, it’s an absolute shame how this very critical bug has been treated to this day – they have accepted @jamescollins’s fix in 1.4.10, which fixed the issue for everyone with correct plugin settings, BUT then they reverted everything back in 1.4.11, breaking all the sites again. The reason for a rollback was the fact that most users had incorrect settings, so the 1.4.10 update has silently affected everyone’s tracking.

On the “bright” side, they’ve added a filter now, that lets developers bypass the setting entirely using a simple filter function. Seems like a copout solution to a very serious problem. I have suggested a different approach, but so far haven’t heard anything back..

As for your question, it would probably be best to use this code below in your functions.php file in your child theme, instead of modifying the core plugin files directly:
add_filter('wc_goole_analytics_send_pageview', '__return_false');

Otherwise, every time you edit core plugin files & update the plugin, all of your changes will be gone. That’s why you might’ve continued seeing duplicates.

This means the last 2 months of my GA data is unreliable.

I’d say more like ANY GA data becomes unreliable, if you use this plugin + a standard GA tracking code. Until they fix this issue, you are better off not using this plugin or using it EXCLUSIVELY (since it tracks standard GA data, whether you want it or not).

Cheers,
Alex

• This reply was modified 5 years, 3 months ago by Alex Kladov. Reason: Edited incorrect filter hook

@jamescollins Oh yeah, you are right! I just saw the last message and assumed that the one above it was from the same date.. That makes it even worse that they just let it sit there for 2 months.

@blackeye0013 Yup, pretty disappointing.

It’s been so long that someone already took it into their own hands and proposed a fix for this. Coincidentally, he just submitted this pull request today on GitHub: https://github.com/woocommerce/woocommerce-google-analytics-integration/issues/143

Hopefully, they’ll accept the PR soon and it will be included into the next official release.

It’s literally just 2 simple lines of code.. Not sure why it took WooCommerce team so long to fix such a major bug.

Hi Matt,

Thanks for getting back to me.

Do you have a local copy of your site, or a live staging environment where you can deactivate all plugins safely?

I do. I will get to it as soon as I can, once I will deal with the workload.

For now I have found a temporary solution – I just disabled the WP Rollback, which seemed to have solved the problem, and will be re-enabling it only if I ever need to roll back any plugins/themes.

My guess at this point is that it’s 99% certainly a plugin conflict of some sort.

My initial hunch is that it’s either LiteSpeed Cache (since that was my initial finding) or maybe Github Updater (because it’s another updates manager for WP).

Regards,
Alex

@stanleylitespeed I have submitted a ticket. My ticket # is 369260.

@leoraphael Same here! This just broke our entire site, since remote jQuery failed to load and therefore all jQuery-dependant scripts threw an error.

Please fix it asap.

Right now you can fix the issue by turning the Load JQuery Remotely under CDN tab to OFF.

Hi @malihu,

Thanks for getting back to me!

When were you planning on making an official release for this feature? I am still working on the site, so I can wait a few days. But if it’s going to take much longer, then I will install the development release first.

Also, it seems to be a bit of a complicated solution.. Wouldn’t it be easier to simply allow users to enter multiple CSS selectors (i.e. each separated with a | character, for example)? Then you can explode those in JS, loop through each CSS selector and add up all of the selected elements heights together to get the offset dynamically. This way users won’t have to add any custom CSS at all and the plugin will just work out of the box.

Also, in this scenario, if my menu shrinks not based on viewport width or height, but on how far along you’ve scrolled down the page (the top header and main header are appended with et-fixed-header class on scroll after X pixels), how would this feature account for that? It would be hard (or maybe even impossible) to setup a CSS dependancy like that.

For example, in my case, at the very top of the page my top header is 45px & main header is 205px, which need a combined offset of 250px. Then, once I scroll down, the top header stays the same, while main header shrinks to 105px, making for a total combined offset of 150px. On mobiles the menu is not fixed, so doesn’t need an offset at all.

So as you can see, the best solution would be to allow for multiple offset CSS selectors, while still checking for selector expressions (i.e. :fixed). That way if those selectors are “fixed”, the script will add up all necessary heights and if any of them stop being fixed (on scroll or on mobile devices), then they won’t be added.

I hope that makes sense.

Sorry, I can’t give you a link to the website right now, because I am still working on it on a local environment.

Regards,
Alex

• This reply was modified 5 years, 7 months ago by Alex Kladov.

Hey,

If anyone is struggling with this issue, try checking your PHP default_socket_timeout configuration! If it’s set to 0 or -1, change it to something above 30.

I spent 4h trying to reset permissions, troubleshoot WP REST API etc. Nothing. It was driving me insane.

Then tried swapping PHP version and it worked! At first, I thought I had something to do with PHP 7.3 compatibility. But then after comparing active extensions & PHP options, I narrowed it down to default_socket_timeout being set to 0. Changed it to 60 and it’s working perfectly on any PHP version.

Jesus I wish this was listed somewhere as a requirement..

Regards,
Alex

Hi @tatvic,

Thank you for your response.

Unfortunately due to issues with GADWP and your plugin, I ended up removing both and instead installed WooCommerce Google Analytics Integration, which provides enhanced WooCommerce analytics & basic standard tracking.

That seemed to have resolved all tracking issues.

Thanks again,
Alex

Hi @johndcoy,

That’s exactly what I was saying. It was still tracking regular event, even after disabling Standard Tracking in settings.

Thanks for creating an official bug report! I will keep an eye on it in GitHub.

Regards,
Alex

Hi @bcrodua,

I just saw a release from today and it included the fix. Perfect, thanks!

Regards,
Alex

Hi @johndcoy,

WooCommerce Google Analytics does track both e-commerce and standard session data.

Since you said that this plugin alone can track both eCommerce & standard session data, I ended up disabling the GADWP for now, because we’ve been losing too much sales data because of all these issues.

Everything seems to be working ok now, but there is a new problem now: I get “No HTTP response detected” error in Google Tag Assistant, but only on our Shop page. Every other page seems to be working fine, as far as I can see.

Can you please tell me why that would be happening?

I have disabled all other analytics plugins & removed all manually entered tracking codes, leaving only WooCommerce Google Analytics Integration.

Regards,
Alex