Pages

09 May, 2022

Empower Content Authors to Copy Final to Shared Layout using a button in Content Editor ribbon

Sometimes Sitecore content authors would like to merge the layout from Final to Shared Layout so that the structure of the page can be common across all the languages. In this article, we can empower the content authors to copy Final to Shared layout themselves using a click of a button in the Content Editor ribbon using Sitecore PowerShell (SPE). 


Step 1: Add Integration Point & Module

With Sitecore PowerShell (SPE), there are multiple integration points available that may be added to modules. In this case, we need to add it as a Chunk in Presentation Ribbon. 
  • Add PowerShell Script Module in Script Library folder with a name. Example: Sample


  • In the newly Sample PowerShell Script Module item, add a Integration Point Libraries. This will open a window to select the integration points. In this dialog, choose Content Editor - Ribbon. This will add the ribbons which are available in this system as Script Library








  • In the Presentation item, add a PowerShell Script Library called Merge Layout. This will be the name of the chunk in the Presentation ribbon. And then add a PowerShell script item called Final to Shared. We can set an icon in the Appearance section of this item to match with the purpose of this button. In this case, we are merging the layout so I chose Arrow merge (/~/icon/office/32x32/arrow_merge.png).


  • In the script body, we can add this simple script to get the current item and then call Merge-Layout command. The Merge-Layout command takes all the layout information stored in the FinalLayout field and merges into the SharedLayout field. The FinalLayout field is reset after the merge completes. This will be done only in the current language. In case if other languages are having final layout, additional script should be added to remove the Final Renderings field values in other languages. 


  • We can add Show Rule as "Where the item has a layout". We can also add Enable Rule to be specific to ACL of the project. For non-admins to use this button, I suggest to add whether the item is locked and locked by me. This will let the non-admins to run this script without any issues. 
  • In order to remove all the empty Ribbon libraries, go to Sample PowerShell Script Module item, right click, scripts, Purge Empty Libraries. This will remove all the empty Script Libraries. 


Step 2: Sync with Core database

Some integrations need to be synced with the Core database through the PowerShell ISE. 
  1. Open Sitecore PowerShell ISE from Launch Page. 
  2. Go to Settings Ribbon, Rebuild All button, Sync Library with Content Editor Ribbon. This will sync the newly created integration to sync with Core database. 


Since there are Show and Enable rule, if the selected item matches the rules, then button will show in the Presentation tab and we can merge the layout from Final to Shared layout by clicking the button. 



29 April, 2022

Shared Fields & Publish Related Items - Possible Impact

Shared fields (includes Shared Layout) and Publish related items may lead to unexpected results to the content in target database.  

First, let's talk about Shared Fields.

  1. Shared fields are shared by all versions in all languages.
  2. Shared field changes will be published even though the latest version of the item is not in final workflow state. 
  3. Shared field values cannot be staged in a draft workflow state unless we use publishing restrictions. 
Scenario:
  1. Item has a Shared field of type checkbox. Version 1 of the item has this field checked. 
  2. Version 1 is approved and published. 
  3. User creates Version 2 and it is in draft state. User updates the Shared field checkbox to unchecked. 
  4. Keeping the item in draft state, user publish the item and Sitecore will complain that the version is not in final state so it will publish the Version 1 instead. 
  5. Version 1 will be published along with the Shared field checkbox changes (unchecked).

It is known and expected that Sitecore will publish the Shared field changes along with the previously approved item version.





