This blogpost is part of short series on ‘XM Cloud – Sitecore Content Serialization (SCS) Best Practices‘
- XM Cloud – Sitecore Content Serialization (SCS) Best Practices – File System
- XM Cloud – Sitecore Content Serialization (SCS) Best Practices – Include naming
- XM Cloud – Sitecore Content Serialization (SCS) Best Practices – Module Explorer
In my previous blogpost I talked about ‘XM Cloud – Sitecore Content Serialization (SCS) Best Practices – File System‘. If you haven’t read that one, please do read it first. With all of that setup I want to quickly talk about ‘Include naming conventions on a module’.
Include Naming conventions
On the filesystem on important thing is naming conventions of your includes. Make sure to keep them brief and short, and I prefer to have them lowercased as well so it won’t be a mess, so you’ll end up for example with this:
This way you’ll likely NOT run into any issues with devops and the path length is too long exceptions. Sitecore has a great article on Relative serialization path hashing and aliasing in case you might run into this.
Of course these includes are the easier ones. I can imagine for example that in a Foundation.RichText or Foundation.BasicContent you want to serialize like a custom Html Editor Profile at for example /sitecore/system/Settings/Html Editor Profiles/Custom Rich Text Default than have it include like this:
- \src\items\Foundation\BasicContent\items\corecustomrteprofile or \src\items\Foundation\BasicContent\items\core-custom-rte-profile
Always keep it simple and readable and logical! I prefer to have items that are serialized in the core db to be prefixed with core(-) for include names, but you would also be able to introduce a new module, introduce for example per Foundation/Feature module a Core and a normal Master module configuration like this:
And that’s it!
Remember this is my personal preference and I might be very picky and opinionated on this, there’s not a 100% rule to have things names like this or that…. but the above should give you good guidance of what I would expect when I do a PR review.
In my next blogpost we’ll show you how a potential multiple module setup visually looks like. Hope this second part was helpful somehow!