Add Support for Disabling Nested Content Items (i.e., a Toggle Button)

[Nicholas-Westby]

Given this blog post: https://umbraco.com/blog/a-new-take-on-the-umbraco-issue-tracker/

I am migrating this issue to this issue tracker: http://issues.umbraco.org/issue/U4-10422

Much discussion has happened around the issue and I think it's time for a reset to get everybody on the same page. Here is the actual request:

Add a toggle button to nested content items that allows the nested content items to be either enabled or disabled.

There are a bunch of ways of going about that. Here are my recommendations (gathered from the other ticket and from other places this issue was being discussed):

• Toggle Button Included the toggle button in the core of Umbraco.
• Opt-In Feature Allow that toggle button to be shown/hidden based on a setting configured for a given nested content data type instance. Make the default hidden so this is an opt-in feature.
• Surefire Storage Save the full nested content data to the database (i.e., IContent), but only save the enabled nested content data to the XML cache (i.e., IPublishedContent). This ensures that even if the property value converter is bypassed, the correct data will still be represented. This would also mirror how actual pages work (i.e., unpublished pages are not included in the XML cache).

I understand you may not have the resources to implement this feature yourselves at Umbraco HQ. There are a ton of people interested in making this happen, so it's probably safe to assume you can get another pull request that implements this.

[hartvig]

TL;DR: Love it, this would be awesome, but there's some challenges to solve both around UX and architecture that makes the task bigger than initially.

I'd love to see this in the core, but done "right".

As this introduce the concept of what could be described as "atomic publish/unpublish", I'd love to see a broader discussion on how to handle this in Umbraco.

Right now we have a few core property editors (Grid and Nested Content) and quite a lot as packages, that "mimics" content nodes, but aren't. They work by storing a big pile of un-normalised JSON into a blob storage and then various "magic" in both back office and runtime tries to make them behave as Content Nodes.

When everything works a-ok, that's awesome. But essentially it's all hacks which is less than ideal. Hacks have a history of biting when you least expect it and when this technique of mimic'ing content nodes goes wrong, it's really a wreck because the core essentially have no idea what's going on (we see this in support cases and it's not pretty).

Long term solution is making Doctypes much more flexible and introduce a concept of "subnodes". We're not they're yet (but we will be post v8).

Until then we need to find a balance between what is sustainable and healthy for the core, while not preventing people from solving actual and current use-cases.

There's two challenges here before I feel comfortable of including this in core:

1. A solution that doesn't involve black magic to emulate content nodes
2. A UX pattern that is tested and can be rolled out in general throughout the core (I don't like the idea of a UX pattern that only applies to one single thing in core although it can work great in a single package). This means we - as community - need to come up with - and user test - a way to make it clear what it means when a "subnode" is not published.

Exciting times ahead.

[mortenbock]

I think the concept of "subnodes" sounds a lot like EPiServer "blocks". Basically blocks of content that can live under a page (or in a global structure) and can be dragged into the pages properties to be displayed on the page.

So the block will still exist even if you remove it from the page, and you can reuse it in multiple places.

The prop editors also add a layer of "meta data" for blocks, so you can select a "display mode" for the block where it is inserted. This means that you could basically add the same block to the same property multiple times, with different display modes. Pretty neat.

So that might function as inspiration for how this could be achieved.

[nul800sebastiaan]

Hi everyone,

After another productive discussion about this at HQ we would like to emphasize that we're most worried about point number 2 in Niels' response: having a consistent UX pattern for the "subnodes" concept. We've created a separate issue with specifications for those interested at taking a crack at that #2923.

With a good UX pattern in place we could consider a little bit of black magic to emulate content nodes, that we can in a later version improve on.

For now we're going to close this issue in anticipation of advancing the "subnodes" concept. This is not a rejection of the feature requested but an encouragement to make sure that it makes sense for where the Umbraco project wants to go with this. And remember, "no is temporary, yes is forever".

Thanks everyone for the great constructive feedback!

[ronaldbarendse]

Adding a toggle button to Nested Content can be done right now with https://github.com/nathanwoulfe/NestingContently. This basically adds an on/off button (with additional UI styling) to the header icons, instead of having a checkbox on the nested content item.

Until issue #2925 is fixed and we can override the value converter (example code is already provided in that issue), you will need to filter the IPublishedContent in the view. If you've aliased the Nesting Contently property umbracoNaviHide, this can be done using the IsVisible() extension method.

[ronaldbarendse]

Using NestingContently and the work-around from #2925 (comment), it's already possible to disable nested content using a toggle button 🎉