aheinzel

Thank you @contrid, we appreciate your efforts.

We face the same problem as @timnicklas. We are running Variation Swatches version 1.0.15 with WooCommerce 8.6.1. According to your documentation it is our understanding that the free version of Variation Swatches should not show swatches for out of stock products if hide out of stock products from catalog is enabled in WooCommerce settings and that only the premium version would allow having all swatches shown with those which are out of stock being shown in disabled state (How to disable out of stock swatches – WCBoost Documentation).

The current behavior of the free version does not match the documentation. As @timnicklas already outlined swatches for all variations irrespective of the respective variation being in stock are shown. We would be fine with this behavior as long as variations not in stock would be shown in a disabled state, but this is apparently a feature of the premium edition only. Currently, on page load all variations are shown as if they were in stock and only after onUpdateAttributes (see frontend-min.js) is triggered for the first time out of stock variations will receive the disabled css class and thus be shown in a disabled state.

The current behavior of showing all swatches is due to the fact that swatches for all variations are created in the backend see swatches.php function swatches_html. This function is invoked from function wc_dropdown_variation_attribute_options (woocommerce) via the filter hook woocommerce_dropdown_variation_attribute_options_html. Here woocommerce passes all options to the filter and in consequences the Variation Swatches plugin creates swatches for all options. This behavior closely mirrors the behavior of the woocommerce default functions for creating the dropdown menu for product variations. Here also options for all variation attributes, whether in stock or not, are generated and included in the html served to the client. However, any option elements for variation attributes out of stock are subsequently removed with javascript on the client side (see https://github.com/woocommerce/woocommerce/blob/e38ffc8427ec4cc401d90482939bae4cddb69d7c/plugins/woocommerce/client/legacy/js/frontend/add-to-cart-variation.js#L475).

Hi @vmarko,

sorry for the late reply. No I didn’t post this on github as I felt it is more a general usage/funciton of w3tc question. Shall I bring it over to github?

best,

Andreas

Hello @vmarko,

thanks for getting back at me so quickly. Sorry for the confusion the cookie based cache-group was just mentioned for completeness but is not relevant in the given scenario.

Regarding what I try to cache. My question refers to the page cache (enhanced) feature for caching dynamic pages. In this specific setting /test2/ is a WordPress page. The specific behavior I was interested in was if cookies set (set-cookie haeder in the response) when accessing a dynamic page are also set when the same page is served from cache. Let me please again include the headers from the two example requests provided above and try to highlight the relevant differences.

#state cache empty - page is served from WordPress (set-cookie header is present)
HTTP/1.1 200 OK
Date: Tue, 16 Jan 2024 03:45:51 GMT
Server: Apache
Link: <https://w3dk.test.local/wp-json/>; rel="https://api.w.org/", <https://w3dk.test.local/wp-json/wp/v2/pages/15>; rel="alternate"; type="application/json", <https://w3dk.test.local/?p=15>; rel=shortlink
X-Powered-By: W3 Total Cache/2.6.1
Set-Cookie: test_cookie=1; expires=Wed, 17-Jan-2024 03:45:51 GMT; Max-Age=86400
Upgrade: h2,h2c
Connection: Upgrade
Last-Modified: Tue, 16 Jan 2024 03:45:51 GMT
ETag: "bdee7f0147cd5baa40bed5648ee6d9bc"
Vary: Accept-Encoding
Referrer-Policy: no-referrer-when-downgrade
Transfer-Encoding: chunked
Content-Type: text/html; charset=UTF-8

#subsequent request - page is served from cache (set-cookie header is absent)
HTTP/1.1 200 OK
Date: Tue, 16 Jan 2024 03:47:09 GMT
Server: Apache
Upgrade: h2,h2c
Connection: Upgrade
Last-Modified: Tue, 16 Jan 2024 03:45:51 GMT
ETag: "ee52-60f07f77dabfb"
Accept-Ranges: bytes
Content-Length: 61010
Vary: Accept-Encoding
Referrer-Policy: no-referrer-when-downgrade
X-Powered-By: W3 Total Cache/2.6.1
Content-Type: text/html; charset=UTF-8

As far as I understand the inner workings of W3 Total Cache the page cache grabs the html and saves it to file in the cache dir. Subsequent requests are then directly redirected to the saved file instead of WordPress. Thus any http headers that were added by WordPress to the initial request are missing when the same content is served from cache (see Set-Cookie or Link headers in the example above).

• This reply was modified 10 months, 2 weeks ago by aheinzel. Reason: span added was added to code output when post was submitted