Variables in URL being cached?

Solved
Billy_fox
New Member
3 0 0

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.

Screen Shot 2021-10-22 at 3.49.22 PM.png

Accepted Solution (1)

Accepted Solutions
PaulNewton
Shopify Partner
3419 224 657

This is an 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).

Join the discussion - What was learned this Black Friday?


Answers powered by coffee Buy Paul a ☕ Coffee for more answers or donate to eff.org

Problem Solved? ✔Accept and Like solutions to help future merchants

Confused? Busy? Buy a custom solution paull.newton+shopifyforum@gmail.com

View solution in original post

Replies 2 (2)
PaulNewton
Shopify Partner
3419 224 657

This is an 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).

Join the discussion - What was learned this Black Friday?


Answers powered by coffee Buy Paul a ☕ Coffee for more answers or donate to eff.org

Problem Solved? ✔Accept and Like solutions to help future merchants

Confused? Busy? Buy a custom solution paull.newton+shopifyforum@gmail.com

View solution in original post

Billy_fox
New Member
3 0 0

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.