gbruzzo

Dear Plamen,

thank you for confirming that the first approach used was in fact the correct one (minus the ‘=’).

For the sake of better understanding, could you please explain how

add_filter( 'sgo_bypass_query_params', 'add_sgo_bypass_query_params');
function add_sgo_bypass_query_params( $bypass_query_params ) {
    // Add custom query params, that will skip the cache.
    $bypass_query_params[] = 'query_param';

    return $bypass_query_params;
}

and

add_filter( 'sgo_ignored_query_params', 'add_sgo_ignored_query_params');
function add_sgo_ignored_query_params( $ignored_query_params ) {
    // The query parameters which will be ignored.
    $ignored_query_params[] = 'query_param';
    $ignored_query_params[] = 'query_param2';

    return $ignored_query_params;
}

work?

Thanks again in advance

Giacomo Bruzzo

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

Dear @hristo-sg

thank you for taking the time to address my query.
You have clarified my queries, directly and implicitly, all understood, thank you.

I am really looking forward to hear about new tech coming from Siteground. What I have experienced until now has been unquestionably excellent and beneficial.

Cheers

Giacomo Bruzzo

Hello there,

hope you are all well.

Maybe this is not the place to ask broad development questions not immediately related to a support issue. I certainly do not wish to abuse your time.

If that is the case, could you please suggest a place I may submit my question above?
Siteground Support is now very automated and pre-filtered, and I am uncertain where to ask questions as the one above (there are no forums that I know of, for example).

I certainly would appreciate receiving an answer to my question above (or similar ones in future). (I am a VPS customer, btw.)

Thanks in advance for any clarification.

Kind regards

Giacomo Bruzo

Dear @hristo-sg

thank you very much for taking the time to respond.

I think I broadly understand your point, though my question was related to the type of CF worker SG optimizer parametrises/uses.

If I understand correctly, you register only one worker called sg_worker.

