mammadz

Hi @rynald0s and thanks for the filters. I was able to disable loading the js on product pages. No more __stripe_* cookies either. That’s great.

However, I noticed that this plugin is also setting the wp_woocommerce_session cookie on the same product page. That is also undesirable as it gets in the way of hitting the cache. I’m not logged in, and there’s no item in the cart, so I’m not sure why this cookie is set by the plugin. If I deactivate the plugin then everything works as expected and I’m able to hit the cache.

Is there any way to disable that?

• This reply was modified 2 years, 4 months ago by mammadz.

To give you a sense of the performance on mobile (fast 3G with 150ms ping latency):

– Each r.stripe.com/0 fetch is about 650-700ms (10x some overlapping)
– Each m.stripe.com/6 call is about 600ms (2x not overlapping)
– js.stripe.com/v3/fingerprinted/js/trusted-types-checker is another 600ms

All happening on single product pages.

• This reply was modified 2 years, 4 months ago by mammadz.

Hi Con, I think it’s worth digging a little more into this issue because it’s got huge implications.

1) I have disabled express checkout on product pages, yet, the __stripe_mid cookie (maybe even others) is set when visiting those pages. Why?

2) Moreoever, 12 external fetch requests are made to [rm].stripe.com from the product page. Why?

Why should any of these happen when express checkout is disabled on product pages? The net effect of these is unnecessary performance hit and completely disabling caching on perfectly cachable pages.

I personally think the plugin can play nicer here. But, if there’s a way to control this behavior in my own code, I would be willing to do that if you tell me how.

Thanks.

• This reply was modified 2 years, 4 months ago by mammadz.

Hi Rashed, I’m running the latest greatest version 6.4.3 and all other plugins. I’m seeing these external fetches on my product pages even when express checkout is disabled on those pages. I’m also seeing cookies being set (__stripe_*) on these pages which is causing a related performance problem (bypassing the cache).

You can check it yourself on the link provided. Thanks.

Thank you.

So, I also need stripe to not bust the cache. Do I need to open a ticket? Is there any solution that you could share here? Would it be safe to remove the stripe cookies (is there a list?) if there’s no wc session cookie?

Hey Ryan, sorry for the delay and thanks for the suggestion.

Following your suggestion, I was able to remove the cookie, so that worked. To get the cache hit I wanted, I also had to deal with zombie woocommerce session cookies. Once I got rid of that (if cart empty), and not logged in, then I was able to get the cache hit.

Thanks.

Ok, so I found one: https://essentique.com/product/doux/

I don’t see any errors in the console when editing. What I do see is that the text in the meta description box is an old text that I’m guessing is from the old Yoast days and the google preview box shows the correct and current description (%%post_excerpt%%). The only other thing I can think of is that this product is a variable product.

To get around the problem, I’m hooking to seopress_titles_desc and reconstructing the meta there by grabbing the excerpt and doing a do_shortcode myself. But this is a hard coded hack and I think the plugin should just handle this.

• This reply was modified 2 years, 4 months ago by mammadz.

Just as mysteriously as they appeared they have now disappeared. Sorry, can’t find the issue right now. If I run into it again will let you know.

Yes, I agree the support is not great, or pretty bad even. Most likely because the dude is overwhelmed. The plugin is kind of ok and could become even great, but not at this rate. Suggestions to the dude:

– Communicate. And do it often. It doesn’t cost anything and your customers need to know you’re still around. Respond to your paying customers emails. Right now it feels like the plugin has been abandoned.

– Fix bugs. Way too many issues are open and not being addressed. Some are low hanging which could be done quickly, and some are major, like crashing sites that should be prioritized.

– Develop. Looking at the activity here and on github it doesn’t look like much is happening. Can’t remain stagnant.

– Hire. If you’re stretched thin, get help.

– Support. The pro version costs like any other premium plugin but the support is anything but premium. This is not sustainable.

If you don’t turn this around, the moment a better alternative shows up, which it will, you’re going to see a mass exodus of your customers. Hope this helps.

Thanks.

Thanks for addressing this. Could you also describe a little more what is the tradeoff? What would we lose exactly if the feature is disabled?

Interesting that you say it works for you if you share. For me it doesn’t. But thanks for checking.

Here is the curl result when the plugin is active:

HTTP/2 200
date: Tue, 05 Jul 2022 01:19:03 GMT
content-type: text/html; charset=UTF-8
content-length: 252162
server: Apache
…
set-cookie: mailchimp_landing_site=https%3A%2F%2Fwww.essentique.com%2F;
expires=Tue, 02-Aug-2022 01:19:00 GMT; Max-Age=2419200; path=/; secure;
SameSite=Strict
vary: User-Agent
x-cacheable: NO:Got Cookies
x-varnish: 4456585
age: 0
via: 1.1 varnish (Varnish/6.5)
x-cache: MISS
…

And the curl result below after deactivating the plugin:

HTTP/2 200
date: Tue, 05 Jul 2022 02:50:26 GMT
content-type: text/html; charset=UTF-8
content-length: 253550
server: Apache
…
cache-control: must-revalidate, public, max-age=300,
stale-while-revalidate=360, stale-if-error=43200
vary: Accept-Encoding
x-varnish: 720993 4554788
age: 472
via: 1.1 varnish (Varnish/6.5)
x-cache: HIT
…

• This reply was modified 2 years, 4 months ago by mammadz.

You could mark it as resolved but it really isn’t. It’s not a great fix, it’s a hack that one should not need to do, and it doesn’t work for variations.