1. Sitecore CLI command reference

The CLI serialization command

The Sitecore serialization plugin provides the serialization command with the short form ser.

This command handles the serialization of items.

To install the serialization plugin, run the following code:

shell
dotnet sitecore plugin add -n Sitecore.DevEx.Extensibility.Serialization

Usage

You can use the command as follows:

shell
dotnet sitecore serialization [subcommand] [options]

Alternatively, you can use the short form for the command as follows:

shell
dotnet sitecore ser [subcommand] [options]

Subcommands

You can use the following subcommands:

  • info - shows serialization configuration information.
  • explain - explains whether a content item path is included and why.
  • pull - serializes content items from a Sitecore instance to your file system.
  • push - pushes serialized content items from your file system to a Sitecore instance.
  • diff - compares the content items of two Sitecore instances.
  • validate - checks serialized content items for validity. Can fix common issues with the --fix argument.
  • watch - monitors changes to content items in a Sitecore instance and automatically serializes the changes to your file system.
  • package - provides additional commands for working packages of serialized items.
  • package create - creates a package of serialized items.
  • package install - installs a package of serialized items in a Sitecore instance.

The info subcommand

The info command provides information about how the solution is set up and configured for use as it relates to content serialization.

The information returned by the command includes a list of all serialization module configurations. For every serialization module configuration, the information includes:

  • Module name.
  • Module description.
  • Item subtrees with name and path.

You can use the following options with the info subcommand:

OptionRequired?Description
-i, --include NoSpecify module configurations to include. Supports module name, tags. Wildcards and multiple values are allowed.
-e, --exclude NoSpecify module configurations to exclude explicitly. Supports module name, tags. Wildcards and multiple values are allowed.
-c, --config NoPath to root sitecore.config directory. Default: current working directory.
-v, --verboseNoWrite additional diagnostic and performance data.
-t, --traceNoWrite additional diagnostic and performance data.
-?, -h, --helpNoDisplay developer help and usage information about the command.

The following is an example of using the info subcommand:

shell
dotnet sitecore ser info
shell
\> sitecore ser info

Maximum subtree-relative item path allowed: 100

Feature.BasicContent
  Subtrees:
    templates: /sitecore/templates/Feature/BasicContent
    renderings: /sitecore/layout/Renderings/Feature/BasicContent
    buttons: core:/sitecore/content/Applications/WebEdit/Custom Experience Buttons/BasicContent
      FieldsFilter Excludes: 0
  Roles: 0

# ...

Project.DemoContent
An example of separating content into a separate module, so it can be excluded from deploy.
  Subtrees:
    content: /sitecore/content/Basic Company
    media: /sitecore/media library/Basic Company
      FieldsFilter Excludes: 1
  Roles: 0

Excluded Fields From Default Serialization Config:
      FieldsFilter Excludes: 1

The explain subcommand

You can use the explain to provide detailed serialization-related information on a given Sitecore item path and an optional database.

The subcommand provides the following:

  • Item path is within the scope of any serialization modules.
  • Related allowed operations for the given item path.
  • Path to the serialization Module.json set up for the given path.

You can use the following options with the explain subcommand:

OptionRequired?Description
-p, --path YesItem path to explain.
-d, --database NoDatabase of the item path to explain. Default: master.
-c, --config NoPath to root sitecore.config directory. Default: current working directory.
-v, --verboseNoWrite some additional diagnostic and performance data.
-?, -h, --helpNoDisplay developer help and usage information about the command.

The following are examples of using the explain subcommand:

  • Explain a path not included in any module configuration:

    shell
    dotnet sitecore ser explain --path "NOT_INCLUDED_PATH"

    Output:

    shell
    Path master:NOT_INCLUDED_PATH is not included in any module configuration.
  • Explain a path included in a module configuration:

    shell
    dotnet sitecore ser explain --path "INCLUDED_PATH"

    Output:

    shell
    [MODULE_NAME] [INCLUDED_PATH] Item path matches subtree scope ItemAndDescendants.
    [MODULE_NAME] [INCLUDED_PATH] Subtree set allowed push operations CreateUpdateAndDelete
    [MODULE_NAME] [INCLUDED_PATH] Path master:INCLUDED_PATH is included!
    Physical path:PATH_TO_YAML_FILE

The pull subcommand

