[Bug/Featured]: Invalid schema: setting link_list type can only be inserted once in the settings

[notrealdev]

Please confirm that you have:

• [X] Searched existing issues to see if your issue is a duplicate. (If you’ve found a duplicate issue, feel free to add additional information in a comment on it.)
• [X] Reproduced the issue in the latest CLI version.

In which of these areas are you experiencing a problem?

Theme

Expected behavior

Limiting a section to one "link_list" setting seems really restrictive, what if e.g. you want a separate menu for mobile and desktop? It's only an issue with the CLI, Themekit and the Online Editor accepts this fine.

Actual behavior

The CLI throws an error and prevents the file being uploaded.

06:33:12 ERROR » update sections/layout-header.liquid: Invalid schema: setting link_list type can only be inserted once in the settings.

Verbose output

06:33:12 ERROR » update sections/layout-header.liquid:
Invalid schema: setting `link_list` type can only be inserted once in the settings.

Reproduction steps

1. Create a section e.g. "layout-header.liquid"
2. Give it a Schema with two or more "link_list" type settings.

{% schema %}
    {
        "name": "Header",
        "class": "shopify-section-layout-header",
        "settings": [
            {
                "type": "header",
                "content": "Navigation (Desktop)"
            },
            {
                "type": "link_list",
                "id": "main_menu_link",
                "label": "Main Menu"
            },
            {
                "type": "header",
                "content": "Navigation (Mobile)"
            },
            {
                "type": "link_list",
                "id": "mobile_menu_link",
                "label": "Mobile Menu"
            }
        ]
    }
{% endschema %}

3. Run "shopify theme dev" and watch the file fail to upload

Operating System

Windows 10

Shopify CLI version (check your project's package.json if you're not sure)

3.45.4

Shell

Command line

Node version (run node -v if you're not sure)

v18.14.2

What language and version are you using in your application?

ruby 3.1.2p20 (2022-04-12 revision 4491bb740a) [x64-mingw-ucrt]

[cfxd]

Confirming this is still an issue and any previous workaround with the cli does not work

[github-actions[bot]]

This issue seems inactive. If it's still relevant, please add a comment saying so. Otherwise, take no action. → If there's no activity within a week, then a bot will automatically close this. Thanks for helping to improve Shopify's dev tooling and experience.

P.S. You can learn more about why we stale issues here.

[notrealdev]

Issue still here

[trenkwill]

I'm still having this issue

[santiagojimenezh-clouddistrict]

Same issue here

[kyrylo-soulandwolf]

+1

[kgiglia]

We are having a similar issue, though in our case I only see the error when app blocks are enabled on the section.

For example, the following works:

{% schema %}
{
  "name": "Header",
  "class": "section-header",
  "max_blocks": 3,
  "settings": [
    {
      "type": "link_list",
      "id": "primary_menu",
      "label": "Primary menu"
    },
    {
      "type": "link_list",
      "id": "secondary_menu",
      "label": "Secondary menu"
    }
  ],
  "blocks": []
}
{% endschema %}

But with this in blocks, I see the error:

  "blocks": [
    {
      "type": "@app"
    }
  ]

We are using CLI 3.47.5 and Node v18.16.1

Edit: this behaviour is mentioned here so I suppose this is a separate issue, we will have to disable app blocks for now.

[github-actions[bot]]

This issue seems inactive. If it's still relevant, please add a comment saying so. Otherwise, take no action. → If there's no activity within a week, then a bot will automatically close this. Thanks for helping to improve Shopify's dev tooling and experience.

P.S. You can learn more about why we stale issues here.

[ttnbtfy]

Remove this block type to resolve this for me

  "blocks": [
    {
      "type": "@app"
    }
  ]

[github-actions[bot]]

This issue seems inactive. If it's still relevant, please add a comment saying so. Otherwise, take no action. → If there's no activity within a week, then a bot will automatically close this. Thanks for helping to improve Shopify's dev tooling and experience.

P.S. You can learn more about why we stale issues here.

[lucasdelmonte]

Issue still here

[notrealdev]

Issue still here

[NobelIslam]

Remove this block type to resolve this for me

This methods working for me. If you have empty "type": "@app" remove it.

[github-actions[bot]]

This issue seems inactive. If it's still relevant, please add a comment saying so. Otherwise, take no action. → If there's no activity within a week, then a bot will automatically close this. Thanks for helping to improve Shopify's dev tooling and experience.

P.S. You can learn more about why we stale issues here.

[PaulNewton]

This is so silly to add apps we have to cripple the baseline flexibility of a section. Which pretty much every theme has to have workaround for adding common aftermarket fixes like creating a separate mobile menu. Since for some silly architectural reason ambiguity is allowed to come into existence between different blocks scopes when an @app block is added instead of name-spacing or given a way to enforce strictness.

To get around this it's either A) make the setting that's need for section needed a global setting 🤢 B) make a custom block to stand in as a section-setting and do all the extra processing for that, along with the UX confusion that causes for staff. I.e. a block like this

