Skip to content

Commit

Permalink
Merge pull request #2 from KayeeNL/feature/Unicorn_update
Browse files Browse the repository at this point in the history
Feature/unicorn update
  • Loading branch information
KayeeNL authored Aug 26, 2020
2 parents 8642100 + c65037f commit e8f027a
Show file tree
Hide file tree
Showing 38 changed files with 1,316 additions and 1,822 deletions.
25 changes: 10 additions & 15 deletions Sitecore.DataExchange.Gutters.sln
Original file line number Diff line number Diff line change
@@ -1,30 +1,25 @@

Microsoft Visual Studio Solution File, Format Version 12.00
# Visual Studio 14
VisualStudioVersion = 14.0.25420.1
# Visual Studio Version 16
VisualStudioVersion = 16.0.30225.117
MinimumVisualStudioVersion = 10.0.40219.1
Project("{FAE04EC0-301F-11D3-BF4B-00C04F79EFBC}") = "Sitecore.DataExchange.Gutters", "Sitecore.DataExchange.Gutters\Sitecore.DataExchange.Gutters.csproj", "{8C10FCEE-9517-4078-AD2E-C4A23B538920}"
EndProject
Project("{CAA73BB0-EF22-4D79-A57E-DF67B3BA9C80}") = "TDS.core", "TDS.core\TDS.core.scproj", "{96972380-1971-4C62-BE77-2C9C69870E22}"
Project("{FAE04EC0-301F-11D3-BF4B-00C04F79EFBC}") = "Sitecore.DataExchange.Gutters", "Sitecore.DataExchange.Gutters\Sitecore.DataExchange.Gutters.csproj", "{0C5FC0D6-47FA-4274-9E65-AB388F8D9E96}"
EndProject
Global
GlobalSection(SolutionConfigurationPlatforms) = preSolution
Debug|Any CPU = Debug|Any CPU
Release|Any CPU = Release|Any CPU
EndGlobalSection
GlobalSection(ProjectConfigurationPlatforms) = postSolution
{8C10FCEE-9517-4078-AD2E-C4A23B538920}.Debug|Any CPU.ActiveCfg = Debug|Any CPU
{8C10FCEE-9517-4078-AD2E-C4A23B538920}.Debug|Any CPU.Build.0 = Debug|Any CPU
{8C10FCEE-9517-4078-AD2E-C4A23B538920}.Release|Any CPU.ActiveCfg = Release|Any CPU
{8C10FCEE-9517-4078-AD2E-C4A23B538920}.Release|Any CPU.Build.0 = Release|Any CPU
{96972380-1971-4C62-BE77-2C9C69870E22}.Debug|Any CPU.ActiveCfg = Debug|Any CPU
{96972380-1971-4C62-BE77-2C9C69870E22}.Debug|Any CPU.Build.0 = Debug|Any CPU
{96972380-1971-4C62-BE77-2C9C69870E22}.Debug|Any CPU.Deploy.0 = Debug|Any CPU
{96972380-1971-4C62-BE77-2C9C69870E22}.Release|Any CPU.ActiveCfg = Release|Any CPU
{96972380-1971-4C62-BE77-2C9C69870E22}.Release|Any CPU.Build.0 = Release|Any CPU
{96972380-1971-4C62-BE77-2C9C69870E22}.Release|Any CPU.Deploy.0 = Release|Any CPU
{0C5FC0D6-47FA-4274-9E65-AB388F8D9E96}.Debug|Any CPU.ActiveCfg = Debug|Any CPU
{0C5FC0D6-47FA-4274-9E65-AB388F8D9E96}.Debug|Any CPU.Build.0 = Debug|Any CPU
{0C5FC0D6-47FA-4274-9E65-AB388F8D9E96}.Release|Any CPU.ActiveCfg = Release|Any CPU
{0C5FC0D6-47FA-4274-9E65-AB388F8D9E96}.Release|Any CPU.Build.0 = Release|Any CPU
EndGlobalSection
GlobalSection(SolutionProperties) = preSolution
HideSolutionNode = FALSE
EndGlobalSection
GlobalSection(ExtensibilityGlobals) = postSolution
SolutionGuid = {8D1AACFE-123F-4CCE-A3B0-5791F4AE3F7D}
EndGlobalSection
EndGlobal
49 changes: 49 additions & 0 deletions Sitecore.DataExchange.Gutters/App_Config/Include/Rainbow.config
Original file line number Diff line number Diff line change
@@ -0,0 +1,49 @@
<!--
Rainbow.config

This file configures the Rainbow serialization library

This file should be present on all environments Rainbow is present on.

http://github.com/kamsar/Rainbow
-->
<configuration xmlns:patch="http://www.sitecore.net/xmlconfig/">
<sitecore>
<settings>
<!-- Rainbow - SERIALIZATION FOLDER PATH MAX LENGTH
In Windows, there is a 248 character limit on the length of file system paths. To avoid exceeding the maximum path length, Rainbow will loop
long paths back to the root. This setting specifies the maximum length of the path to the serialization root path,
which determines how long item paths can be before they are looped.
Important: The value of this setting must be the same on all Sitecore instances accessing the serialized data.
Important: When changing this value, you must reserialize all configurations!
Example: A value of "90" for this setting will mean that item paths longer than 150 characters will be shortened, since Sitecore
reserves 8 characters (and 248 - 8 - 90 = 150).
Default value: 110
-->
<setting name="Rainbow.SFS.SerializationFolderPathMaxLength" value="110" />

<!-- Rainbow MAX ITEM NAME LENGTH BEFORE TRUNCATION
Sitecore item names can become so long that they will not fit on the filesystem without hitting the max path length.
This setting controls when Rainbow truncates item file names that are extremely long so they will fit on the filesystem.
The value must be less than MAX_PATH - SerializationFolderPathMaxLength - Length of GUID - length of file extension.
Default value: 30
-->
<setting name="Rainbow.SFS.MaxItemNameLengthBeforeTruncation" value="30" />

<!-- Rainbow EXTRA INVALID FILENAME CHARACTERS
Sometimes source control systems, like TFS with '$', impose additional limitations on what files on disk may be named.
Adding characters to this setting will disallow their use in written SFS item names on disk.
Path.GetInvalidFileNameChars() are always included as invalid characters; this setting is for extra characters only.
Default value: $
-->
<setting name="Rainbow.SFS.ExtraInvalidFilenameCharacters" value="$" />

<!-- Rainbow INVALID FILE NAMES
Windows has certain file names that are disallowed that are device names. These apply regardless of file extension, so should you name an item PRN, we'll fix that.
See https://msdn.microsoft.com/en-us/library/windows/desktop/aa365247(v=vs.85).aspx
If an item name matches one of these names it will be prefixed with an underscore to make the name valid (e.g. COM1 -> _COM1)
-->
<setting name="Rainbow.SFS.InvalidFilenames" value="CON,PRN,AUX,NUL,COM1,COM2,COM3,COM4,COM5,COM6,COM7,COM8,COM9,LPT1,LPT2,LPT3,LPT4,LPT5,LPT6,LPT7,LPT8,LPT9" />
</settings>
</sitecore>
</configuration>
Original file line number Diff line number Diff line change
@@ -0,0 +1,19 @@
<configuration xmlns:patch="http://www.sitecore.net/xmlconfig/" xmlns:role="http://www.sitecore.net/xmlconfig/role/">
<sitecore>
<unicorn>
<configurations>
<configuration name="Sitecore.DataExchange.Gutters.Core">
<predicate>
<include name="Gutters" database="core" path="/sitecore/content/Applications/Content Editor/Gutters">
<exclude children="true">
<except name="DataExchange - Item Disabled" />
<except name="DataExchange - Pipeline Batch" />
<except name="DataExchange - Pipeline Step" />
</exclude>
</include>
</predicate>
</configuration>
</configurations>
</unicorn>
</sitecore>
</configuration>
Original file line number Diff line number Diff line change
@@ -0,0 +1,38 @@
<!--
Unicorn Auto Publish Configuration

This file configures the Unicorn serialization system to automatically publish items that it syncs.

This file should be removed on content delivery environments.

http://github.com/kamsar/Unicorn
-->
<configuration xmlns:patch="http://www.sitecore.net/xmlconfig/" xmlns:role="http://www.sitecore.net/xmlconfig/role/">
<sitecore role:require="Standalone or ContentManagement">
<pipelines>
<unicornSyncComplete>
<!-- at the end of each configuration's sync, we throw the items it changed into ManualPublishQueueHandler's queue -->
<processor type="Unicorn.Pipelines.UnicornSyncComplete.AddSyncedItemsToPublishQueue, Unicorn" />
</unicornSyncComplete>

<unicornSyncEnd>
<!-- when all configurations have synced, fire off a publish that processes the queue we've accumulated -->
<processor type="Unicorn.Pipelines.UnicornSyncEnd.TriggerAutoPublishSyncedItems, Unicorn">
<PublishTriggerItemId>/sitecore/templates/Common/Folder</PublishTriggerItemId> <!-- the trigger item can be any leaf node Sitecore item - just has to have a 'starting point' for the publish -->
<!-- these are the database(s) to publish synced items to -->
<TargetDatabases hint="list:AddTargetDatabase">
<web>web</web>
</TargetDatabases>
</processor>
</unicornSyncEnd>

<publish>
<!--
This handler manually injects arbitrary items into the publish queue so that the next publish to occur will cause the injected items to get published.
See http://www.velir.com/blog/index.php/2013/11/22/how-to-create-a-custom-publish-queue-in-sitecore/ et. al.
-->
<processor patch:after="*[@type='Sitecore.Publishing.Pipelines.Publish.AddItemsToQueue, Sitecore.Kernel']" type="Unicorn.Publishing.ManualPublishQueueHandler, Unicorn"/>
</publish>
</pipelines>
</sitecore>
</configuration>
Original file line number Diff line number Diff line change
@@ -0,0 +1,126 @@
<!--
Unicorn.Configs.Default.config

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 https://github.com/kamsar/Unicorn/blob/master/README.md
-->
<configuration xmlns:patch="http://www.sitecore.net/xmlconfig/" xmlns:role="http://www.sitecore.net/xmlconfig/role/">
<sitecore>
<unicorn>
<configurations>
<!--
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.

BEHAVIORS
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.

DEPENDENCIES
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.

TIPS
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="Feature.Sample" description="Write something here about why this configuration exists and what it's for. Or remove the attribute; it's optional.">
<predicate>
<!--
PREDICATE

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:
https://github.com/kamsar/Unicorn/blob/master/src/Unicorn.Tests/Predicates/TestConfiguration.xml

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 https://github.com/kamsar/Unicorn/wiki/The-Transparent-Sync-Guide
NOTE: If your configuration is named in Helix format (Layer.Module), you can use $(layer) and $(module) here as variables.
-->
<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>
<include database="master" path="/sitecore/system/Workflows" />
<include database="master" path="/sitecore/system/Settings" />
</predicate>

<!--
PREDICATE AND INCLUDE FIELD TRANSFORMS

- These transforms ONLY APPLY to what gets deserialized into Sitecore. Field values on disk/serialized datastore remain complete - respecting only the Rainbow field filter settings

IN OTHER WORDS:

Example: "-title, -text, +ApiUrl[{$apiUrlToken$}]" => All fields get deployed as normal, except "title" and "text". And "ApiUrl" gets a forced value.
Example: "!title, -text" => "Title" gets reset (to standard value), "Text" gets ignored.
Example: "?title, ?text" => ALL fields gets deployed, but fields "Title" and "Text" will only get their value deployed if target field value is empty
Example: "?title, ?text, !apiUrl" => As above, but field "apiUrl" is reset