The pull subcommand takes items from Sitecore, serializes them, and stores them as .yml files on a given file system path. The subcommand uses Module.json files to determine what items are included in the serialization process. During the pull operation, the serialization engine evaluates existing serialized items on disk and performs a deep comparison of the same items in the source Sitecore instance.

This command requires elevated permissions.

You can use the following options with the pull subcommand:

OptionRequired?Description
-n, --environment-name NoNamed Sitecore environment to use. Default: 'default';
-i, --include NoSpecify module configurations to include. Supports module name, tags. Wildcards and multiple values are allowed.
-e, --exclude NoSpecify module configurations to exclude explicitly. Supports module name, tags. Wildcards and multiple values are allowed.
-w, --what-ifNoList the commands involved in the operation without running them.NoteSee the video Sitecore CLI and the 'what-if' flag for more information on the -- what-if option.
-s, --skip-validationNoSkip filesystem integrity validation before syncing.
-c, --config NoPath to root sitecore.config directory. Default: current working directory.
-v, --verboseNoWrite additional diagnostic and performance data.
-t, --traceNoWrite additional diagnostic and performance data.
-fr, --forceNoShow a warning instead of an error. Skip the item causing the warning and continue serialization.
--use-debug-signaturesNoUse debug (un-hashed) item signatures to diagnose hash mismatches. Much slower.
-?, -h, --helpNoDisplay developer help and usage information about the command.

The following are examples of using the pull subcommand:

  • Serialize all sitecore items from the configurations:

    shell
    dotnet sitecore ser pull
  • Serialize all Sitecore items from the ModuleA and ModuleB configurations:

    shell
    dotnet sitecore ser pull -i ModuleA ModuleB
  • Serialize all Sitecore items from the modules tagged as tagA and tagB configurations:

    shell
    dotnet sitecore ser pull -i tags:[tagA,tagB]
  • Serialize all items from the modules tagged as tagA, tagB, and ModuleA configurations:

    shell
    dotnet sitecore ser pull -i tags:[tagA,tagB] ModuleA

The push subcommand

The push command takes items serialized as .yml files on disk and pushes them to a destination Sitecore instance. The push operation uses serialization Module.json files to determine the items included in the serialization process. During the push operation, the serialization engine evaluates existing serialized items on the file system and performs a deep comparison of the same Items in the source Sitecore instance.

This command requires elevated permissions.

You can use the following options with the push subcommand:

OptionRequired?Description
-n, --environment-name NoNamed Sitecore environment to use. Default: 'default'.
-i, --include NoSpecify module configurations to include. Supports module name, tags. Wildcards and multiple values are allowed.
-e, --exclude NoSpecify module configurations to exclude explicitly. Supports module name, tags. Wildcards and multiple values are allowed.
-w, --what-ifNoList the commands involved in the operation without running them.
-s, --skip-validationNoSkip file system integrity validation before syncing.
-c, --config NoPath to root sitecore.config directory. Default: current working directory.
-v, --verboseNoWrite additional diagnostic and performance data.
-t, --traceNoWrite additional diagnostic and performance data.
-fr, --forceNoShow a warning instead of an error. Skip the item causing the warning and continue serialization.
--use-debug-signaturesNoUse debug (un-hashed) item signatures to diagnose hash mismatches. Much slower.
-p, --publishNoPublish synced items.
--pt, --targets NoList of targets database to publish. Blank publishes to the web database.
-?, -h, --helpNoDisplay developer help and usage information about the command.

The following are examples of using the push subcommand:

  • Push all Sitecore items from the configuration to the Sitecore instance:

    shell
    dotnet sitecore ser push
  • Push all Sitecore items from the ModuleA and ModuleB configurations to the Sitecore instance:

    shell
    dotnet sitecore ser push -i ModuleA ModuleB
  • Push all Sitecore items from the modules tagged as tagA and tagB configurations to the Sitecore instance:

    shell
    dotnet sitecore ser push -i tags:[tagA,tagB]
  • Push all Sitecore items from the modules tagged as tagA, tagB, and ModuleA configurations to the Sitecore instance:

    shell
    dotnet sitecore ser push -i tags:[tagA,tagB] ModuleA

The diff subcommand