If I also understand correctly, cloudflare APO uses KV workers instead (or on top of regular workers? not sure to be honest). As stated on their launch blog post (https://blog.cloudflare.com/building-automatic-platform-optimization-for-wordpress-using-cloudflare-workers/) “it only requires a single request to the page to cache it and within a minute it is made available to be read back from KV from any Cloudflare data center.

This would certainly be very beneficial to sites with few delocalised (but very valuable) customers.

It is clear that accessing CF via SG Optimizer is spectacularly easy (single click no DNS configuration – absolutely amazing); I also do not think SG Optimizer and APO should be used together, there is too much overlap ‘under the hood’.

My question is though: Have Siteground / the Caching Team considered implementing the scheme offered by APO in SG Optimizer, using KV workers to push assets to peripheral stores automatically, and therefore reducing page load times on the periphery?

Thank you in advance for your responses ,

Giacomo Bruzzo

• This reply was modified 3 years, 5 months ago by gbruzzo.

Dear @stoyangeorgiev

thank you for pointing it out to me. I figured out that the ‘culprit’ was

(function () {
var c = document.body.className;
c = c.replace(/woocommerce-no-js/, 'woocommerce-js');
document.body.className = c;
})();

This turns out to be a function in woocommerce/includes/wc-template-functions.php
https://woocommerce.wp-a2z.org/oik_api/wc_no_js/

once this inline script is removed from the combined js, downloads resume correctly.

Will flag the issue to YITH developers.

Thanks again for pointing me in the right direction.

Giacomo Bruzzo

• This reply was modified 3 years, 7 months ago by gbruzzo.

Hello there @stoyangeorgiev

thank you for your answer!

Giacomo Bruzzo

@hristo-sg

Thank you very much

Hello @hristo-sg

thanks for your response. I honestly do not know who should ‘take responsibility’ for this one (my 2c would be the Chromium devs, but that would require someone going down a rabbit hole). SG optimizer is technically doing nothing ‘wrong’, nor is the plugin whose css is being affected.

I have written to the developer of that plugin whose code is being affected suggesting they change ‘1000’ to ‘999’ or ‘1001’ (these quantities do not get ‘minified’), but I do wonder whether this is the right thing to do.

In any case, many thanks

Giacomo

Dear @sstoqnov

maybe of interest to others: I have implemented

add_action( 'woocommerce_cart_item_removed', 'after_remove_product_from_cart', 10, 2 );
function after_remove_product_from_cart() {
  if ( WC()->cart->get_cart_contents_count() == 0 ) {
        		WC()->session->destroy_session();
	}

}

as per your suggestions (only changed the hook to run just after the item has been removed). I will test further to see if removing a the session cookie when emptying the cart causes issues elsewhere.

At the risk of sounding like Don Quixote, I would prefer to be able to change the caching behaviour at the server level, rather than change default Woocommerce session behaviour to achieve better caching.

In any case, thank you all very much for the support

Giacomo Bruzzo

Dear @sstoqnov

Thank you

I will try this out.

I hope you reconsider offering customers the option to serve cached pages when the wp_woocommerce_session cookie is present. (Other providers, such as Kinsta, allow for specific server rules – see: https://kinsta.com/blog/wordpress-cookies-php-sessions/#3-exclude-pages-from-cache-when-the-cookie-is-present).

This kind of option would be welcome for VPS subscribers such as myself.

Kind regards,

Giacomo Bruzzo

• This reply was modified 3 years, 8 months ago by gbruzzo.
• This reply was modified 3 years, 8 months ago by gbruzzo.

Hello @hristo-sg

thank you for your response.

It was not my intention to upset or criticise you or your team, I am genuinely just trying to understand.

If you read the first post above, you will see I described a sequence of actions on an installation with only WordPress, Woocommerce and storefront. No other plugins are involved.

The issue I face is : if a customer adds a product to cart, then removes it, they will have to wait for the Woocommerce session cookie to expire (2 days) to get a new cache HIT. Until then, cache will be bypassed. That seems like a long time to wait, and time is money.

thanks in any case

Giacomo Bruzzo

Hello @sstoqnov,

thank you very much for responding to my query.

Could you please clarify further, as I am not sure what you mean by ‘caching sensitive data’?

If I am not mistaken, each wp_woocommerce_sessions_ cookie points to an entry in the wp_woocommere_sessions table. This table holds information relating to the cart, product in cart and associated statistics, but certainly no credit card information.

As far as I understand, payment token data is stored in other tables (wp_woocommerce_payment_tokens, wp_woocommerce_payment_tokenmeta for Stripe etc), irrespective of the wp_woocommerce_sessions.

I therefore don’t understand what ‘sensitive‘ data could be gleaned from cache that cannot already be gleaned from the site itself. Are these GDPR issues? Please help me understand.

Not caching when the wp_woocommerce_session_ cookie is present seems like overkill. I could in the limit understand if you did not cache when woocommerce_items_in_cart=1 is present (though even this should be necessary, if you update the cart via ajax).

I really would like to use your plugin on our e-commerce instead of our previous solution (WP Fastest Cache), but this cache BYPASS is quite problematic for us.
TTFB of pages goes up from 40-100ms to 1 – 2s depending on the page (Woocommerce pages are in particular affected) when cache is BYPASSED – all benefits are gone.

Would you please consider making the cookie BYPASS optional?

If you do not, can you suggest options? I considered shortening the expiry time of the woocommerce session cookie to 10-15 minutes, but not sure it’s a great idea.

Thank you in advance for any further comments.

Giacomo Bruzzo

Update: We ran the same on a test site with minimal plugins (WP, WC, SG Optimizer and very few others) with Storefront.

See https://www.densesignals.com/releases

the same occurs: when the woocommerce session cookie is present, the cache will be bypassed. This is very problematic.

A customer visiting the site, adding a good to cart, then removing it, then visiting the site again will be served the site without caching, as if he/she was logged in (which is not the case).

Please advise

Giacomo Bruzzo

Dear @hristo-sg

thank you for your response.

All that follows is without any user logged in

I noticed the following:

Cache BYPASS is being triggered when cookie

wp_woocommerce_session_………………. is stored

Step by step :

1. go to shop page (see https://www.rarenoiserecords.com/releases) => x-cache HIT

2. add product to cart (ajax) => Cookies : woocommerce_items_in_cart,
woocommerce_cart_hash,
wp_woocommerce_session_……………….
are stored

3. refresh page => x-cache BYPASS

3. remove item from cart (ajax) => Cookies : woocommerce_items_in_cart woocommerce_cart_hash are removed, wp_woocommerce_session_………………. is still stored

4. refresh page => x-cache BYPASS

5. manually remove cookie wp_woocommerce_session_……………….

6. refresh page => x-cache HIT

I am confused, as I thought you did not BYPASS when wp_woocommerce_session_…. was stored (see https://www.ads-software.com/support/topic/woocommerce-setup-2/ but maybe that was a long time ago)

How can I change this behaviour? I am getting bypasses when I should not it seems.

Thank you in advance for your assistance

Giacomo

• This reply was modified 3 years, 8 months ago by gbruzzo.

Dear @sstoqnov

Thank you for your response and for sharing the link: will look at the code in detail and revert, if I have more questions.

Giacomo Bruzzo