Make elements in the library section more flexible, like content

[Luuk1983]

I absolutely love the idea of the new library section. It solves our problem of always having the 'shared content' or 'reusable content' in the content tree outside the website root. However, I feel like the library does not yet live up to the potential.

The managing of the library section's elements is (intentionally?) less complex than the content section:

• Folder are generic entities in the library section. You can't create your own folder 'types'.
• You can only allow an element to be created in the library section, but you can't scope it, like you can in the content section with node-specific permissions.
• You cannot create elements under other elements. There is no concept of 'create' on an element, only on the folder's.

To be honest, I find these limitations very unfortunate and I'll tell you why in a moment. Let me first say that there are probably good reasons for some of these choices that I don't see, so I love to be informed about what they are.

Anyway, there are two reasons why I don't like the limitations:

First is multi-site support. I can garantuee you that when you have multiple sites in your Umbraco instance, you're going to have a few root folders, one for each site in the library section. I can't create specific 'folder' document types here, so I can't distinguish them by alias, I can only use their name (which is not very reliable). I also can't make rules where I will allow element A on Site A, but not in Site B to be added.

Second is that you can't create elements below elements in the tree because an element does not have a 'create'. In our current 'shared' content, we sometimes categorize things that have content of their own, so you can't use a folder for that. For instance: we sometimes have a 'FAQ' category that has a general description of the category, followed by one or more FAQ items as the children. We have multiple places where you can pick either the category, or the individual FAQ items. That's why we have them in seperate nodes, so you can pick either.

So to be honest, I think I'm going to run into limitations of the library. I really feel like it could have more flexibility that is more in line with the content. Maybe that would even make sharing code for that functionality easier. Anyway, I'm curious what you all think!

[nielslyngsoe]

I might help kick-start the discussion by adding a few thoughts from our side.

1. Enabling Developers to lock down/enforce Elements into specific folders depending on their origin in the Document Tree.
   — This approach feels counterintuitive; it will potentially prevent authors from utilizing the Element Library to its full potential. Let me elaborate:
   An author might want to share one element between multiple sites, so multiple folders with various permissions would be necessary.
   Example folders: SiteA, SiteB, Shared

This could be extended, so a subfolder could be limited further (Replace 'Products'/'Articles' with what makes sense in your use cases. Read it as Elements for a subdivision of a site):

SiteA
-> Products
-> Articles
SiteB
-> Products
-> Articles
Shared
-> Products
-> Articles

But if the user was forced into SiteA, they would not be able to utilize any of the Shared Elements — leading to solution nr. 2:

2. Limiting some Folders to specific areas of the Document Tree
   This could make sure that some folders were dedicated to a specific Site, but not enforce a user in there. Enabling the user to navigate a folder like 'Shared''.

But that would also mean that a user with permission to create folders could create new other folders in the root, so having some folders with limits might not really work, cause an author who doesn't care about the structure might not bother navigating there.
Which leads to the next idea:

3. Limiting root create access?
   Maybe something is interesting in rules specific to root creation, both root creation of Folders and root creation of Elements — this could enforce Authors into folders? Without any of the above initiatives this might be enough nudging to enforce the Author to consider where to put an element.
   Since we already can limit Authors from creating Folders, then that might be something?

But anything we do must consider that we are not enforcing a system that does not meet authors' daily lives.

A structure like above would easily start looking like this:

SiteA
-> Products
-> Articles
-> Team Members
-> Shared
--> Summer Campaign '26
SiteB
-> Products
-> Articles
-> Team Members
-> Shared
--> Summer Campaign '26
Shared
-> Products
-> Articles
-> Team Members
-> Summer Campaign '26

Being strict on the Site relation might not be ideal for a business; the Library Section is for Reusable Content, which is about breaking the usual structure and connecting across.

4. We might open up for some intervention in code, extension points that declare the initial folder for an Element, helping authors get the structure right. But not enforcing it?

I hope that can help get the conversations started, so please share your perspectives so we can get a good insight into the various use cases.

[mistyn8]

I'm think I'm with Luuk here, where I have a feeling some of this has precedent, with existing solutions/patterns in other areas of the Umbraco-Cms.. for instance we already have the concept of users with multiple allowed content/media start nodes.. and pickers that are able to override this restriction to allow picking even if the media/content node isn't accessible to the user...

And there is also the counterintuitive argument.. in that this just looks like an unrouteable content section, so should preserve those other conventions of typed folders to allow typed children, with sorting for default enumeration control etc..
Without typed folders you can't apply custom icons (which we have in the media section) but probably moot as that icon would indicate child types, which we can't restrict?
And I'm sure we all have sites where the media library is just 1k's of root level images, because we didn't structure allowed hierarchies at the get go :-)

All, as requested, musings to get the conversation started. (I wonder if these weren't raised in any RID as it was assumed by many this was just unrouteable content by design (eg for the archetypal template less settings node and descendants), so carried the existing content patterns....)

[Luuk1983]

Well said! I think there is a fundamental difference in my expectation and how I think it was build. Because it uses Elements, it inheritly has limitations because elements don't have a concept of 'create' options for instance.

I think the idea of it being a collection of blocks where you can pick a 'block' and later use blocks in the block grid is fine by itself, but I miss all the organizational stuff like insert options, complex permissions. Looking at how we use 'shared content' these days, we have shared content per site and global content. We have a more complex tree with more advanced pickers that use get their list from specific 'folders' based on dynamic root. For that you really need to be able to create folder from different document types.

I forsee soo many scenario's that are simply not possible by the current approach and I really fear that 'yes but it's meant as just a big bag of blocks' is just not going to cut it

[mistyn8]

Ah so that changes the starting point, it's not the unrouteable content I'd hoped for, but as you say a library of elements which dare I say it is now synonymous with blocks (aligning with your bag of blocks, and the upcoming extension to the library for persistent style clipboard and promotion/demotion of grid blocks to the library).. It does make sense from that viewpoint as elements are intentionally not to be used unless in the context of a node/page container with it's full content type so shouldn't have any hierarchical context beyond grouping.
So we still end up intentionally subverting to get our nice site settings structures at least without worrying about routes. :-)

However, with the grid and block management we do already have a concept of structure, aka areas/allow at root and what elements can exist in which area.. and nesting of areas.. (though not sure it workably extends beyond a couple of levels).
And to mention a bug bear of mine areas is a poor cousin to what we had previously in the now legacy grid where the equivalent cell could have its own settings. ;-)
But this structure is the concern of the datatype.. perhaps we can bring structure to the library by having a composing library element that has a grid property, but then I think we lose the permissions granularity @Luuk1983 is after that would/come from elements sprinkled with a little content sugar?

I may be rambling now ;-)

[dawoe-TL]

I have to agree with @Luuk1983 here.

I know the implementation is not feature ready, but in it's current form it will not be usable for our projects.

Luuk already raised some points about permissions and structure.

But the element picker should be revised as well. Now it can only be restricted to a start folder.
But I would prefer that it would be able to restrict the elements picked, and optionally also to the option to set a dynamic root. Very similar to how the Content picker works now.

[nielslyngsoe]

Hi @dawoe-TL, yes, sounds great with Dynamic Root. But then the next question surfaces.

How would you imagine that would work?

[dawoe]

Hi @nielslyngsoe

The dynamic root only makes sense I think when you are able to create different folder types in the Elements section.

For me personally, having the ability to limit the element type in the picker would already be a great help.

Dave

[nielslyngsoe]

@dawoe surely, and that is part of 18.1(I'm not sure if it was already in 18.0). The so-called allowedContentTypes can be configured on the Element Picker Data Type.