The diff subcommand compares serialization items between a source Sitecore instance and a destination Sitecore instance. The operation uses serialization Module.json files to determine the items included in the comparison process. During the diff command, the serialization engine performs a deep comparison of paths and items in the source Sitecore instance and the destination Sitecore instance.

This command requires elevated permissions in both source and target environments.

To use the diff subcommand, you must log in to both the source and destination environments using client credentials, which will generate access tokens for each environment. If you don't log in to both environments, running the command will result in a missing access token error.

You can log in to each environment and automatically generate the necessary access tokens in the .sitecore/user.json file using the following command:

shell
dotnet sitecore login \\
  --authority https://auth.sitecorecloud.io/ \\
  --cm https://<ENVIRONMENT_HOST_NAME> \\
  --audience https://api.sitecorecloud.io \\
  --client-credentials true \\
  --client-id <ENVIRONMENT_CLIENT_ID> \\
  --client-secret <ENVIRONMENT_CLIENT_SECRET> \\
  --allow-write true \\
  -n "<ENVIRONMENT_NAME>"

Replace the environment name and host name with the actual environment values in the Deploy app, and the client ID and client secret with your actual client credentials.

You can use the following options with the diff subcommand:

OptionRequired?Description
-s, --source YesNamed Sitecore endpoint to use as a source for comparison.
-d, --destination YesNamed Sitecore endpoint to use as a destination for comparison.
-i, --include NoSpecify module configurations to include. Supports module name, tags. Wildcards and multiple values are allowed.
-e, --exclude NoSpecify module configurations to exclude explicitly. Supports module name, tags. Wildcards and multiple values are allowed.
-p, --path NoItem path to compare (instead of include/exclude).
--source-database NoSource database (when used with --path).
--destination-database NoDestination database (when used with --path).
--pushNoApply the detected differences to the destination.
-c, --config NoPath to the root sitecore.config directory. Default: current working directory.
-v, --verboseNoWrite additional diagnostic and performance data.
-t, --traceNoWrite additional diagnostic and performance data.
-?, -h, --helpNoDisplay developer help and usage information about the command.

The following is an example of using the diff subcommand:

shell
dotnet sitecore ser diff -s SOURCE -d DESTINATION

Output:

shell
[DBNAME] Discovered CHANGES_COUNT changes after evaluating ITEMS_COUNT total items.

The validate subcommand

The validate subcommand ensures file system integrity of serialized items and paths. Additionally, by using the --fix (-f) argument option flag, the command can attempt to auto-correct identified issues. The subcommand evaluates all serialized paths and subtrees on the file system configured in serialization Module.json files and performs the following checks on the file system:

  • Invalid physical path.
  • Orphaned parent ID.
  • Non-included item.
  • Empty folder.
  • Duplicate item ID.
  • Non-unique path.
Note

For more information, see Validate serialized content items.

You can use the following options with the validate subcommand:

OptionRequired?Description
-i, --include NoSpecify module configurations to include. Supports module name, tags. Wildcards and multiple values are allowed.
-e, --exclude NoSpecify module configurations to exclude explicitly. Supports module name, tags. Wildcards and multiple values are allowed.
-f, --fixNoExecute possible fix operations when validating the serialized items.ImportantUsing the --fix (-f) option can delete local files.
-c, --config NoPath to the root sitecore.config directory. Default: current working directory.
-v, --verboseNoWrite additional diagnostic and performance data.
-t, --traceNoWrite additional diagnostic and performance data.
-?, -h, --helpNoDisplay developer help and usage information about the command.

The following are examples of using the validate subcommand:

  • Read-only validation:

    shell
    dotnet sitecore ser validate

    Output:

    shell
    Read-only validation is active. No fixes will be made.
    No errors were detected.
  • Vaidate and fix:

    shell
    dotnet sitecore ser validate --fix

    Output:

    shell
    DUPLICATE ID: 5c069416-660c-4028-b5c8-c9f3ce3cb277 found in ...
    [D] ~\\FILE_DUPLICATE.yml
    ...
    No errors were detected.

The watch subcommand

The watch subcommand monitors changes to content items in a Sitecore instance and automatically serializes the changes to your file system.

This command requires elevated permissions.

You can use the following options with the watch subcommand:

