For some reason, when I attempt to add the block to the main-product.liquid page directly, it works, but it doesn’t seem to work as expected when I try to implement it as demonstrated above. I’ve experimented with adding the block to various locations within the main-product.liquid file, and all of them seem to work as intended. See below:
Adding it in custom_liquid section (Works fine, meaning I can get the desired value in cart as well as in the final order in the backend):
Everything functions properly, except for an issue I’ve encountered when attempting to configure it within the Shopify user interface (UI). In my quest to identify the problem, I’ve managed to pinpoint the issue, but I’m uncertain about how to resolve it. My assumption is that it should work seamlessly, as otherwise, it raises questions about why Shopify introduced this feature in the first place. What I’ve observed is that when we transmit this custom Liquid code from the Shopify UI, there are rendering problems with the form. The second instance of the form, as sent from the UI, appears to lack the expected values, as illustrated below.
Have others encountered a similar challenge? If so, any guidance or assistance would be immensely valued. Shopify, if you can also provide any assistance in this matter, it would be highly appreciated. Thank you!
Treat custom-liquid settings as black-boxed standalone assets/templates*.
You have to recreate any needed variables in a custom-liquid setting.
The code in a custom-liquid block is private, scoped , it does not have access to local variables in a section or snippets,
Nor does anything bother to communicate this annoying nuance to the user because the logic silently fails.
We cannot create our own global variables in liquid.
When you output a variable and it’s empty when it you think it should be filled that’s a good sign it doesn’t actually exist in the context you think it does.
Super obnoxious , so {{ product_form_id }} has to be recreated using the same logic as the surrounding sections/snippet that renders the custom-liquid setting. In some case this can be another layer of obnoxious if the variable is using even more properties/variables the custom-liquid doesn’t have access too.
*The reason I say assets or templates instead of snippet is because at least with {% render %} you can pass in parameter arguments, not so much with custom-liquid settings; even though there is a syntax and system that shows example how to do this at least with interpolation: the locale keys translation system and "| t: " liquid filter.
Edit: It appears to be functioning now. Thank you! Would you be able to shed some light on why this issue might have occurred? As Paul mentioned above, the Shopify Liquid code can be somewhat like a black box. I’m speculating that the code might not have complete access to certain elements, possibly due to restrictions related to the main form object but can access other fields such as section.id in this case.
You’re right when you mention that the custom Liquid box in the Shopify UI is like a blackbox and has no access to these variables.
Could you please provide more details regarding the statement, ‘recreated using the same logic as the surrounding sections/snippet’? Does this mean there’s a way to replicate a similar state and integrate it into the same form object, or possibly a different one that’s still connected to the same object used in the cart and the backend? If such a method exists, could you provide some guidance or code to point me in the right direction, because I would ideally want to handle everything from the UI?
I want to ensure I’m interpreting your advice accurately. If it’s not possible to achieve what I described above, or do you believe the only viable option would be to handle it from the backend main-product.liquid file?