raindeer2

Any update on this?

What do you mean by “the log will still show? , but the server should only see nothing tag”

I still see log entries like this:

01/29/22 22:19:12.498 [34.244.18.16:35832 1 jNM] ——POST HTTP/1.1 (HTTPS) ?/shop/wp-json/wc/v3/subscriptions/66797/notes
01/29/22 22:19:12.498 [34.244.18.16:35832 1 jNM] Query String:
01/29/22 22:19:12.498 [34.244.18.16:35832 1 jNM] User Agent: python-requests/2.25.1
01/29/22 22:19:12.498 [34.244.18.16:35832 1 jNM] Accept: */*
01/29/22 22:19:12.498 [34.244.18.16:35832 1 jNM] Accept Encoding: gzip, deflate
01/29/22 22:19:12.498 [34.244.18.16:35832 1 jNM] Cookie:
01/29/22 22:19:12.498 [34.244.18.16:35832 1 jNM] X-LSCACHE: true
01/29/22 22:19:12.498 [34.244.18.16:35832 1 jNM] LSCACHE_VARY_COOKIE: _lscache_vary_shop
01/29/22 22:19:12.499 [34.244.18.16:35832 1 jNM] X-LiteSpeed-Purge: public,stale,54d_FD => LiteSpeed\LSC->send_headers()@558 => WP_Hook->apply_filters(,ARRAY)@303 => WP_Hook->do_action(ARRAY)@327 =>
/home/flovvtes/public_html/shop/wp-includes/load.php@470

and

01/29/22 22:41:58.018 [91.201.60.17:54960 1 l7i] ——POST HTTP/1.1 (HTTPS) ?/shop/wp-cron.php
01/29/22 22:41:58.018 [91.201.60.17:54960 1 l7i] Query String: doing_wp_cron=1643496111.7711660861968994140625
01/29/22 22:41:58.018 [91.201.60.17:54960 1 l7i] HTTP_REFERER: https://flowneuroscience.com/shop/wp-cron.php?doing_wp_cron=1643496111.7711660861968994140625
01/29/22 22:41:58.018 [91.201.60.17:54960 1 l7i] User Agent: WordPress/5.8.3; https://flowneuroscience.com/shop
01/29/22 22:41:58.018 [91.201.60.17:54960 1 l7i] Accept: */*
01/29/22 22:41:58.018 [91.201.60.17:54960 1 l7i] Accept Encoding: deflate, gzip
01/29/22 22:41:58.018 [91.201.60.17:54960 1 l7i] Cookie:
01/29/22 22:41:58.018 [91.201.60.17:54960 1 l7i] X-LSCACHE: true
01/29/22 22:41:58.018 [91.201.60.17:54960 1 l7i] LSCACHE_VARY_COOKIE: _lscache_vary_shop
01/29/22 22:41:58.018 [91.201.60.17:54960 1 l7i] X-LiteSpeed-Purge: public,stale,54d_FD => LiteSpeed\LSC->send_headers()@558 => WP_Hook->apply_filters(ARRAY)@303 => WP_Hook->do_action(ARRAY)@327 =>
/home/flovvtes/public_html/shop/wp-includes/load.php@470

Ive verified?that your script is running.

In Woocommerce each order is a post. This cron job retries the payment of a subscription order. It will add some information to the order, so in some sense it is updating a post but this should not affect the front page in any way what so ever. It would only affect logged in pages of Wooc customers (private cache), API calls, and the admin interface.

Is there anyway I can block the purge due to these events?

I also see that some part of the cache is purged when we add notes to an order:

12/20/21 00:04:12.007 [54.171.34.131:41550 1 kHn] ?? ------POST HTTP/1.1 (HTTPS)  /wp-json/wc/v3/subscriptions/58888/notes
12/20/21 00:04:12.007 [54.171.34.131:41550 1 kHn] Query String: 
12/20/21 00:04:12.007 [54.171.34.131:41550 1 kHn] Cookie: 
12/20/21 00:04:12.007 [54.171.34.131:41550 1 kHn] X-LiteSpeed-Purge: public,3a6_FD,3a6_W.recent-comments-2;private,3a6_W.recent-comments-2 => LiteSpeed\LSC->send_headers()@552 => WP_Hook->apply_filters(,ARRAY)@303 => WP_Hook->do_action(ARRAY)@327 => 
/home/flovvtes/public_html/wp2/wp-includes/load.php@470

