Content design patterns for XbyK

I'm looking at a PBI in our backlog that describes creating a CTA Widget Bar that is essentially a headline and 0-4 CTA buttons horizontally aligned.

Each button can be configured for label, URL, target, size, light|dark

The PBI indicates to create 4 copies of the fields, so CTALabel1, CTALabel2, etc. In my opinion, this flat structure is too denormalized, doesn't scale well, and just feels like an anti-pattern. I offered up an alternative which I believe follows more the way Kentico intends you to design content. This would basically be to create a LinkItem content type that gets stored in the content hub. Authors create their links here, and then they can be selected as "children" from widgets. In fact, if you make them generic enough, they can be a CTA, a Link, a Nav item, anything that uses a URL.

I got some pushback that this solution was overkill, overengineered, "it's just a simple button," or "we won't be reusing these very often." Further, to keep myself in check, I had my own concerns, mostly in terms of the potential disjointed editing experience requiring the author to go to the hub first, create the content, then hop back to PageBuilder to select the items. My next plan was to test that theory out, because if Kentico allows for the ability to create content items (and folders) in the hub on the fly from PageBuilder, then that squashes that concern. That essentially then puts the onus of good organization of content items in the hub on the authors which I don't consider a problem.

While my gut tells me my solution is probably the right call, I wanted to discuss with the community here so I could at least come back to the team with some extra input from the community on best practices.

Environment

  • Xperience by Kentico version: [30.11.2]

  • .NET version: [10]

  • Execution environment: Private cloud (Azure)]

Answers

Your gut is right here. The type of model you’re suggesting, and one I also use in my own projects, is much closer to how Kentico generally encourages structured and reusable content.

Create a reusable Link content type in the Content hub with fields like:

  • Title
  • DestinationType with values like Internal page, External URL, File
  • InternalPage
  • ExternalUrl
  • File
  • OpenInNewTab
  • Optional InternalPageAnchor

Use DestinationType as the visibility condition for the destination fields.

Then, in the CTA Widget Bar, expose a content item selector scoped to the Link type and set MaximumItems = 4. Keep presentation options like button size, light/dark theme, alignment, spacing, etc. on the widget itself, not on the reusable Link item.

That gives authors a reusable structured link item, while the CTA Bar remains responsible for presentation. It also avoids creating four repeated sets of fields. Because the link itself is generic, it can also be reused across the content model in other places that need a destination, such as navigation, link lists, cards, or related-content blocks.

Kentico’s docs support this pattern as well: Page Builder widgets can reference structured reusable content from the Content hub, and authors can create reusable items from the editing flow through selectors. So the experience does not necessarily require creating everything in the hub first and then coming back to the page.

Supporting docs pages:

https://docs.kentico.com/guides/architecture/content-modeling/model-website-presentation-components/model-page-builder-widgets.html

https://docs.kentico.com/guides/architecture/content-modeling/content-modeling-guide/design-website-content.html

To response this discussion, you have to login first.