RFC 0025 - Reusable Content with Global Blocks

[lassefredslund]

Request for Comments: Reusable Content with Global Blocks

Read the full RFC document here.

This RFC discusses adding Reusable Content in the form of Global Blocks to Umbraco. We would love your feedback on the described feature.

How do I contribute?

Most importantly, we don’t want to miss anything, so everything goes in terms of clarifications, questions, suggestions, etc.

Please do the following things if you want to contribute:

1. Read the RFC document here
2. Please read and respect the RFC Code of Conduct
3. Come back here and add comments down below 👇

[robertjf]

One thing that immediately comes to mind when looking at Global vs Local Blocks, is the scenario where an Umbraco Instance may have multiple sites, each with their own content and scoped to specific content editors. Some Blocks may be okay to be shared amongst the sites, while others should definitely be scoped to the site. We have one client who for example has 8 sites in their instance, each with their own theme and content. They don't want content bleeding from one site to the next.

[lassefredslund]

Thanks @robertjf for the comment

Besides looking at Global vs Local Blocks, I would hope that your scenario would also be covered by the suggested permissions where "we want to offer opportunities for limiting the Block Library Tree to a specific start node" - the same way as we have it on content and media. Do you think that would be sufficient?

[Myster]

If an editor has permission to edit all sites, this won't 'force' them to use the correct blocks in the correct sites. should it? or at least help them to use the correct block on the correct site?

We do something similar now by having re-usable content within the content tree, in this case it can be inside the correct tree.

[ravimotha]

I love the idea and the concept

I think library is a good section title , and may also be a great place to put any dictionary items long terms

I suggest we have a naming convention and grouping as described below ( which is mostly what is described)

2 types
Global
reusable content blocks to be used anywhere

Local
Reusable content defined by region

Global
-> Header Block ( unique name suggestion global.HeaderBlock)

Local

• UK
  |
  ----> Header Block (local.uk.HeaderBlock)

• DE
  |
  ---->Header Block (local.de.HeaderBlock)

[miguelcrpinto]

This is a great idea and I really like the proposed designs!

Below a few questions and remarks.

Naming
I'd name these "reusable content" or "reusable blocks" instead of "global blocks". I believe these are more meaningful names and people might use this to store shared and reusable information (like product data)

Technical considerations
In the RFC it mentions that the global blocks won't have a URL. Will they have any other unique identifier other than their id/content key? Like a slug? Something unique that can be used to retrieve them? I'm thinking about mobile apps scenarios that need to retrieve content via the API and where the page concept doesn't make much sense.

Talking about APIs, will the global blocks be accessible via the new Content API?

Is the RFC it's mentioned that these global blocks would be stored in a "new structure". Is this the first step to an overhaul of the content structure? :)

Organization within Umbraco
Global blocks are, in the end, just content pieces and therefore I think it doesn't make sense to place them in a separate section (For the tags and Content Templates, I think the Library section makes sense).

Have you considered changing the Content section tree to have a "content" and "global blocks" subtrees instead of having a Library section? Or simply having them just in the content section and they'd be special types (pretty much like the element types for example)?

[lassefredslund]

Hi @miguelcrpinto

In general we are trying to work more with Guids than Integer ID's, so our plan is to have a Guid on Global Blocks.

For the Content Delivery API we plan to return the Global Blocks the same way as we do it for Local Blocks today, - as part of the content for a specific page. However, for functionality like retrieving all Global Blocks or traversing the Global Blocks tree, we believe this should be part of the Management API. Do you think that would be sufficient?

Regarding Global Blocks in the Content section: Yes, we have discussed this. While it will probably be easier for the advanced user to have everything in the content section, we fear that it will make things too complicated for the less experienced content editor. Also, we foresee more "advanced features" in the future which we would like to "hide" for a new or less experienced editor.

[Myster]

#naming-is-hard: If you use the word library in the menu, why not stick with that metaphor and call them 'Library Blocks'

[bjarnef]

@Myster the new section can possible be used for other stuff than reuable blocks, e.g. we can consider moving Content Templates to this section instead, third party packages can inject trees in the section as well and maybe Umbraco addons like Umbraco Commerce and Umbraco Forms will use it in future as well. Who knows?

[Myster]

To clarify I was thinking of keeping the section name "Library" I like that, but anything referenced borrowed from the library would be called a "LibraryXYZ" for consistency, be it a LibraryBlock or a LibraryElement or a LibraryForm or a LibraryBook ;-) At least as far as the UI is concerned, and probably as far into the code as makes sense.

[ravimotha]

@miguelcrpinto

I think I agree with the naming

Naming
I'd name these "reusable content" or "reusable blocks" instead of "global blocks". I believe these are more meaningful names and people might use this to store shared and reusable information (like product data)

this then works really well with a library concept
here is your list of Global reusable content and Local Reusable content

Organisation within umbraco
While they may be "just content" i think having them separated is a good idea so in a library.

technical considerations

Should a block type be allowed by Document type
eg

[lassefredslund]

Regarding "allowed blocks", our thought was to let the configuration of the Block List or Block Grid handle this, - just like they do it for Local blocks today

[mattbrailsford]

I haven't got a fully formed answer right now, but my main thing would be to consider this outside of the context of "blocks". For a while there has been the discussion of having non routable "collections" for lists of things, be that lists of team members, or offices, or recipes etc. I think the library section is a good idea for this, but I would just ensure we are thinking beyond "blocks" and the grid and make sure the concept it useful for more generalized use cases.

In these cases it's not just about picking an item from a list, it could be accessing and iterating over the list in it's entirety so what is the API for this? etc etc.

[ravimotha]

I presume this is more directed at the comment made by Miguel..

but does that speak to the idea of have data you could reuse for a drop down data type

so we could have a generic set of properties defined but that a drop down datatype could use as a data source?

[miguelcrpinto]

I agree with the "thinking beyond blocks". That's why I gave the example of product details/specs :)

[royberris]

As an addition to the global blocks I would to add the following:

I would like to add thought into the idea that we can create preset blocks for a content node instead of the whole content tree. A lot of times when we have multiple websites in one instance they are split by using different roots (see A and B in the example). For root A I might have a set of blocks and for root B I might have a set of blocks. Also because users might be locked out on the root level. One group might have access to manage root A, and not root B. But they can see the global content.

I think it would be a good idea to be able to manage these "global" blocks for a certain tree. So we can preset blocks on tree A and only descendants or A can use these. It shouldn't be limited to root nodes, for example A2 should be able to have their own preset blocks which only A2x and A2y can use.

We can achieve this by having a "Library" content app instead of only using a library section. These should follow the library section, but are limited to the content node itself and it's descendants.

I can already see the global library be trashed with folders for local content. Using a content app should clean up the general library section because a lot of local content is not in the global library. It hides visibility when a user does not have access to these nodes.

A
- 1
- 2
-- x
-- y
- 3

B
- 1
- 2

---

For the library section: I am not a big supporter on it. This is my first thought. Thinking about it makes me realize there is not a lot of truly global content. For me, probably on how I set-up the content tree, there is only "global" content for each content root. Where a content root is the top-level of this content tree, it might also need to be considered as the root for a library functionality like described above.

Everything related to the library in this proposal equals content. So it should probably be in the content section.
I am not against the concept of the library, I am just questioning the need for a new section.

This is just my opinion and I can see other people configuring the CMS differently where a library section might make sense.

[DanDiplo]

I think this is a great idea and something that would be really useful as it meets a need that most sites have. I really hope this comes to fruition.

One thing that hasn't been discussed is this:

"To facilitate a good experience all Block content, whether it is local or global, will be handled as standard content. This means storing it in the same way in the database, providing similar actions for managing publish state, variants, and so forth."

This seems like quite a large change. At the moment, blocks are stored as JSON and whilst this has a lot of disadvantages, it does help with performance as you can load all the blocks with one SQL call.

If blocks are stored like Umbraco content - with a DB row for each property - then how will this perform when you have to load all the blocks? If you had 10 blocks with an average of 5 properties - and maybe some of those properties could have blocks nested in them as sub blocks - then you could literally be 100s of DB calls to load up the blocks. I know from experience how slow Umbraco can get when loading a lot of content not from cache. So I'd be interested to know how this will be achieved and still keep things like the editor experience snappy?

[leekelleher]

The RFC looks good to me. To feedback specifically on the unresolved issues...

Related to the technical considerations, if we are right, that it makes most sense to have Block Settings stored within the Content Node or if there are more/better use cases for storing Block Settings globally too.

Personally, I haven't used the Block Settings feature much, but I can envisage an example scenario where Block Setting reusability could be influenced by seasonal visibility or theming, e.g. at certain times of the year a content author would want to bulk alter block settings to hide or change theme, i.e. Halloween, Christmas, etc.

Of course, this scenario could be handled multiple ways within Umbraco. I'm only wondering if there is a technical reason to NOT have the Block Settings be globally available in the Library?

In case you work with segments, if you can see any implications in this proposal.

