We've been working on refactoring a sitecore solution to bring it in line with helix principles. One of the main initial offenders was the placement of a lot of serialisation in the project folder. There were dependencies to those project items on multiple features and foundation layer, so we've made a conscious decision of separating them and moving the essential site structure to the Foundation layer.

At present our objective is to define and serialize on the Foundation layer some fundamental pieces of the site structure such as the Data and Global Content folders as well as some of other important sub-folders.

Then within features and project layer we'd like to define the serialization of folders and items which are more specific and live under the ones defined on Foundation. Those would be items that are specific to a feature (to which serialization included within the dedicated feature) or items which relate to or bring together more than one feature, such as page designs (project layer items).

Example of site structure defined on Foundation:

<include name="$(layer).$(module).SiteStructure" database="master" path="/sitecore/content/Tenant/Website" >

 <exclude path="/sitecore/content/Tenant/Website/Home"/>

 <exclude childrenOfPath="/sitecore/content/Tenant/Website/Media"/>

 <exclude childrenOfPath="/sitecore/content/Tenant/Website/Data"/>

 <exclude childrenOfPath="/sitecore/content/Tenant/Website/Global Content"/>

 <exclude childrenOfPath="/sitecore/content/Tenant/Website/Presentation/Page Designs"/>


What we are struggling to understand is how to specify serialization for all children of a folder without specifying all child item paths individually. There is a large number of child items to be included and specifying their serialization individually would quickly become unmanageable. For excludes the childrenOfPath attribute is the way to achieve that. What we would need is an equivalent of childrenOfPath for includes. Or maybe there's any other method we're missing.

Take /sitecore/content/Tenant/Website/Presentation/Page Designs as an example. We need to include all its children in the project later, hence the exclusion of its children on the Foundation layer (above). So, we've tried:

A simple include - does not work since the folder is already included with the Foundation include rule for Website. Results in an error:

<include name="$(layer).$(module).PageDesigns" database="master" path="/sitecore/content/Tenant/Website/Presentation/Page Designs"></include>

An include that excludes the Page Design template. Trying to include all its children and at the same time exclude the parent folder (Page Designs) by excluding its template - It does not result in an error but no children are included under the Page Designs item either, so it doesn't achieve the purpose. I believe the same would happen if we excluded the parent using a pattern instead of a template id:

<include name="$(layer).$(module).PageDesigns" database="master" path="/sitecore/content/Tenant/Website/Presentation/Page Designs">
 <exclude templateId="{C0B5E1BD-3CDA-45BA-A731-C8915B7E0B93}"/>

This all seems like a simple and common problem. We've been trying to work out for a while how to best solve it and so far could not figure out the best approach. Any help is appreciated.

  • 2
    You would normally include root items in your Foundation configs, with something like <exclude children="true"> or one of the variants. github.com/SitecoreUnicorn/Unicorn/blob/… And then in project configs (separate <configuration>) define the above root item with all children being included by default.
    – Mark Cassidy
    Oct 15, 2020 at 14:47
  • 1
    Still not sure I understand your question fully since the title seems to suggest you have trouble including all children of a path - this is literally what Unicorn does out of the box
    – Mark Cassidy
    Oct 15, 2020 at 14:48
  • 1
    Try not to over engineer your approach. michaellwest.blogspot.com/2017/04/… Oct 17, 2020 at 20:57
  • @MichaelWest your blog post brought a lot of clarity. The video even more. The solution we're working with is quite similar to the one you describe. We clearly need to approach it in a simpler way, you're right. I believe we were too concerned about incorrect dependencies between layers and ended up including/excluding too much on Foundation. Oct 23, 2020 at 16:44

1 Answer 1



I am pretty sure that it's impossible to achieve what you want, taking into account all your requirements.

You must define a named root for your configuration. Each node in the Unicorn configuration represents a folder on a disk. If I get you right, your goal is to create these folders automatically. It is impossible. You cannot include orphans. You have to start with root item.


Your challenge description got me questioning whether your architecture split was successful.

Do you really think that Website should be placed in Foundation?

Website template with fields could be in Foundation but instance of a Website template (item) should be then a part of Project.

Take a look how I defined configuration and split code, content for my demo site. Maybe it will let you take a look on your problem from different perspective.

I think, that your whole Website should be a part of Project. Personally I don't see a reason for splitting it the way you described it.


If you really think that your architecture split is correct, you might want to try this workaround.

What we are struggling to understand is how to specify serialization for all children of a folder without specifying all child item paths individually.

Create a folder under Page Designs and nest items underneath.

Then all "dynamic children" should be added under this additional folder (ChildrenGrouping) and you don't have to include them one by one. At the same time Page Designs root is not a part of the same configuration

└───Page Designs
  • That inclusion of Website had got me thinking before, yes. I don't think the problem we have is that uncommon that it requires a workaround. It just requires better understanding of Unicorn and Helix plus a lot more simplification and pragmatism on the approach. Appreciate your answer. Very informative. It actually confirms what we had been wondering, that Unicorn doesn't do what we're looking for because what we're looking for isn't that smart. Thank you. Oct 23, 2020 at 16:48

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.