Reuse component blueprint multiple times

Kirby 3 Solved ✅
#1

Hello,

I just started exploring Kirby v3, and I have to say, I love it!
There is one problem though that I can’t figure out.

We structure our pages into components, where each component has its blueprint that consists of multiple fields. This works fine. The problem arises when I want to use this component blueprint multiple times.

So for the sake of this example I created button.yml blueprint in site/blueprints/components that looks as follows:

label: Button
type: group
fields:
  label:
    label: Label
    type: text
    width: 1/3
  content:
    label: Link
    type: url
    width: 1/3
  style:
    label: style
    type: select
    options:
      primary: Primary
      secondary: Secondary
      link: Link
    width: 1/3

I then want to use this button inside my home.yml blueprint in site/blueprints/pages in each tab once:

title: Home

tabs:
  tab1:
    label: First Tab
    fields:
      button1: components/button

  tab2:
    label: Second Tab
    fields:
      button2: components/button

This works for the first tab which renders three fields for label, link and style. But on second tab I get three error messages -

The field name "label" already exists in your blueprint.
The field name "content" already exists in your blueprint.
The field name "style" already exists in your blueprint.

Did somebody run into similar use-case, how did you manage to solve this?

Thanks for all the help!

1 Like
#2

It is because the names are identical and they need to be unique in order to be stored in the content file. I think your probably breaking things down to small.

You can use the extends feature to change the component in the second tab, but in this case you need to change all three field names, which makes the component redundant because you have just rewritten the whole thing. You may as well just put it directly in the main home blueprint, and do away with the button.yml file.

Personally I have broken my site down into distinct blocks and used a combination of the re-usable Tabs, Fields and the Builder plugin to create a set of reusable blocks for things like Hero banner images, different kinds of content, call to action blocks, sidebar info boxes etc… basically anything that is a distinct isolated block of content, I’ve turned it into a re-usable block via the builder plugin and you can have as many as you like on the page because the builder plugin takes care of the uniqueness.

For something like your button example, I personally would do that as a Kirbytext link with a class on it in a textarea, without using fields at all, but that depends on where the button needs to go.

#3

For repeated content with the same field names, I’d use a structure field called tabs. Then inside this structure field definition, you can reuse your button component.

2 Likes
#4

My issue with this is that field names cannot be reused (even when you’re not using components). This will not work (because headline is duplicated):

title: My blueprint

tabs:

  # content tab
  content:
    label: Content
    icon: text
    preset: page
    fields:
      headline: fields/headline

  # seo tab
  seo:
    label: SEO
    icon: search
    fields:
      headline: fields/headline

Is there another way? Or am i missing something in my code ?

I’m looking for a way to make this work (without adding prefixes):

<?= $page->content_headline() ?>
<?= $page->seo_headline() ?>
#5

What is the problem with adding suffixes or naming these fields differently? If field names are not unique, the duplicate fields are ignored, so no, not possible.

#6

Thank you for your time to respond.

The problem is that you need to add suffixes where you could skip them. Also, this would make blueprints truly reusable. Having them working without prefixes you could just copy/paste your “blueprint component” code and it would work.

But this is not a big deal after all.

#7

That’s probably the smaller problem compared to if Kirby would have to automatically prefix these keys , and you wouldn’t know in advance the resulting keys you would have to call in your templates. After all, these keys end up in the content file, and if they weren’t unique, what content would you get from a given key name?

#8

These are unique.

and you wouldn’t know in advance the resulting keys you would have to call in your templates

The key could be just a combination of “parent key” and “field key”.

Auto prefixes could be just an option to turn on in blueprint (or set a custom prefix in blueprint, basically with something like “prefix: my_prefix”).