What is purged here?

Digging a bit more I see that the cron jobs are woocommerce_scheduled_subscription_payment_retry.

This is a paymenet retry from the Woocommerce Subscriptions plugin.

It looks like this:

12/17/21 08:33:53.459 [91.201.60.17:47438 1 HxG] ?? ------POST HTTP/1.1 (HTTPS)  /wp-cron.php
12/17/21 08:33:53.459 [91.201.60.17:47438 1 HxG] Query String: doing_wp_cron=1639730029.4312500953674316406250
12/17/21 08:33:53.459 [91.201.60.17:47438 1 HxG] HTTP_REFERER: https://flowneuroscience.com/wp-cron.php?doing_wp_cron=1639730029.4312500953674316406250
12/17/21 08:33:53.459 [91.201.60.17:47438 1 HxG] Cookie: 
12/17/21 08:33:53.460 [91.201.60.17:47438 1 HxG] X-LiteSpeed-Purge: public,stale,3a6_FD,3a6_W.recent-comments-2,3a6_Po.63214,3a6_URL./,3a6_W.recent-posts-2,3a6_F,3a6_H,3a6_PGS,3a6_REST;private,3a6_W.recent-comments-2 => LiteSpeed\LSC->send_headers()@552 => WP_Hook->apply_filters(,ARRAY)@303 => WP_Hook->do_action(ARRAY)@327 => 
/home/flovvtes/public_html/wp2/wp-includes/load.php@470

If I understand everything correctly 3a6_F this means that the front page of the site is purge when there is a payment retry??

In Woocommerce orders can have notes. These are small pieces of information attached to an order and are normally only shown in the admin GUI.
The request “POST HTTP/1.1 (HTTPS) /wp-json/wc/v2/orders/63441/notes”
adds a private note to the order 63441.
I dont understand why this would purge any cache. My suspicion is that this could cause our cache to purge when it should not, since we have 3rd party integrations that add notes to order now and then. What does “public,stale,3a6_FD,3a6_W.recent-comments-2;private,3a6_W.recent-comments-2” mean?

Regarding 3a6_, where does this tag come from? What does it represent? How can I see which pages have this tag?

In addition the order note post purge there is this cron job you see above that purges 3a6_. Do you have any idea what this is? It seems to be running every hour or so.

I disabled the banner now, since it looked very strange.

A related question. Why is guest mode really needed, why cant the front page just be publicly cached (when the Wooc cart is empty)? What is different between a normally publicly cached page and the guest mode version?

We still have the same problem.
There is some issue with varying on currency while having geo lookup of currency enabled in WCML

• This reply was modified 3 years, 4 months ago by raindeer2.

We will test this, but note that your rule seems to make it vary on language, not currency. Language is not the problem. We have different URLs for different languages.

• This reply was modified 3 years, 4 months ago by raindeer2.

Thanks!

We tried this and made no difference.

As I mentioned initially I think it is related to WCML not WPML.

If I comment out:

$list[ 'wcml_currency' ] = self::$_currency;

in wcml.cls.php then it works, but I lose the vary on the currency.

• This reply was modified 3 years, 4 months ago by raindeer2.

GZCMTMBG

I can add that it is the first request of a session to a page that is missed, consecutive requests by the same browser session are hits.

Hence, the cache check tool reports constant miss:
https://check.lscache.io/?host=https%3A%2F%2Fflowneuroscience.com%2F

Interestingly that seems to fix it for some pages but not others. The top menu is the same on all pages so that should be the same right?
An advice on how to debug this further?

The css is generated. Please read I write: “The css is generated as it should and I can see the css in the litespeed-optm-css-rules tag”

That is not the problem, the problem is that the page renders very ugly with the generated css. See the screenshot for how it looks when rendered with the generated critical css.

FYI, critical css is disabled on the site now since it creates an ugly flash if enabled.

Thanks, then CSS combine is at least enabled eventhough it gives some weird artifacts. Will look into that later.
But how can I make Litespeed updated the root .htaccess? Or does it work with the one in the subdir?