"blocks": [
  {
    "type": "@app"
  },
  {
    "type": "menu-drawer",
    "name": "menu-drawer",
    "limit": 1,
    "settings": [
      {
        "type": "link_list",
        "id": "menu-drawer",
        "label": "menu-drawer",
        "info": "When enabled this menu replaces the sections menu inside the navigation drawer."
      }
    ]
  }
]

then to check for this either looping over the blocks or use the "| where: " filter for that block type

{%- for block in section.blocks -%}
    {%- case block.type -%}
      {%- when 'drawer-menu' -%}
        {%- assign menu_mobile = block.settings.drawer-mobile -%}
        {%- break -%}
    {%- endcase -%}
{%- endfor -%}

or

{% assign drawer_menu_block = section.blocks | where: 'type', 'menu-drawer' %}

[github-actions[bot]]

This issue seems inactive. If it's still relevant, please add a comment saying so. Otherwise, take no action. → If there's no activity within a week, then a bot will automatically close this. Thanks for helping to improve Shopify's dev tooling and experience.

P.S. You can learn more about why we stale issues here.

[uPesyLabs]

Issue still here

[notrealdev]

They never do these things, maybe I'll close this issue if I get more than 10 votes

[github-actions[bot]]

This issue seems inactive. If it's still relevant, please add a comment saying so. Otherwise, take no action. → If there's no activity within a week, then a bot will automatically close this. Thanks for helping to improve Shopify's dev tooling and experience.

P.S. You can learn more about why we stale issues here.

[ttnbtfy]

Issue still here

[github-actions[bot]]

This issue seems inactive. If it's still relevant, please add a comment saying so. Otherwise, take no action. → If there's no activity within a week, then a bot will automatically close this. Thanks for helping to improve Shopify's dev tooling and experience.

P.S. You can learn more about why we stale issues here.

[uPesyLabs]

Issue still here

[Sumit-Rodge]

Confirming this is still an issue and any previous workaround with the cli does not work

It's an intended behavior of app block, it only allows to include one resource setting of each type as a section setting Learn more

Just replace the block type from "@app" to any other type.

`"blocks": [
    {
      
      "type": "text",
      "name":"header"
    }
  ]`

[robertosenabre]

The issue is preventing themes from using app blocks in the header or footer. Can someone from Shopify look into this?

[ceri-waterscreative]

It's intentional behaviour, see https://shopify.dev/docs/storefronts/themes/architecture/blocks/app-blocks#app-blocks-and-section-settings

[robertosenabre]

Thanks for that @ceri-waterscreative! From my point of view, it is still a bug. Our app block does not have autofill settings enabled and is not using any resource input settings, so why block all app types? It does not make sense. It is just another way Shopify wants every merchant to use extensibility but at the same time making absurd limits.

[PaulNewton]

Thank you ceri-waterscreative for adding link to the docs about the @​app block autofill limitation behavior 🚀

@​shopify , Intentional is not the same as defect free. Intended or not in systems it's always a bug, or a defect or DX anti-pattern, when there is global ambiguity with side effects instead of proper namespace'ing of what should be internal settings for THIRD PARTY system integrations

App blocks and section settings To prevent ambiguity with autofill settings, sections that support app blocks can include only one resource setting of each type as a section setting. For example, a section might include only one product setting and only one collection setting.

And the way autofill works:

A dynamic source pointing to the parent section's resource setting of the same type. A dynamic source pointing to the template's global resource.

So we get the 🤸 mental gynmastics of artificial limitations to block type usage in first party theme customizations because of what? that dynamic sources are not re-usable? that apps cannot be properly scoped to their @​app settings like a regular block while calling itself a block so it has to create a side effect of limitations in a sections global space because it pollutes the section scope? because it can't just use the first instance, treat the section settings as a pickable JIT dynamic soure, or fail gracefully when multiple types are available?? And it's not even about ID properties having uniqueness issues, it's because types .... TYPES aren't re-usable??? 😵 Wut, huh, say what?

It can be argued all day long it's not technically a bug because nothing breaks or it's "meant to be that" etc etc etc. Meanwhile it is a very real process issues that shouldn't exist that defies reasonable expectations, breaks project implementations , lowers flexibility of theme customizability through extensibility(due to scope side effects). And then of top of that it's also a weird illogical bug not adhering to either the simple ideas of namespaces, or scopes. Yeah that's a bug. QED 🤢

[EvilGenius13]

Hello 👋 , I am re-opening this issue. I used @notrealdev 's example in the description and was able to successfully upload when running theme dev.

It appears as though it was patched. That being said, I don't want to close this issue prematurely. Are there other examples where this wouldn't be working?

Thanks!

[robertosenabre]

Hi @EvilGenius13,

Thank you for reopening this issue. However, in the last comments we are not referring to that. The issue occurs when you add a block with the type @app to that schema structure. You will notice that it doesn't work as expected.

Look:

[EvilGenius13]

Thanks for responding so quickly @robertosenabre! Let me dig into this.