OptionRequired?Description
-n, --environment-name NoNamed Sitecore environment to use. Default: 'default';
-i, --include NoSpecify module configurations to include. Supports module name, tags. Wildcards and multiple values are allowed.
-e, --exclude NoSpecify module configurations to exclude explicitly. Supports module name, tags. Wildcards and multiple values are allowed.
-s, --skip-pullNoSkip pulling data from Sitecore before starting the watcher.
--allow-file-changesNoContinue watching files if they change.ImportantUsing this option can result in tree corruption if the underlying state is changed.Use this option only if some other program touches serialized files that are not changing.
-fr, --forceNoShow a warning instead of an error. Skip the item causing the warning and continue serialization.
-c, --config NoPath to the root sitecore.config directory. Default: current working directory.
-v, --verboseNoWrite additional diagnostic and performance data.
-t, --traceNoWrite additional diagnostic and performance data.
-?, -h, --helpNoDisplay developer help and usage information about the command.

The following is an example of using the watch subcommand:

bash
dotnet sitecore ser watch

Output:

shell
Watcher is online! Changes made to serialized items will be automatically pulled.

The package subcommand

The package subcommand (short form pkg) provides additional subcommands for package specific operations, as follows:

SubcommandDescription
createCreates a new serialized item package.
installInstall an existing item package to Sitecore.This command requires elevated permissions.

You can use the following options with the package subcommand:

-?, -h, --helpDisplay developer help and usage information about the command.

The package create subcommand

The package create subcommand creates a new serialized item package.

You can use the following options with the package create subcommand:

OptionRequired?Description
-o, --output YesPath for placing the package after creation. If you do not provide an extension, it is added for you.
--overwriteNoAllow overwriting an existing package.
-i, --include NoSpecify module configurations to include. Supports module name, tags. Wildcards and multiple values are allowed. From version 4.1.0 and later, roles specified in a Serialization Module are also serialized.
-e, --exclude NoSpecify module configurations to exclude explicitly. Supports module name, tags. Wildcards and multiple values are allowed.
-c, --config NoPath to the root sitecore.config directory. Default: current working directory.
-v, --verboseNoWrite additional diagnostic and performance data.
-t, --traceNoWrite additional diagnostic and performance data.
-?, -h, --helpNoDisplay developer help and usage information about the command.

The following are examples of using the package create subcommand:

  • Create a package at a specified file path:

    shell
    dotnet sitecore ser pkg create -o <file-path>
  • Serialize a module with roles:

    json
    {
        "namespace": "Feature.Products",
        "roles": [
            {
                "domain": "DevEx",
                "pattern": "Product"
            }
        ]
    }
    shell
    dotnet sitecore ser info --include Feature.Products -v

    Output:

    shell
    [role] [A] Role DevEx\\Product Admin is created successfully.
    [role] [A] Role DevEx\\Product Merchandiser is created successfully.
    [roles] Synced 2 roles completed.

The package install subcommand

The package install subcommand installs an existing item package to Sitecore.

This command requires elevated permissions.

You can use the following options with the package install subcommand:

OptionRequired?Description
-f, --package YesPath to the package to install.
--auth, --authority NoIdentity authority for the environment, such as identity server or AAD tenant URL.
--cm NoSitecore content management hostname to connect to.
--client-id NoThe OAuth ClientID to send. Defaults to 'Device' for device auth and 'SitecoreCLIServer' for client credentials.
--client-secret NoThe OAuth ClientID to send. Defaults to 'Device' for device auth and 'SitecoreCLIServer' for client credentials.
-n, --environment-name NoNamed Sitecore environment to use. Default: 'default'.
-w, --what-ifNoList the commands involved in the operation without running them.
-i, --include NoSpecify module configurations to include. Supports module name, tags. Wildcards and multiple values are allowed.
-e, --exclude NoSpecify module configurations to exclude explicitly. Supports module name, tags. Wildcards and multiple values are allowed.
-c, --config NoPath to root sitecore.config directory. Default: current working directory.
-v, --verboseNoWrite additional diagnostic and performance data.
-t, --traceNoWrite additional diagnostic and performance data.
-p, --publishNoPublish synced items.Because of performance concerns, we recommend you avoid using this option with the Publishing Service.
-?, -h, --helpNoDisplays developer help and usage information about the command.

The following is an example of using the package install subcommand to install a package using the file path to the Sitecore instance:

shell
dotnet sitecore ser pkg install -f <file-path>
If you have suggestions for improving this article, let us know!