Copied to clipboard

Flag this post as spam?

This post will be reported to the moderators as potential spam to be looked at

  • Steven Lemmens 4 posts 78 karma points
    May 10, 2019 @ 20:20
    Steven Lemmens

    Dynamically add "features" to a page


    I'm taking my first steps with Umbraco (v8), and right now I'm trying to create a "Features" section on my page (see image below for example what it will look like) enter image description here

    So I would like my client to be able to dynamically add 2 or more "Features".

    I can of course add fields ("Title 1", "Description 1", "Title 2", "Description 2", etc) to my document type, but I want to avoid this and make it as dynamic as possible.

    So I was wondering what the best way to do this in Umbraco?

    1) Create a different document type called Feature and add it under my page as a subnode? If so, how would I go about accessing them and printing them in my Razor? (mind you there may be more dynamic content than just "Features" on the same page, so if I would go this route, I would need some way to distinguish between a "Feature" and a different type of content block.

    2) Is there a package or a special kind of editor that will help me with this?

    Thank you very much for any help.

  • Marc Goodson 1154 posts 7698 karma points MVP 5x c-trib
    May 11, 2019 @ 17:37
    Marc Goodson

    Hi Steven

    Yes you could create a new 'document type without template' that describes the Feature, with 'title', 'icon' and 'description' fields and enable it to be created underneath your homepage.

    In your homepage razor template you'd be able to access them by

     IEnumerable<IPublishedContent> featureBlocks = Model.ChildrenOfType("featureBlock");

    where "featureBlock" is the alias of the document type you chose to call them.

    If the feature blocks 'always' link to another page on the site, the other approach is to add only a Content Picker property, to the home page document type called featured pages... and make sure the pages that can be picked have a, title, description and icon property to use when they are picked to appear on the homepage, you'd be able to read the picked items via

    IEnumerable<IPublishedContent> featuredPages = Model.Value<IEnumerable<IPublishedContent>>("featuedPages");

    Finally the other option worth considering based on your screenshot is to use a Nested Content property, this is a really similar concept to creating the feature blocks underneath the homepage, except the repeating items are editable on the homepage. See for a bit more info on Nested Content - certainly worth having in your armoury when designing solutions.

    Here you would again create a 'FeatureBlock' Document Type Without Template, to define the repeating elements, eg title, icon, description etc

    Then add to the Homepage a new property of 'Nested Content' type - perhaps call it Feature Blocks, and choose to use your 'FeatureBlock' document type to define the repeating elements.

    Now in your homepage template you should be able to access the items:

     IEnumerable<IPublishedElement> featureBlocks = Model.Value<IEnumerable<IPublishedElement>>("featureBlocks");

    With either of the approaches once you have your featureBlocks you can create a foreach loop to write out the blocks

    @if (featureBlocks.Any()){
    <div class="feature-blocks">
    @foreach (var block in featureBlocks.Take(3)){
    <div class="feature-block">
    <span class="icon icon-@block.Value("icon")></span>
  • Steven Lemmens 4 posts 78 karma points
    May 12, 2019 @ 10:40
    Steven Lemmens

    That is an amazing answer, thank you very much. I went with your suggestion for the "Nested Content", this was actually exactly what I was hoping for. Thank you very much!

  • Nathan Woulfe 386 posts 1469 karma points MVP 3x c-trib
    May 13, 2019 @ 09:44
    Nathan Woulfe

    Dropped in to recommend Nested Content.

    Worth considering though if you're likely to want to reuse the feature blocks on other pages, they won't be easily accessible as NC - in this case you'd be better off creating child nodes. Like a lot of decisions, depends on your use-case.

Please Sign in or register to post replies

Write your reply to: