View on GitHub


Test Coverage

    This is an example of how to configure a basic Unicorn configuration using your own config patch file.
    Copy this file to use as a basis for your own configuration definitions.

    Enabled configuration definition patches should be present on all environments Unicorn is present on.

    See Unicorn.config for commentary on how configurations operate, or
<configuration xmlns:patch="">
                    The default configuration is an example to start making other configurations from.

                    WHAT SHOULD I INCLUDE?
                    In general, include the fewest items possible. This both makes things faster and reduces the amount of things kept in source control.
                    The most common candidates for serialization are layout items and template items, but Unicorn can serialize any type of item or field including media.
                    Configurations can override the default dependency types defined in Unicorn.config's <defaults> to apply
                    custom behaviors to specific configurations. 
                    If no 'type' attribute is specified, the default dependency type is inherited (e.g. Unicorn.Predicates.SerializationPresetPredicate for a predicate).
                    Attributes set on a type-less dependency are added or replace those on the base type (e.g. setting transparent sync to on/off without specifying a type).
                    Child elements of a type-less dependency are appended to any defined on the base (e.g. you can add includes to a predicate using this).
                    Specifying a type attribute completely overwrites any definitions made in a parent configuration.
                    Configurations may also depend on each other. Add a comma-delimited list of configuration names to depend on to the 'dependencies' attribute on the configuration.
                    Dependent configurations do not force dependencies to sync if not selected, but syncs will always occur in dependency order if multiple dependent configurations sync at once.
                    Transitive dependency and multiple dependency (comma delimited) are supported.
                    Favor using several configurations over a single monolithic one.
                    Favor using more includes and fewer excludes in your predicates.
                    Start with minimal configurations and add includes as you need to serialize new things.
                    If you're using a convention-based system like Helix, you can create a base configuration that encodes your conventions using variables,
                        for example <include path="/sitecore/templates/$(layer)/$(module)" /> on the predicate. The base configuration will have 'abstract="true"' on the root element, and
                        inheritors will have 'extends="AbstractConfigName"' on their root element.
                <configuration name="Sitecore.Extensions">
          <targetDataStore physicalRootPath="F:\Projects\Ecuasoft\Sitecore.Extensions\src\Sitecore.Extensions\Serialized" />
                            The predicate controls what items are included in the configuration.
                            Each include can also exclude specific subitems in various ways. For a reference of the most current predicate grammar, consult the tests here:

                            NOTE: after changing what is included or excluded, you should reserialize all items, or at least the added items for additions.
                            NOTE: the "name" attribute controls the folder name the items will go into. If unspecified, the last path segment is used. Names must be unique across the configuration.
                            NOTE: You cannot use excludes with Transparent Sync. See
                            NOTE: If your configuration is named in Helix format (Layer.Module), you can use $(layer) and $(module) here as variables.
            <!-- Content folders -->
            <include name="Extensions.Application" database="core" path="/sitecore/content/Applications/Extensions" />

            <!-- Template folders -->
            <include name="Extensions.Templates" database="core" path="/sitecore/templates/Sitecore Client/Extensions" />
            <!-- Examples -->
            <!--<include name="Layouts" database="master" path="/sitecore/layout/Layouts/YourSite" />
                        <include name="Templates" database="master" path="/sitecore/templates/YourSite" />
                        <include database="master" path="/sitecore/system/Languages" />
                        <include database="master" path="/sitecore/system/Tasks">
                            <exclude path="Schedules" />
                        <include database="master" path="/sitecore/system/Workflows" />
                        <include database="master" path="/sitecore/system/Settings" />-->
                        SYNC TYPE
                        Traditional Sync (the default) updates the state of the database only when a sync operation is run. It supports additional operations but can be more of a chore to remember to sync.
                        Transparent Sync (preferred) updates the state of Sitecore instantly as soon as changes to files occur. It is optimal for development purposes, but has a few limitations.
                        See the guide to help decide:
                    <dataProviderConfiguration enableTransparentSync="false" />

                        SYNC CONFIGURATION
                        UpdateLinkDatabase: If true, the links will be updated for synced items after the sync has completed. If false (default) links are not updated for performance.
                            Updating links is important if you are syncing user-facing content where link tracking is important. It is not very important for system items (templates/renderings).
                        UpdateSearchIndex: If true, the search index(es) containing the item will be updated with item changes after the sync has completed. If false, indexing will not be updated for performance.
                            Updating the index is important for content that relies on indexing, which may include most user-facing content items. Most of the time templates and renderings don't need indexing.
                        NOTE: UpdateLinkDatabase and UpdateSearchIndex also apply to items that are reloaded from disk when using Transparent Sync, as well as normal Sync.
                        NOTE: Updating the links and search indexes will cause significant performance degradation during syncing.
                    <syncConfiguration updateLinkDatabase="false" updateSearchIndex="false" />