(No opinion, I don't typically work with segments.)

More perspectives on the proposed new section called “Library”. If it should be there at all and if so what it should include.

My initial gut instinct would be to name it "Repository", but now even that doesn't feel quite right. I think "Library" is a good choice of name.

In terms of other inclusions, selfishly for my Contentment package, I could envisage it potentially housing reusable Data List data-source configurations. I also like the "collections" idea that @mattbrailsford mentioned.

The naming. Should we call it Global Blocks, reusable content or something else.

I guess this depends on how the term "Block" will be used in future, as the schema is called an Element Type, which would imply "Global Elements", but even that feels a slightly odd name in the Block editor context.

I do like the idea of future property-editors being able to reuse non-routable content, which may not use the "Blocks" terminology, so maybe Elements might be a more generic term?

[lassefredslund]

Thanks, @leekelleher

Regarding local or global settings: If these are stored globally, it would also mean that you would have to make a block for each combination of content and settings whereas if you would store the settings locally, you would then have a chance to use the same Global Block content with different settings. We could fear that storing them globally would end up in too many blocks.

Concerning naming, our first name was "Repository" too :-)
But this might be considered a bit too technical and maybe also a bit too generic, which was why we came up with "Library". Happy, if you can see parts of Contentment located in this section too.

[nathanwoulfe]

My gut often says repository, but for our dear users, the nomenclature doesn't have much meaning. I like library, it is what it is. For more nomenclature, I think there's value in distinction between block and element items, even though blocks are elements, just the context varies.

Keeping the library as flexible as possible will be important, so that it can meet the different use cases already outlined in these comments. Serving it as a separate section makes sense in that the library could have a complex tree (or multiple trees) which would introduce extra complexity if added to the content section. Media is fundamentally content, but we keep it separate, so following the same separation continues to make sense here. A separate section also allows handling scenarios where elements/blocks differ from 'regular' content.

[ravimotha]

I like repository,
but is this feature for developers or editors .. if its for editors . (I am with Nathan) Library is surely the more welcoming phrase

this i think need to be the deciding factor , who is this section for
Ideally we need to get some actual users or people who do the day to day interaction to contribute to this.. if we can or could get Clive from Crumpled Dog, or may maybe Sophie from the Gibe team as they will have experience of clients and their interactions which could and would be enormously useful

[c9mb]

I suspect that if the total collection is a library, then the specific sections are generically archives or perhaps registers.

[bjarnef]

Currently Content Templates are supported/used in Umbraco core at document type/content type lever, but not for element types although I think @leekelleher used these in the Contentment package.

I think with resuable/blocks it may make sense to use Content Templates at element type level as well.

In a few projects we also had the need to move Content Templates tree to Content section (or remove the core tree and register our own inheriting the core Content Templates tree controller), since content editor could create these, but not edit and delete. So I think it makes sense to move this to a Library section as well by default, yet make in configuable. In the content template has a reference to media and the media is being deleted, it currently link to Settings section, which is hardcoded at the moment. See umbraco/Umbraco-CMS#12764

[tormnator]

Here are some thoughts based on my experience with building pages with the Block Grid over the last two months:

Summary: Shared content can be used in multiple places, not only in the Block Grid and Block List. Sometimes the content is displayed in the resulting UI, and sometimes it's used for configuration purposes. Sometimes the content is global, sometimes it's local to a sub-site, and sometimes it's local to a sub-tree under a sub-site. Hence, consider allowing both content and settings, or simply make no distinction between them. And maybe what we're talking about is just "Shared Content".

Terminology

• "Library" - is good, "Shared Content" might more accurate, but is maybe too long to use in the backoffice's sections menu
• "Global" vs "Local" - I'm not sure about "Global", see the summary above
• "Global Blocks" - we need to be careful of how we use the word "Block", it's a generic word and if we use it everywhere it might become dilluted and lose meaning. Maybe only use it when it's related to the Block List and Block Grid property editors. If I create some content, and it's generic enough to be allowed in multiple places (Block Grid, composition nodes, future property editors, third party property editors, etc.), then maybe stick with "Content" or "Element" instead of "Block".
• "Block" vs "Block Type" vs "Element Type" - I'm not sure if I have seen this distinction mentioned by Umbraco, but after having used the Block Grid for a while, it made sense to me that:
  1. when I create an "Element Type" (which can be used in more places than block grids/lists), I should not use the word "Block" in the name
  2. when I add an element type to a block grid definition and configure it (label, content model, settings model, areas, etc.), then it becomes a "Block Type"
  3. and finally, when I add an instance of a block type to a grid editor, I choose the configured "Block Type", I edit content and settings, and the result is a "Block"

