Ghanendra's Tips

Do you know that version 10.1 onwards, Sitecore is storing default items as resource files. This is an interesting update as the files on disk are binary-serialized item data using Google’s ProtoBuf specification – in this case using the ProtoBuf.Net library for .Net. Why to store item as resource files? Sitecore has lots of  out-of-box items like sitecore/content/Home which are present in Sitecore databases. Sitecore has changed this approach to store these items on file system as resource files as ProtoBuf data to solve the complexity related to upgrading the Sitecore instances especially in containerized environments. If you have an instance of Sitecore 10.1 or above running, you will find these below files. Default Sitecore items are part of these files now -  How do they help in upgrades? In containerized solution, code and config updates are wrapped in Docker Image. When the out of box Sitecore items are placed in resource files, they get updated as part of Docker Image itself. T

  While performing dotnet sitecore ser push, I received following error- Unhandled exception: System.Exception: Unhandled exception  ---> System.AggregateException: One or more errors occurred. (Error converting value 404 to type 'GraphQL.Common.Response.GraphQLResponse'. Path '', line 1, position 3.) (Error converting value 404 to type 'GraphQL.Common.Response.GraphQLResponse'. Path '', line 1, position 3.) (Error converting value 404 to type 'GraphQL.Common.Response.GraphQLResponse'. Path '', line 1, position 3.) (Error converting value 404 to type 'GraphQL.Common.Response.GraphQLResponse'. Path '', line 1, position 3.) (Error converting value 404 to type 'GraphQL.Common.Response.GraphQLResponse'. Path '', line 1, position 3.) (Error converting value 404 to type 'GraphQL.Common.Response.GraphQLResponse'. Path '', line 1, position 3.)  ---> Newtonsoft.Json.JsonSerializationException:

  While running dotnet sitecore ser push, I encountered following error- Unhandled exception: System.Exception: Unhandled exception ---> System.NullReferenceException: Object reference not set to an instance of an object. at Sitecore.DevEx.Serialization.Client.TreeCongruencyCommandBuilder.GenerateCommands(TreeSpec subtree, ITreeDataStore sourceDataStore, ITreeDataStore destinationDataStore, CancellationToken cancellationToken) at Sitecore.DevEx.Serialization.Client.TreeSyncOperation.DiscoverCommands(TreeSpec subtree, TreeCongruencyCommandBuilder commandBuilder, CancellationToken cancellationToken) at Sitecore.DevEx.Serialization.Client.TreeSyncOperation.DiscoverCommands(Boolean applyAllowedPushOperations, IEnumerable MyProject.module.json file had following entry which pointed to a non-existent node in Sitecore. The node was moved to a different folder as part of a PR but the entry in MyProject.module.json was not updated. Hence the error. - { "allowedPushOperations": &quo

So  I was using Sitecore 8.2 and working on one of my development tickets. While committing my changes to source control, I observed,  for some reason,  created field value for TDS item was updated on my local instance (highlighted in snapshot). I knew this was not the Sitecore item created date field which is represented by __Created (also in snapshot). I looked around but didnt find  much information on what this field represents and why it was updated on my local.  So I started digging and also reached out to Sitecore support and below is the observation - Created field values are updated by Sitecore serialization. TDS doesn't directly update them, it uses the Serialization API to get the item and it is changed/updated by the API Created field is ignored by TDS for sync and compare. It was not present in older versions of Sitecore, therefore, we don't use it to maintain backward compatibility. Since it is ignored by TDS, there is not much information about the field, but it