Kentico Xperience: MVC Widget Experiments Part 3 - Unused Widgets Section
Tags: kentico, aspnet, mvc, cms
Published: 2021-04-20 13:53:01

---
title: Kentico Xperience: MVC Widget Experiments Part 3 - Unused Widgets Section
published: true
description: Learn how to create a simple container for Widgets we don't want to delete, but also don't want displayed in the Page
cover_image: https://dev-to-uploads.s3.amazonaws.com/uploads/articles/fngxzyqjruxfrj3witny.jpg
tags: kentico, aspnet, mvc, cms
series: Kentico Xperience - MVC Widget Experiments
---

## Widget Experiments

_This series dives into Kentico Xperience MVC Widgets and the related technologies that are part of Kentico Xperience's Page Builder technology - Widget Sections, Widgets, Form Components, Inline Editors, Dialogs, and Page Templates 🧐._

_Join me 👋, as we explore the nooks and crannies of Kentico Xperience MVC Page Builder and discover what might be possible with this powerful technology..._

> _If you aren't yet familiar with Xperience MVC Widgets, check out the Youtube video on [Building a Page with MVC Widgets in Xperience](https://www.youtube.com/watch?v=ljQO9on5lLM)._

> The previous version of this blog series is [Kentico EMS - MVC Widget Experiments](https://dev.to/seangwright/series/5038)

## Goals

This post is going to show how we can create a simple Widget Section where we can add Widgets that we don't want displayed on the Page, but don't want to delete because we might want to use them in the future 🧐.

## Use Case - Swapping Between Variations of a Widget

When building out Pages using the [Kentico Xperience Page Builder](https://docs.xperience.io/managing-website-content/adding-page-content-using-widgets), we have many ways to customize the design and layout of a Page.

We can use [MVC Page Templates](https://dev.to/seangwright/kentico-12-design-patterns-part-25-mvc-page-templates-13n2), which let us swap out one layout and set of Page properties for another.

We could also save a set of Page Builder components as [Custom Page Templates](https://docs.xperience.io/managing-website-content/using-page-templates#Usingpagetemplates-Savingpagesascustompagetemplates), to make building out new Pages with the same set of components much easier 🤗.

Of course, we also have [Widgets](https://docs.xperience.io/managing-website-content/adding-page-content-using-widgets#Addingpagecontentusingwidgets-Workingwithwidgets) and [Widget Sections](https://docs.xperience.io/managing-website-content/adding-page-content-using-widgets#Addingpagecontentusingwidgets-Workingwithsections).

What happens when we want to continue to customize the layout and design of a Page, but save some Widgets we've already set up for later use?

A concrete example might be that we have a Carousel Widget configured how we like, but we want to remove it from the Page for a week, while we continue adding customizations to a Featured Product Widget. When we bring back the Carousel Widget a week from now, we don't want to lose our changes to the Featured Product Widget and any other changes we've made to the Page's Page Builder components in the meantime.

## Problem - Custom Page Templates Save the Whole Page

One solution could be to create a Custom Page Template and swap our Page's template in the future when we want to change back to that old Widget configuration 😊.

The Custom Page Template would store the full set of Page Builder components and their configuration as they currently exist on the Page. We could then make changes to the Page during the week and then load the original Custom Page Template at the end of the week to restore our original Page Builder configuration.

Unfortunately, all the changes to settings of various Widgets and Sections on the Page since we created the Custom Page Template will be lost 😭 when we restore that Custom Page Template.

Custom Page Templates are a snapshot of the entire Page's Page Builder configuration and don't let us save or restore specific parts 😕.

We could delete and re-create the Widgets, hoping that we got the settings correct whenever need them again, but some Widgets have lots of configuration options (especially if their forms are built with [modal dialog form components](https://docs.xperience.io/developing-websites/page-builder-development/developing-modal-dialogs-for-builder-component-properties) to enable large and complex configuration), like in the screenshot below.

![Complex Modal Dialog form for Widget Properties](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/3vcz061121uosn17t0z7.jpg)

Writing down all the Widget configuration (or taking a screenshot) feels wrong - there has to be a better way to remove a Widget from the Page, but save the settings for later use 🤷🏻‍♂️.

## Solution - Unused Widget Section

The solution to our problem is actually pretty simple, and uses features of Xperience we already have at our disposal.

What we need is:

- Something that 'holds' Widgets
- Display 'unused' Widgets in the Page Builder's Edit mode
- Hide 'unused' Widgets on the Live site

The first requirement is the very definition of Widget Sections, so let's start there 👍🏽!

The second requirement is how Widgets already work - they display their content when content managers are working in the Page Builder UI 👏🏾.

The third requirement requires a little bit of conditional logic, but fortunately we can leverage the [Page Builder Mode Tag Helper](https://github.com/wiredviews/xperience-page-builder-mode-tag-helper) package, which should do all that work for us 😅.

### Create an Unused Widget Section

First, we'll create our `UnusedWidgetSection`, which is likely the simplest section we'll ever make 🥳:

```csharp
[assembly: RegisterSection(
    UnusedWidgetsSection.IDENTIFIER,
    "Unused Widgets",
    null,
    "~/Components/Sections/_UnusedWidgets.cshtml",
    Description = "A section container for unused Widgets that won't be rendered",
    IconClass = "icon-square")]

namespace Sandbox.Components.Sections
{
    public class UnusedWidgetsSection : ViewComponent
    {
        public const string IDENTIFIER = 
            "sandbox.section.unused-widgets";

        public IViewComponentResult Invoke() => View();
    }
}
```

That's all there is to the class - this Section doesn't _need_ any Section Properties or dependencies. It's just a container for Widgets that we want to hide when the Page is being displayed live to visitors.

Let's look at the View, which is slightly more interesting:

```html
<page-builder-mode include="Edit">
    <div style="border: 5px solid #999; padding: 1rem;">
        <div class="row">
            <div class="col">
                <h3>Unused Widgets</h3>
            </div>
        </div>
        <div class="row">
            <div class="col-md-12">
                <widget-zone />
            </div>
        </div>
    </div>
</page-builder-mode>
```

Here we can see that we're using the `PageBuilderModeTagHelper` to conditionally render the `<widget-zone />`.

The `<widget-zone />` needs to be rendered in "Edit" mode, otherwise the Section won't be valid (all Sections require at least one `<widget-zone />`).

However, there's no requirement for the `<widget-zone />` to be in the Page when it's displayed outside of the Page Builder 🤓.

We include some simple styling to ensure our Widgets and Widget Section show up in the Page correctly in "Edit" mode, and add a friendly title so content managers know that the Widgets in this section are unused.

> We could add more styling to this Section to make it very clear these are unused Widgets. Maybe add a overlay with some opacity, or a noticeable border color around everything... but these are implementation details that don't affect the functionality, so use what makes the most sense for your project 😎!

Here's what we end up with in the Page Builder:

![Unused Widget Section in the Page Builder](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/e37org9hb2z1tdrf0rfn.gif)

And here's what the live site looks like (notice, none of our unused Widgets are visible 💪):

![Live site with no visible unused Widgets](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/vliihmjppdui4ff7cv2b.jpg)

## Conclusion

While I haven't found the need for this kind of Page Builder functionality an every day occurrence, I do think that some content managers would find it very convenient.

It's one of those tools that improves the quality-of-life every so slightly for our site's users, and with enough features like this, we can build sites that people 💖 **love** 💖 to use.

...

As always, thanks for reading 🙏!

---

<figcaption>Photo by <a href="https://unsplash.com/@jkoblitz">Julia Koblitz</a> on Unsplash</figcaption>

---

We've put together a list over on [Kentico's GitHub account](https://github.com/Kentico/Home/blob/master/RESOURCES.md) of developer resources. Go check it out!

If you are looking for additional Kentico content, checkout the Kentico or Xperience tags here on DEV.

{% tag kentico %}

{% tag xperience %}

Or my [Kentico Xperience blog series](https://dev.to/seangwright/series), like:

- [Bits of Xperience](https://dev.to/seangwright/series/8740)
- [Kentico Xperience Xplorations](https://dev.to/seangwright/series/8185)
- [Kentico Xperience Design Patterns](https://dev.to/seangwright/series/10963)