When starting to use the Block Grid I was surprised that 1) we couldn't create reusable "Block Types", and 2) a specific "Element Type" could only be used once in the same grid definition. So, a couple feature requests would be:

1. Move the "Block Type" definition out of the block grid and into its own "entity" type, allowing fully configured block types to be shared among Block Grid property editor definitions
2. Allow the same element type to be used more than once in the same grid (configured into different block types)

Block Contents vs Block Settings - we have had reusable/shared content and settings on our sites, for multiple purposes, since long before blocks. In our content tree we have a node under each site's root called "Shared Content". This node doesn't have a template, and cannot be navigated to from the web. For us there hasn't been a significant distinction between "content" and "setting", but if they need to be distinct, then I would promote allowing both global content and global settings. Here are some of the types of shared content (and settings):

• Shared Product Content - when we have multiple product pages of the same product category we place shared content in its own node to avoid having to repeat data entry. Each product page then links to the same "Shared Product Page Content" node. One could argue this content could be placed on a parent product category page, but that is oftentimes too restrictive (one-dimensional hierarchy).

• Shared Image Styles - these nodes should be considered shared settings and contain common configuration of how images are displayed. An image style node's properties roughly correspond to CSS settings for images, e.g. stretch ("best fit", "auto", "fixed width auto height", etc), best fit settings ("contain", "cover", etc.), max height, vertical alignment, and more. When you're displaying multiple images on a page (or pages) and you want the images to be displayed the same way, then you can allow the image entity (e.g. a nested content item in earlier Umbraco versions or a block type today) to link to the same "Image Style" node.

• Page Layout Options - various settings for how a page is displayed (e.g. site header/nav bar/footer visibility). Page nodes can link to one of the shared page layout nodes, or otherwise use a node called "Default Layout Options".

• We also have "Full Screen Image View" settings, shared "Login Form" and "Create User Profile Form" (they are embedded on more than one page), and we have full set of shared banners, sidebars, widgets, and widget carousels.

[Myster]

Regarding Publishing, Unpublishing and Scheduled Publishing.
I think this is a nice feature, but may need some special consideration.
If a LibraryBlock (aka Global Block) is used on a given page, but it's scheduled eg: for the Christmas period, if the editor is looking at the given page when one library block is not published is there a clear/obvious way to show this?

If a specific layout relied on blocks of certain dimensions and one becomes unpublished, then the layout could end up with un-expected holes, and also would not be as represented in the back office. (is this a concern?)

[ajsmith27]

I think this feature is a fantastic idea. I was literally trying to research whether such functionality existed yesterday, as I've potentially got a new project upcoming on Umbraco and wanted to see if this concept exists, as it does on other CMS platforms I've been working with. Through my research, I did find an Umbraco theme called Igloo, which includes a Global Content concept: https://igloo-theme-1.gitbook.io/igloo-theme/page-types/global-content. I concluded, therefore, that it's something I'd have to build myself (if not buying such a theme that already includes it), so seeing it being discussed for inclusion in the core CMS is very encouraging.

I did initially feel that the Content section would be a better place for it, but agree with the point made by @nathanwoulfe, that Media is also in its own section so why wouldn't this be?

I've been out of the Umbraco game for a while, last site I built was on v8(!), so there's probably not much useful contribution I can make in terms of implementation to the current CMS, but just wanted to give a massive thumbs up for the idea, it would be very useful indeed!

[glombek]

I forgot to add notes to this RFC after CODECABIN 23.

Here are the notes I made and blogged about:

Reusable nodes could include anything that does not logically fit into the tree structure, such as office locations or team members. This repository pattern is seen in other CMS'.

You could even have blog posts as repository items to more easily replicate a WordPress-style URL structure like /blog/2022/09/14/codecabin-23, since WordPress also has a repository structure for blog posts. Where some Umbraco blog solutions require blog posts to be manually sorted into a date-based folder structure.

We discussed that having multiple library tabs (/applications) in the navigation bar may be desirable (e.g. Blocks, Blog) similar to how Konstruct works.

It was also suggested that media should be a library type as well, since it's essentially the same thing.

[arknu]

I like the idea of a Library section for these reusable block, and as stated, perhaps also for other kinds of reusable content like employees in the future.

However, I'd like to see some kind ability to selectively override a few properties on a global block. You should be able to indicate that a property on a global block can be overridden on a local instance and then choose to override it on a local instance, while keeping all other properties global. This does of course increase the complexity somewhat, but it would be very useful to have this option.