Up until last week, visible_if could be used to show and hide resource inputs (product, collection, page) as long as the conditional was based on the value of a supported input type (checkbox, select, etc).
Not being able to use visible_if to toggle between collection and product_list inputs would be a big loss. The conditionals still work in the theme editor but Shopify throws an error preventing file-save. I made a reproduction code gist here.
To clarify, the use case is to show/hide resource inputs based on the value of supported input types, select and checkbox. This use of visible_if still works in the theme editor, but I canât touch any file that uses it.
Update: This appears to be specfic to /blocks schema. These settings will save and work correctly in seciton-level settings and classic block settings.
@Gideon We donât allow conditional resource settings, this is an intentional limitation as it conflicts with closest.<< resource >>. The fact that it worked up until now was a gap in our validation. You can find the list of supported conditional settings here.
Update: This appears to be specfic to /blocks schema. These settings will save and work correctly in seciton-level settings and classic block settings.
Let me verify, but I believe this is another gap that weâll be addressing in the near future.
Not being able to gatekeep those is big loss for merchant usability imo. I think the visible_if is great at making the schema settings in theme editor more merchant friendly and this feels like big loss on that regard.
I understand why it would be problematic to parse a conditional statement that depends on the value of a closest resource.
This conditional uses a select input.
The docs do not differentiate between settings that can be used in a conditional statement and input types that can be shown/hidden. It seems like those are two very different things?
@Gideon There are two separate restrictions to know:
Conditional settings canât access runtime context or values from resolved data sources. This is aligned with what you are saying.
Only the inputs listed under The following settings support conditional settings on that page can be shown or hidden conditionally. product and collection are not on that list, so you canât use conditional logic with them. Iâll update the documentation to make this more clear.
@misha with all due respect point number 2 is absolutely ridiculous.
I can accept that we canât use the value of a resource input for another settingâs visible if condition. However, the fact that resource inputs are completely blocked off from visible if, is just insane. I donât mean to ask too much but I think the community needs some detail on this as to why this is the way things are at the moment. We have an explanation for point 1, so what about point 2?
Regardless of visible if hiding or showing an input our liquid code already has to handle fallbacks and managing input data when the conditions have it hidden. So it canât be something like âwell itâs just a data point we wouldnât want to have hidden but still referenced in codeâ.
Honestly it seems like a blatant code mistake that the resource input types were just blanket excluded.
Make visible_if work for all settings, add a warning in the documentation and leave the specifics to us, thatâs our job. The feedback is real and the requirement is clear, make it happen please !
There is no point in having this visible_if property if we need to tiptoe our way using it.
@Matthew_Crigger I get it, and youâre right to call this out. It does feel like an arbitrary limitation.
There are technical reasons why resource inputs canât work with visible_if right now, but sadly I canât get into the specifics of what those are. This isnât a permanent decision - itâs just not on our roadmap right now.
Thanks for the feedback though - it helps us understand where the pain points are.
Speaking from experience, the documentation can sometimes be a little light on, and needing to reach for documentation to validate that a feature, which is working in the OSR / OSE, is officially sanctioned is not realistic.
When sections are marked as invalid, the OSR does not fail gracefully, it invalidates the entire route that consumes the template and 404âs.
While there are some guards in place to limit the production impact for a merchant on a breaking change like this, this breaking change has felt like itâs flown a little close to the sun.
Letâs take the following scenario:
Merchant duplicates a theme that is currently working, because the section was previously marked as valid.
Since the section is marked as invalid on duplication, templates now referencing said section are now invalid, and 404.
Merchant goes through and updates un-affected templates, not realising that the duplicate theme now has invalid routes. Because they are only updating unaffected templates, they donât realise parts of their sites are 404âing.
Merchant goes to publish said theme.
Theme publishes successfully.
Merchant is now 404âing on the product route.
The merchant was at no point:
Notified that the theme duplication process did not work.
That routes would now 404 if a template included the affected section.
Prevented from publishing a broken theme.
I think there would have been far more graceful ways of deprecating a feature that once worked.
@misha this is a big breaking change. Weâve had to submit a new version of our themes in a hurry as some sections could not be added anymore (and as Kurt explained, if a JSON file such as index.json were referring one of those sections, the whole file wonât upload and generate a 404). Shopify has usually cared a lot about BC, it is surprising that a BC was done (without prior communication to devs) that can cause such issue.
Just to be sure, I can see that image_picker (which is a resource) is still in the list. Can you please therefore confirm that using this (where logo is an image_picker) still supported and wonât be removed?
This is going to stop us from making any updates, and with very little heads up !!! We deprectaed some fields using this and now this will be tough to migrate from as well! would request some time atleast to make this change! We were using this in our theme app extensions, so now we are unable to deploy any extensions at all!
@Gideon, I canât help you with the arbitrary conditional logic restriction weâre all running into but I wanted to propose an alternative approach to what youâre doing. My âProduct Cardsâ theme block starts with a URL field. I then use visible_if to look for things like â{{ block.settings.url contains âshopify://collections/â }}â or â{{ block.settings.url contains âshopify://products/â }}â. If itâs a collection, I have a select input allowing me to select whether Iâm showing a single card for this collection or if Iâm showing a collections products. If itâs a product URL, simply show the single product card.
This doesnât help if you want to us the Product List field in your block but in my experience, when I want to add multiple products individually, I can do so just by adding individual Product Card Blocks. I like this approach since it also allows you to create cards for other uses like non-product related links, as well as links to pages, blog articles and other Shopify resources. It also allows me to mix and match so, for example, I can add a block showing products from a collection and precede that with a second block showing a single, featured product (or even a non-product block like an image, content or video).
But yes, I agree with everyone else. Shopifyâs need to impose restrictions where itâs not really needed is one of my biggest complaints with the platform. If something will fail if misused, trust us as developers to check for and fix that - just document it so we know. Itâs what we have to do for every other type of code/platform so whatâs the problem here. If itâs possible but can have some risk, document it and let us choose to use it.
Sorry, one follow up to this. Since âCardsâ generally have a featured image and my cards can be Pages and Blogs as well, this posses a problem since those donât have featured images natively in Shopify. I work around this by adding a âFeatured Imageâ metafield to each but the fact that there is no featured image for these core Shopify objects already is very strange IMO. You have them for Products, Collections and Blog posts. For the sake of consistency Shopify, it would be nice if all of these objects were consistent. Just a suggestion.
