madjedo

Well I already told you I tested on both settings. It is when enabling your setting of enhanced styling it doesnt work. I would like to keep the enhanced styling, but primarily only for the ajax load more. So maybe there is a way to only keep the ajax load more button as a temporary fix?

Sure I just translate them under WPML > String Translation > wcml-reviews

https://ibb.co/J753RjQ

• This reply was modified 1 year, 7 months ago by madjedo.

Yes bbut what about code?

I suspected this was PHP compatibility issue.

Site is running on PHP 8.1.9.

I tried installing on PHP 8.0 but same error.

Worked on PHP 7.4.

Can you please confirm PHP versions your plugin (free and premium) is compatible with?

If you are able to setup a sandbox environment for me with a default wordpress and woocommerce installation I can install your plugin and test.

Thank you for your thorough response @aljullu

Though lazy loading, and other similar “tech” usually strike me as tricks instead then actual performance gains. One way or the other, the assets are still going to load.

And when you consider the number of users with old smartphones and slow 3G connections, this becomes an important issue. Especially when we are talking e-commerce and conversion rate optimization.

Since opening this ticket I have tested a few other cart plugins. And they all manage to load about 75% less resources then yours. And just from the looks, they seem to behave almost exactly the same as yours. Your plugin/block does however win out in ‘accessibility’.

I haven’t done a lot of more detailed testing on your mini cart block to understand where or why it needs all these assets. But I guess it’s coming from different libraries for javascript, CSS, and fonts. So I would encourage you to see what else could be done for performance other than just lazy loading because lazyloading is just lazy.

Other than that, your block works and looks just fine. It is also accessible, which is a huge plus for me.

I am not following anymore…

I asked why you have CSS styling outline: none applied.

Then you send me a link stating (that I already attached) stating this is a bad idea…

One example of your submit button not being accessible:

https://wpforms.com/templates/email-signup-form-template/

* Have your dev’s consider removing this styling so that outline styling defaults to browser default.

Kind regards,

• This reply was modified 3 years ago by madjedo.

Hi Prashant, thank you.

I don’t have anymore questions except for the inquiry regarding the submit button outline.

Kindly,

mm… And you also want 2000EUR to translate the URL slugs…

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,

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 Thomas,

Sure we can do that.

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

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, 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.

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/