I am posting this around for some insight, but I have been able to resolve the rendering issue on the client shop. Today, I had a client theme have a regression of sorts all the way back to the earliest theme in their list from September 2024.
The code goal is to grab the color options of a product and store them in a string array. We have another array of online store visible colors we compare the list to.
First we grab some data about the color option.
# Determine the option index for color, start it off as an impossible number, this will help us leave the value empty if the index isn't found.
assign color_option_index = 1000
assign color_option_name = ''
assign color_option_key = 'option1000'
for option in card_product.options
assign normalized_option = option | handleize
if normalized_option contains 'color'
assign color_option_index = forloop.index0
assign color_option_name = option
assign color_option_key = 'option' | append: forloop.index
endif
endfor
The above code works fine, and always has.
However, when we want to get an array of all color options, the line below suddenly broke today?
assign product_color_options = card_product.options_with_values[color_option_index] | map: 'values' | uniq
This line used to return a string array of the color options on a product. We would gather the options_with_values at the index of the color option, map the values, and then use uniq as a quick way to get a string array, otherwise we couldn’t loop through the options correctly. This line now returns a single index array of only the first color option.
This was the only line of code in the theme that gathered colors this way. Other code instances we had updated to:
assign product_color_options = card_product.options_with_values | where: "name", color_option_name | map: "values" | join: "," | split: ","
The above line is a bit similar. We search the options_with_values where the name is the color option name, we map the values, and then do a join and split for a string array. Without doing the join and split, we get back something we can’t quite loop over, but whatever we have it working for us.
My point is, did something change in Liquid within a day or two, that caused our original line to stop working?
I see the Liquid repo has some recent commits related to some uniq changes, maybe that did something.