Second, let's talk about the publish related items. 


    Scenario:

    1. Site has two languages: English and German. 
    2. All the items have 1 language version each and they are approved and published.
    3. Content author A creates a new version (draft state) in SiteHome item and updates the Shared field from unchecked to checked. Also added a component in Shared Layout so that it is applicable for all the languages. 
    4. Content author B adds Blog item as a link in the CTA item and publishes CTA item with publish related items option. Deep scan is disabled in the configuration. 

    List of items which are published by Sitecore:
    Publishing Item: {AF584191-45C9-4201-8740-5409F4CF8BDD} Skipped /sitecore/system/Languages/en
    Publishing Item: {F68F13A6-3395-426A-B9A1-FA2DC60D94EB} Skipped /sitecore/templates/System/Language
    Publishing Item: {15D7E7A7-36CF-4FE4-938D-229098EDD7E4} Skipped /sitecore/templates/System/Language/Data
    Publishing Item: {49E5E8F3-ED4A-4A06-ABE1-B9408951DEE9} Skipped /sitecore/templates/System/Language/Data/Charset
    Publishing Item: {990596CE-0024-43F3-BF4C-A991BFA69B45} Skipped /sitecore/templates/System/Language/Data/Code page
    Publishing Item: {60669E54-7B9C-4B55-A0C4-8F25059D8B94} Skipped /sitecore/templates/System/Language/Data/Dictionary
    Publishing Item: {8728D8FF-66D9-40C2-8B34-C4FC1466942E} Skipped /sitecore/templates/System/Language/Data/Encoding
    Publishing Item: {892975AC-496F-4AC9-8826-087095C68E1D} Skipped /sitecore/templates/System/Language/Data/Fallback Language
    Publishing Item: {C437E416-8948-427D-A982-8ED37AE3F553} Skipped /sitecore/templates/System/Language/Data/Iso
    Publishing Item: {0620F810-9294-4F14-AF9F-F5772EFCA0B2} Skipped /sitecore/templates/System/Language/Data/Regional Iso Code
    Publishing Item: {BB50A232-0C2C-48E5-B291-A8DA2ACCB8FE} Updated /sitecore/content/Home/SiteHome/Page 1/CTA
    Publishing Item: {110D559F-DEA5-42EA-9C1C-8A5DF7E70EF9} Skipped /sitecore/content/Home
    Publishing Item: {77FAC5E0-CE1B-4707-994B-1B36304A1E82} Updated /sitecore/content/Home/SiteHome
    Publishing Item: {7C63C8F3-28D4-4CCC-9EEC-915CB1931492} Skipped /sitecore/content/Home/SiteHome/Page 2
    Publishing Item: {8749DC20-2620-4211-A3A8-A6F3B872B8DD} Skipped /sitecore/content/Home/SiteHome/Page 2/Blog
    Publishing Item: {AE76A034-9491-4B83-99F5-39F227D6FB59} Skipped /sitecore/templates/Sample/Sample Item/Data
    Publishing Item: {75577384-3C97-45DA-A847-81B00500E250} Skipped /sitecore/templates/Sample/Sample Item/Data/Title
    Publishing Item: {2AC61A5A-016B-4EF4-AD27-F7C2837937CC} Skipped /sitecore/templates/Sample/Sample Item/Data/Flag
    Publishing Item: {A60ACD61-A6DB-4182-8329-C957982CEC74} Skipped /sitecore/templates/Sample/Sample Item/Data/Text
    .......(truncated)
    Looking at the above list, these three items are included for a reason. 

    Skipped:  /sitecore/content/Home
    Updated: /sitecore/content/Home/SiteHome
    Skipped:  /sitecore/content/Home/SiteHome/Page 2

    The Blog item is a related item for CTA item. In order to publish the related item "Blog", Sitecore parse the parent items till the Sitecore's root item (/sitecore), publish it first and then publish the Blog item. 

    Reason: In order to maintain the same content tree in the target database, Sitecore publishes every parent items of related item before publishing the related item. 

    Impact:

    The SiteHome item (version 2) which is in draft and has changes to a Shared field and the Shared Layout (__Renderings) are also published though it is not ready to be published. Sitecore publishes version 1 with Shared field changes to Target database.

    Any out of the box configuration? 

    Reached out to a Sitecore MVP and also raised Sitecore support to see if there is an out of the box option to skip these parent items if the target database already has the same content tree. There is no configuration available to skip these items. Sitecore support also agree that if the content tree is same in target database, there is no reason to publish these parent items and unnecessarily publish these staged shared field changes. 

    Sitecore support registered a feature request to change the default Sitecore behavior that can cause problems at the site by publishing changes that are not in the final workflow state so that it can be considered for future implementation and provided a reference number. 

    Possible approach to fix this issue:

    We can customize the <getItemReferences> pipeline to add a logic to allow a parent of related items to be published if it isn’t present in the target database. The processor "GetItemReferencesProcessor" can be tweaked to prevent publishing the parent items of the related item if the content tree matches with the source database. There will be a significant impact to the publish performance. I will create another blog once I have a working prototype with this implementation. 

    Comment if you have any thoughts on this article. 

    20 April, 2022

    Toggling Shared/Unversioned Field in Template does not propagate content between language versions

    Recently in Sitecore 10, we faced an issue where Shared field value is not getting propagated to a new language version. There is a known KB article from Sitecore https://kb.sitecore.net/articles/045873.

    As per the article, it is applicable for version 6 to version 8.2 Update 1. Tried to use this package locally to see if it works but gave method not found error. So I thought to peek into the code and do the same task in Sitecore PowerShell. 

    Basically we are resetting the Shared and Unversioned field value and then setting it up to the originally configured value. As per Sitecore, there might be a loss of data during the processing. A regression may be needed after the execution. 

    Step 1:

    • Find the list of template fields which are corrupted using a script.
    • Save the output in a CSV File with header ItemID.

    Step 2:

    • Run the below script in Sitecore PowerShell ISE.
    • Select and update load the CSV file created from Step 1. 
    • Script will run for few minutes based on the number of corrupted field ids. 

    22 March, 2022

    Sitecore CLI - Authentication and Authorization

    Sitecore has a very good documentation on Authentication and Authorization. As stated, there are two flows. 
    1. Interactive User Login
      • Sitecore Username and Password are needed. 
      • Used mostly by the developers.
    2. Non-Interactive Client Login
      • Client ID and Client Secret are needed. 
      • Client should be configured in Identity server and Identity provider should be configured in Content Management as documented
      • Used for CI/CD process to automate tasks.
    In both the flows,  
    • Identity server is must. 
    • The result of the authentication and authorization is access token. If we wanted extended expiry of tokens for a longer running process, we can opt for refresh token. 
    When we initiate the interactive login request using dotnet sitecore login --authority https://id.sitecorewarriors.localhost/ --cm https://cm.sitecorewarriors.localhost --allow-write true, Sitecore ID login screen will appear. Once logged in, we will get two options. 


    Offline Access will generate refresh token along with short lived access token. A refresh token is a credential artifact that lets a client application get new access tokens without having to ask the user to log in again.

    .sitecore/user.json file will be populated with the access token and refresh token. So we should not commit the .sitecore/user.json file to source control as it contains sensitive information.


    21 March, 2022

    Sitecore CLI Extension Development - Possible errors and solution

    While we (Sitecore Warriors) were working on creating Sitecore CLI extension in Sitecore Hackathon, we came across few errors and I would like to share it in this article. 

    • Could not locate plugin SitecoreWarriors.DevEx.Extensibility.Jobs@4.1.1. Some CLI commands may not function correctly.

      To speed up the development and testing the plugin, we can manually place the plugin assembly in /.sitecore/package-cache/nuget/PluginName and add the plugin name in the sitecore.json file. 


      Possible Reason 1: If the assembly name and plugin name do not match, then we will get this error. Once we set the same name for plugin as well the assembly name, the dotnet sitecore -h command will list the plugin. 

      Possible Reason 2: If the nuget package or the plugin assembly is not placed inside a folder called plugin, you will get this error. 


      PS C:\Project\Working\CLI> dotnet sitecore -h
      >> Begin installing NuGet packages: SitecoreWarriors.DevEx.Extensibility.Jobs@4.1.1
      >>> Skipping NuGet package SitecoreWarriors.DevEx.Extensibility.Jobs@4.1.1 because it is already installed.
      Could not locate plugin SitecoreWarriors.DevEx.Extensibility.Jobs@4.1.1. Some CLI commands may not function correctly.

    • Plugin does not supported by the current version of the CLI. Please try to update you CLI

      Plugin product should be .NET Core project. If the plugin assembly project is created as a Web SDK (Microsoft.NET.Sdk.Web) project instead of just an SDK project, CLI will not be able to recognize the plugin. Make sure the project type is Microsoft.NET.Sdk


    blockquote { margin: 0; } blockquote p { padding: 15px; background: #eee; border-radius: 5px; } blockquote p::before { content: '\201C'; } blockquote p::after { content: '\201D'; }