Why is my product comparison page caching old URLs?

[Billy_fox]

We use a dedicated page to compare products. We load the page by passing the handle for 2-3 products in the URL, parsing the URL in Liquid and loading a card for each product. We sometimes notice that the product comparison page is loading the previously loaded products instead of the ones in the current URL. In other words it appears that the server is caching the response even though the URL variables have changed. To be clear this is not a javascript issue. We don't use JS to load the products - only Liquid. This is an issue on both raceface.com and raceface.ca which share codebases. Any ideas?

Example URLs (go to the 3 pedals page then go to 2 handlebars and it will often still show 3 pedals):

3 pedals: https://www.raceface.com/pages/product-comparison?p1=aeffect-pedal-1&p2=atlas-pedal&p3=chester-pedal
2 handlebars: https://www.raceface.com/pages/product-comparison?p1=aeffect-r-35-handlebar&p2=atlas-35-handlebar

Liquid Code:

{%- capture contentForQuerystring -%}{{- content_for_header -}}{%- endcapture -%}

{% comment %}Use string splitting to pull the value from content_for_header and apply some string clean up{% endcomment %}
{%- assign pageUrl = contentForQuerystring | split:'"pageurl":"' | last | split:'"' | first | split:'.myshopify.com' | last | replace:'\/','/' | replace:'%20',' ' | replace:'\u0026','&' | strip
-%}
{%- assign pageQuerystring = pageUrl | split: '?' | last -%}
{%- assign parts = pageQuerystring | split: '&' -%}
{% comment %}we can now grab the items from the query string and use them in our liquid templates{% endcomment %}
{%- assign p1 = parts[0] | split: '=' | last | strip -%}
{%- assign p2 = parts[1] | split: '=' | last | strip -%}
{%- assign p3 = parts[2] | split: '=' | last | strip -%}

{% assign product1 = all_products[p1] | default: false %}
{% assign product2 = all_products[p2] | default: false %}
{% assign product3 = all_products[p3] | default: false %}

{% assign has-2-products = product2 != false %}
{% assign has-3-products = product3 != false %}
{% assign item-width = '' %}
{% if has-3-products %}
  {% assign item-width = 'has-3-items' %}
{% elsif has-2-products %}
  {% assign item-width = 'has-2-items' %}
{% endif %}

{%- capture item-width-classes -%}
  {%- if has-3-products -%}
    col-4 col-md-4 col-lg-4
  {%- elsif has-2-products -%}
    col-6 col-md-6 col-lg-6
  {%- else -%}
    col-12 col-md-12 col-lg-12
  {%- endif -%}
{%- endcapture -%}

(then we load the product cards based on the variables above)

Notice in the photo below that it should be loading 2 products (handlebars) but instead is loading 3 pedal products.

[PaulNewton · Accepted solution]

If you are having issue with caching make a minimum reproducible usecase by removing ALL irrelevant code except for the core to narrow it down to cache.

This is not always an easy thing because in a sense you need to be able to disprove all code you assume is relevant.

---

@Billy_fox wrote:

We use a dedicated page to compare products. We load the page by passing the handle for 2-3 products in the URL, parsing the URL in Liquid and loading a card for each product. We sometimes notice that the product comparison page is loading the previously loaded products instead of the ones in the current URL. 

---

Shopify has no product comparison feature.

FYI: See the shopify storefront api RFC 

Request for Comment: Faceted Filtering #10  https://github.com/Shopify/storefront-api-feedback/discussions/10 

There's a need for usecases normal or exotic , so in a theoretical filtering could be used to create urls that give the requested selection of products.

The following hack from your code is not supported and prone to issues

{%- capture contentForQuerystring -%}{{- content_for_header -}}{%- endcapture -%}

Output that variable, or the other related variables into your html/js and do a comparison on it to debug it.

For dealing with cache issues stemming from hacks you will need to research to forums for the various discussions and workarounds for busting the cache.

Longshot: might be able to use the view  parameter (?view=alternate-template) as a toggle between visits.

There's also just putting this stuff into cart attributes then refresh, or rehydrate the page(see section rendering api).

[Billy_fox]

The following hack from your code is not supported and prone to issues

Thanks @PaulNewton! It turns out this is the core issue. content_for_header is cached so it can't be used reliably to pass variables to Liquid. It looks like we will have to either pass variables using cart attributes or create a same-page compare solution.

[BaileyPaserk]

Hey Billy, what solution did you end up going with for this problem?