Hello,
We try to build a working headless solution with Umbraco and unfortunately we can't use Heartcore. The first and most dividing question is how should we build our components for our end users/backoffice administrators later.
Still haven't find any "best practice" what is the limit for basic CMS administrators. Our first approach is to limit the accessability of Settings tab to the minimum - which means users can only fill the content of premade templates (Document types). This way we could make the frontend part and make the best sitebuild components for all the templates.But - it has serious limitations. This way backoffice users can't modify the order of elements or add anything to templates/Document Types. This is a serious limitation when we talk about a CMS right?..
An other topic is to choose between Rest and GraphQL approach ( Vertica or Nikcio or self made )...
We are trying to use up-to-date tech stack which means many of the older Umbraco versions / pre-.Net Core is out.
TLDR: Umbraco self hosted + Headless -> how should we build the components in terms of backoffice limitations? if you have done anything similar please share the lessions what you learned.
So I just though I wanted to give you a few pointers regarding how you can setup Umbraco to provide great flexibility for you editors - Usually editors would only need access to "Content" and "Media" and eventually "Forms" (If installed - it's a paid add-on) sections and admins that are not developers would have access to the mentioned sections as well as "Users", "Members" (If relevant, in most cases it's not) and "Translation". The Settings section is in 99% of all cases only relevant for developers to have access to.
Setting up document types etc. is not the job of a content editor. However you as a developer can setup Document types for Pages and Blocks and ensuring a ton of flexibility if you're thinking in terms of "Blocks".
I usually add a few folders under the "Document types" folder in "Settings" called "Pages" and "Blocks".
In pages I create the document types I need to be able to create as pages so then I would usually create a "Home Page" right clicking the "Pages" folder and selecting the "Create" dialog - From there I would choose "Document type" since it will only create the document type and no template, which you won't need when doing a headless build. Then I would go to the "Permissions tab" and select "Allow as root" ensuring the Home Page can be create under the "Content" node in the "Content" section.
Once created I would save the document type and start creating the blocks that I need and then afterwards I would make it possible to insert those blocks on my "Home Page" (And any other page for that matter). So next I would create a let's say "Text" block and an "Image block".
To create the two blocks I would right click the "Blocks" folder and say "Create" and now I would choose "Element type" since it creates a document type that can be used within a "Block Grid Editor" or a "Block List" datatype and won't have a route like document types for pages would to keep it simple.
On the "Text Block" I would add a datatype of "Rich text Editor" and then save it and on the "Image Block" I would add a "Media picker" datatype. Once the blocks are created I would go to the "Datatype" folder and then add a folder Called "Block List Editors" and then right click that newly created folder and hit "Create" and then create a new datatype - From the list that appears I would select "Block list" or "Block List grid" - I will throw in some links to more information about both and how they differ later. For this little intro I would go with "Block List" and then I would select my "Text Block" and "Image Block". Once the datatype has been setup I would go back to my "Home Page" and then add a new property called "Blocks" and select the newly created "Blocks" editor that allows us to insert either a Text or Image block.
Now that this have been setup I would go to "Content", right click the "Content" node and create a "Home Page" and now I can start adding as many content blocks of either Text or Image I would like and using "drag'n'drop" I as an editor have full control of the placement of the blocks etc.
I hope this brief introduction shows that you can setup some pretty flexible options for you editors and that locking down what sections they can access don't limit their options and flexibility in any way. It's all a matter of how the document types are setup and what blocks are made available to them.
I hope all of this gives you an idea about how you can ensure the editors have a flexible CMS, which does not limit them in their everyday work.
With the release of Umbraco 12 making a headless site will become easier since a Headless API based on Open API will be available. According to the release schedule Umbraco 12 final should be released on June 29th. So if possible it might make sense to wait for this release over starting to implement your own approach - However I do appreciate that you maybe just need to get going now and can't wait. But the stuff that needs to be done to output the data you need I best leave for a backend developer to explain since that's not part of my skillset :-)
Thank you for the detailed answer - I really appreciate your help, this way we are able to build the foundation of a successful project finally!
Additionally one ~simple looking but difficult question came into our mind:
how to handle lists? We are able to build blog-like things with list view and such, but it has it's limitations. What we are looking for is how to return for example only the first few elements from a huge list of elements.
the "Blocks" description is a really big help, and we are trying in this direction but still no luck.
Headless without Heartcore - best approach
Hello, We try to build a working headless solution with Umbraco and unfortunately we can't use Heartcore. The first and most dividing question is how should we build our components for our end users/backoffice administrators later. Still haven't find any "best practice" what is the limit for basic CMS administrators. Our first approach is to limit the accessability of Settings tab to the minimum - which means users can only fill the content of premade templates (Document types). This way we could make the frontend part and make the best sitebuild components for all the templates.But - it has serious limitations. This way backoffice users can't modify the order of elements or add anything to templates/Document Types. This is a serious limitation when we talk about a CMS right?.. An other topic is to choose between Rest and GraphQL approach ( Vertica or Nikcio or self made )... We are trying to use up-to-date tech stack which means many of the older Umbraco versions / pre-.Net Core is out.
TLDR: Umbraco self hosted + Headless -> how should we build the components in terms of backoffice limitations? if you have done anything similar please share the lessions what you learned.
Hi Colosh and welcome to the forum
So I just though I wanted to give you a few pointers regarding how you can setup Umbraco to provide great flexibility for you editors - Usually editors would only need access to "Content" and "Media" and eventually "Forms" (If installed - it's a paid add-on) sections and admins that are not developers would have access to the mentioned sections as well as "Users", "Members" (If relevant, in most cases it's not) and "Translation". The Settings section is in 99% of all cases only relevant for developers to have access to.
Setting up document types etc. is not the job of a content editor. However you as a developer can setup Document types for Pages and Blocks and ensuring a ton of flexibility if you're thinking in terms of "Blocks".
I usually add a few folders under the "Document types" folder in "Settings" called "Pages" and "Blocks".
In pages I create the document types I need to be able to create as pages so then I would usually create a "Home Page" right clicking the "Pages" folder and selecting the "Create" dialog - From there I would choose "Document type" since it will only create the document type and no template, which you won't need when doing a headless build. Then I would go to the "Permissions tab" and select "Allow as root" ensuring the Home Page can be create under the "Content" node in the "Content" section.
Once created I would save the document type and start creating the blocks that I need and then afterwards I would make it possible to insert those blocks on my "Home Page" (And any other page for that matter). So next I would create a let's say "Text" block and an "Image block".
To create the two blocks I would right click the "Blocks" folder and say "Create" and now I would choose "Element type" since it creates a document type that can be used within a "Block Grid Editor" or a "Block List" datatype and won't have a route like document types for pages would to keep it simple.
On the "Text Block" I would add a datatype of "Rich text Editor" and then save it and on the "Image Block" I would add a "Media picker" datatype. Once the blocks are created I would go to the "Datatype" folder and then add a folder Called "Block List Editors" and then right click that newly created folder and hit "Create" and then create a new datatype - From the list that appears I would select "Block list" or "Block List grid" - I will throw in some links to more information about both and how they differ later. For this little intro I would go with "Block List" and then I would select my "Text Block" and "Image Block". Once the datatype has been setup I would go back to my "Home Page" and then add a new property called "Blocks" and select the newly created "Blocks" editor that allows us to insert either a Text or Image block.
Now that this have been setup I would go to "Content", right click the "Content" node and create a "Home Page" and now I can start adding as many content blocks of either Text or Image I would like and using "drag'n'drop" I as an editor have full control of the placement of the blocks etc.
I hope this brief introduction shows that you can setup some pretty flexible options for you editors and that locking down what sections they can access don't limit their options and flexibility in any way. It's all a matter of how the document types are setup and what blocks are made available to them.
You can learn a bit about how to create document types from the docs here https://docs.umbraco.com/umbraco-cms/fundamentals/data/defining-content and by having a look at this tutorial https://docs.umbraco.com/umbraco-cms/tutorials/creating-a-basic-website - However this is focusing on a more traditional build using Razor templates etc. so the templating part is not relevant in a headless context.
Also you can learn more about the "Block List Editor" here https://docs.umbraco.com/umbraco-cms/fundamentals/backoffice/property-editors/built-in-umbraco-property-editors/block-editor/block-list-editor and the "Block List Grid Editor" here https://umbraco.com/blog/deep-dive-block-grid-editor-part-1/
Community member Tim Payne has also written a nice Skrift article about how make the editor experience a bit more WYSIWYG when using the "Block List Editor" here https://skrift.io/issues/supercharging-your-block-list-editors/ - And Kenn Jacobsen has done a nice talk about the grid editor here as well https://www.youtube.com/watch?v=gI_J-RaN2fE
I hope all of this gives you an idea about how you can ensure the editors have a flexible CMS, which does not limit them in their everyday work.
With the release of Umbraco 12 making a headless site will become easier since a Headless API based on Open API will be available. According to the release schedule Umbraco 12 final should be released on June 29th. So if possible it might make sense to wait for this release over starting to implement your own approach - However I do appreciate that you maybe just need to get going now and can't wait. But the stuff that needs to be done to output the data you need I best leave for a backend developer to explain since that's not part of my skillset :-)
I hope this helps a wee bit though!
/Jan
Thank you for the detailed answer - I really appreciate your help, this way we are able to build the foundation of a successful project finally!
Additionally one ~simple looking but difficult question came into our mind: how to handle lists? We are able to build blog-like things with list view and such, but it has it's limitations. What we are looking for is how to return for example only the first few elements from a huge list of elements.
the "Blocks" description is a really big help, and we are trying in this direction but still no luck.
is working on a reply...