"!field" => Reset this field unconditionally
"-field" => Ignore this field unconditionally
"?field" => Deploy this field if it has no value in target data store (Sitecore)
"+field[value]" => Force a new value into this field on target data store (Sitecore)
";field" => Force a "Lorem ipsum dolor" value into the field
":field" => Force a longer Lorem ipsum based HTML string into the field (around 2075 characters of Lorem Ipsum, broken up with <p> into sentences).
"$field[settingName]" => Grab the value of the Sitecore Setting `settingName` and force it as a value
-->
<predicate fieldTransforms=";Title,:Text,!Include In Sitemap,+Api Endpoint[{$apiEndPoint$}],?Default Product">
<include name="Sample Data" database="master" path="/sitecore/content/global/sample" fieldTransforms="-Title" /> /* Predicate transforms apply, but "Title" gets ignored on this include definition */
</predicate>


<!-- Clear Workflow fields on local development environments, but force a specific state upstream -->
<predicate>
<include role:require="Standalone" name="Sample Data" database="master" path="/sitecore/content/global/sample" fieldTransforms="!Workflow,!Workflow State" />
<include role:require="ContentManagement" name="Sample Data" database="master" path="/sitecore/content/global/sample" fieldTransforms="+Workflow[{2DE02B52-B95F-404A-A955-C36B290F1B57}],+Workflow State[{5ACE9C7F-8A18-4C77-BC30-03BE5A40E6B6}]"/>
</predicate>

<!--
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: https://github.com/kamsar/Unicorn/wiki/The-Transparent-Sync-Guide
-->
<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" />
</configuration>
</configurations>
</unicorn>
</sitecore>
</configuration>
Original file line number Diff line number Diff line change
@@ -0,0 +1,54 @@
<!--
This is an example of how to configure a Unicorn configuration that depends on other Unicorn configurations.

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

See Unicorn.config for commentary on how configurations operate, or https://github.com/kamsar/Unicorn/blob/master/README.md
-->
<configuration xmlns:patch="http://www.sitecore.net/xmlconfig/">
<sitecore>
<unicorn>
<configurations>
<!--
This is an example of how to configure a Unicorn configuration that, when synced along with Default Configuration,
will always sync after it because it is a dependency.

Dependencies do NOT force additional configurations to sync. So if you chose to sync only Sample Dependent Configuration,
it would not automatically sync Default Configuration. Dependency only comes into play when all dependencies are syncing at once,
or when all configurations sync together.
-->
<configuration name="Sample Dependent Configuration" dependencies="Default Configuration">
</configuration>

<!-- You may depend on more than one configuration. Transitive dependency relationships (e.g. A->B->C) are respected. -->
<configuration name="Sample Doubly Dependent Configuration" dependencies="Default Configuration,Sample Dependent Configuration">
</configuration>

<!-- You may depend on configurations by wildcards. -->
<configuration name="Sample Wildcard Dependent Configuration" dependencies="Foundation.*,Project.*">
</configuration>

<!--
Configurations will AUTOMATICALLY depend on each other if they include descendant roots of each other
e.g. in this example, 'Sample Implicit Child Configuration' will depend on 'Sample Implicit Parent Configuration'
-->
<configuration name="Sample Implicit Parent Configuration">
<predicate>
<include database="master" path="/sitecore/content" />
</predicate>
</configuration>
<configuration name="Sample Implicit Child Configuration">
<predicate>
<include database="master" path="/sitecore/content/Home" />
</predicate>
</configuration>

<!--
Picked up an implicit dependency you don't want? You can reject specific implicit dependencies, including with wildcards:
-->
<configuration name="Sample Rejected Implicit Dependency Configuration" ignoredImplicitDependencies="Foundation.Serialization,Project.*">
</configuration>
</configurations>
</unicorn>
</sitecore>
</configuration>
Loading

0 comments on commit e8f027a

Please sign in to comment.