New Woo brand announcement v2 | Feb 4, 2025

Added by Mahrie - https://woomarketingstudio.wordpress.com/2024/12/20/studio-request-logo-rollout-customer-comms/

Product Icon

WooCommerce

Sell online with the flexible, customizable eCommerce platform designed to grow with your business. From your first sale to millions in revenue, Woo is with you. See why merchants trust us to power 3.4 million online stores.

Performance: Caching of product pages with preselected product variant

Problem

If we call up a product page of a variable product and there is an attribute in the URL (?attribute_pa_*), then there is a problem.

The parameters preselected via the URL are marked as “selected” on the server side in the “wc_dropdown_variation_attribute_options” function.

We ignore the attributes in the query due to far too high time to first byte (which damaged our Google Ads quality factor) in our cache guidelines.

This necessary action results in additional product page views, which may have a different pre-selected attribute, being displayed with incorrectly pre-selected option values.

To clarify with an example:

– Page call 1: ?attribute_pa_color=red => Page is cached with the server side generated preselection of the option “red”. User sees “red”
– Page call 2: ?attribute_pa_color=blue => Page is loaded from the cache with the preselection of the option “red”, JavaScript does not select the option “blue”. User sees “red”.
This is wrong. “blue” is expected.

We have to choose between: People coming via ads, showing the wrong product OR disabling cache and suffering way too high time to first byte.

It would be nice if the URL state is dynamically synchronized with the form state once during page load.
Maybe even with deactivation of server side selection just to ensure users with script errors will not see false preselection.

We would be very happy if you could provide an improvement.

Proposal

It would be good if there were a PHP filter that allows developers to choose between a server-side and a client-side preselection of a product variant for product pages of variable products with attribute_pa_* properties in the query parameters.

Use case

The use case clearly relates to online stores that send users directly to product pages that preselect properties via URL.
This is common for Google Shopping Ads, for example.

Performance is important there, so we as store operators are very interested in delivering such specific variant page views via cache (e.g. via WP Rocket).

We therefore cache a product page and deliver this cached version, regardless of which query parameters are in the URL.

To ensure that the whole process runs smoothly, the product variant should then be selected on the client side via JavaScript after the cached product page has been delivered.

Implementation

By default, it can remain as it is.
On the server side in wc_dropdown_variation_attribute_options(), select the variants that can be read in the URL.

If the filter described above is used by a developer to perform the preselection on the client side, the following should happen:

1.) The function wc_dropdown_variation_attribute_options() or its caller ensures that only the product variation defined as the preferred variant in the backend is marked as “selected” in the HTML on the server side and delivered. (Or no variation if no preferred variation has been defined by the store operator). The query parameters in the URL are therefore ignored during server-side HTML generation.

2.) On the client side, i.e. via JavaScript, the possibly existing query parameters in the URL of a product page should be synchronized with the selectable product properties. This means: If, for example, ?attribute_pa_color=red is in the URL, then the WooCommerce JavaScript should automatically select the red product variant, if possible.

Here is an example of JavaScript code that only refers to the color example.
If you were to implement it ready for production, you would probably first go through all the properties in the add to cart form in a loop, then check the query parameters associated with the individual select fields and set any values found accordingly via JavaScript.

function initSingleProductPageVariationsForm() {
const searchParams = new URLSearchParams(window.location.search);
const COLOR_ATTR = “attribute_pa_color”;
const queriedValue = searchParams.has(COLOR_ATTR) ? searchParams.get(COLOR_ATTR) : ”;

const selectField = document.querySelector(‘form.variations_form.cart select[name=”‘ + COLOR_ATTR + ‘”]’);
if (!selectField) return;

let isQueriedValueAvailable = false;
const selectedIndex = selectField.selectedIndex;
for (let i = 0; i < selectField.length; i++) {
const option = selectField.options[i];
isQueriedValueAvailable = queriedValue === option.value;

if (isQueriedValueAvailable) break;
}

selectField.value = queriedValue && isQueriedValueAvailable ? queriedValue : "";

selectField.dispatchEvent(new Event("input", {
bubbles: true
}));
selectField.dispatchEvent(new Event("change", {
bubbles: true
}));

console.log({
isQueriedValueAvailable,
queriedValue,
selectField
})
}

jQuery(function() {
initSingleProductPageVariationsForm()
});

We, and presumably many other online store operators, would be happy to see an improvement in WooCommerce in the future.

If the proposed improvement lands, then caching plugins, such as WP Rocket, can automatically and safely ignore URL parameters in the style of attribute_pa_* on product pages, so that many stores should generally benefit from this improvement in terms of loading time and thus also conversion rate.

Author

robertrosanke

Current Status

Open

Last updated: January 29, 2025

0 comments

Log in to comment on this feature request.