Sitecore 10.4.0 Release notes visually explained

 1. Updated the media item duplication logic to resolve issues when deleting duplicates of a media item sharing the same blob. Now, duplicating a media item creates a duplicate of a blob. After upgrading to this version, you must run the /sitecore/admin/duplicates.aspx admin page to ensure all duplicate media items in your solution refer to a blob copy, not a shared one. See ADO no. 563054 in Resolved issues.

This new feature is useful when you upgrade from earlier versions of Sitecore. The code-behind for the duplicates page, present in Sitecore.Client.dll, updates value field in ArchivedFields table based on a set of conditions. I will update this space with more details in coming days:

For now, I created a package in earlier version of Sitecore by duplicating media items within a folder, and installed it in a Sitecore 10.4.0 instance. Next, I traversed to the new duplicates.aspx page and when I clicked the fix duplicates button the duplicates were resolved:

On the other hand, when I duplicated an existing media item in a 10.4.0 instance, it seemed to follow the 10.4.0 logic of keeping the media blob unique rather than using a shared copy. 

2. Added a new Sitecore Client Content Reader user role that grants read access to Content Tree items in the Content Editor and Media Library.

Here is the definition for the new Sitecore Client Content Reader role:


This role seems like a supplementary role. In other words, if you assign just this role to a user and the user tries to login, they would get this message in the login page:
  • You do not have access to the system. If you think this is wrong, please contact the system administrator.

 The user is unable to login since they need a main role like Sitecore Client Users:


End-result:




3. Image files with the .ico extension are now correctly identified as images and displayed in the Media Library.

In earlier version of  Sitecore (10.3.x here):

Although an ico file can be uploaded, its not recognised:


In Sitecore 10.4.0:

An ico file can be uploaded and its recognised:


4. Updated the Domain Manager text in the pop-up window, when creating a new domain.

Domain name message now clearly states what is expected: "The domain name can only contain the following characters: A-Z, a-z, 0-9, and _ (underscore)."


Note that this is an existing functionality but the message is corrected now. In earlier versions, here is the message for reference:


Also note that although both uppercase and lowercase alphabets are allowed, if you want to have two different domains with one in lowercase and other in uppercase, it isn't allowed. In other words, domain name is case-insensitive:



5. Enhanced security with system administrators having the power to enable or disable SVG files containing JavaScript from being uploaded to the Media Library by default.

Create an svg file with example javascript code such as this  and upload to media library

navan.svg
****
Click the circle to change colors.
<svg
  viewBox="0 0 10 10"
  height="120px"
  width="120px"
  xmlns="http://www.w3.org/2000/svg">
  <circle cx="5" cy="5" r="4" />

  <script>
    // <![CDATA[
    function getColor() {
      const R = Math.round(Math.random() * 255)
        .toString(16)
        .padStart(2, "0");

      const G = Math.round(Math.random() * 255)
        .toString(16)
        .padStart(2, "0");

      const B = Math.round(Math.random() * 255)
        .toString(16)
        .padStart(2, "0");

      return `#${R}${G}${B}`;
    }

    document.querySelector("circle").addEventListener("click", (e) => {
      e.target.style.fill = getColor();
    });
    // ]]>
  </script>
</svg>
*****

Without the new patch config, file upload in media library results in the following error:

An error occured while uploading a file .

The reason may be that the file does not exist or the path is wrong.

This is a new behaviour  in Sitecore10.4.0 due to validateMedia pipeline(for security hardening):


After deploying the new patch config in the site web root - in other words, you are reverting to pre-10.4.0 behaviour for a svg file with JS - by deleting the new CheckSvgForJs processor within the validateMedia pipeline:

//////
//////


Now, the upload is possible after the new patching:

Note that if you upload a plain svg file, it gets uploaded  to media library without any stop-gate cautions. Also, if you directly copy over the svg with javascript code into a rich text editor, the rendering happens. Therefore, this security hardening is only specific to svg files with javascript code. 

6. The screenshot functionality that uses PhantomJS can now be disabled by switching the setting to false.

Every item has an ability to take screen shot, it is under the item appearance section:



From 10.4.0, there is a config file named Sitecore.ThumbnailGenerator.config under <cm root>\App_Config\Sitecore\CMS.Core and it has this screenshot setting apart from many new settings:

<setting name="Sitecore.Screenshots.Enabled" value="true"/>

For the purpose of explaining this particular release note, the setting defaults to true and what that means is, you can click this link that allows you to take a screenshot of the item:


On clicking the "Take screenshot" link, you are provided the following modal window that takes a screenshot of the item in different sizes on click of a button:


Now, if you switch back to the file system, you can see the screen shots stored in the temp folder of the web root:


On the other hand, if you patch the Sitecore.Screenshots.Enabled setting to false and click the Take screenshot link in the item appearance section, you wouldn't be able to screen shot:

<setting name="Sitecore.Screenshots.Enabled" value="false"/>

Screenshots are disabled by configuration.

In versions prior to 10.4.0, since there are no switches involved, the Take a Screenshot modal window will look like this with two options to screenshot:


From 10.4.0, if you need the URL option, you need to set the "Sitecore.ThumbnailsGeneration.AllowCustomUrl" setting in Sitecore.ThumbnailGenerator.config  to "true" apart from setting "Sitecore.Screenshots.Enabled" to "true".



In earlier versions, the images generated are generically prefixed with "thumbnail" while in case of 10.4.0, the name has a unique GUID as prefix for better clarity:


7. Changed the value of the ASP.NET validateRequest setting for the pages configuration node, to be enabled by default.

In versions prior to 10.4.0, the web root web.config pages node has the validateRequest set to false while it is changed to true in 10.4.0



First of all, the idea of this setting is to validate any form fields submitted to server with special characters (think of html tags). 


This is the effect of submitting such a form:

On the other hand, this validation happens mainly due to requestValidationMode in httpRuntime node set to 4.0 irrespective of pages validateRequest set to true or false. 

Also, here is the behaviour if requestValidationMode  is set to 2.0 irrespective of validateRequest set to true or false:


The above ysod is thrown after the request is posted to the controller since the request is not intercepted by the validation beforehand. So, in case of Sitecore 10.4.0, setting validateRequest to true seems more of a consistency paradigm considering that the requestValidationMode in httpRuntime is already set to 4.0 and cross site scripting attack protection in case of 4.0 seems a default behaviour irrespective of validateRequest setting!

8. You can now target specific audiences more effectively by adding custom languages, combining any ISO language code with a country/region code. This includes the ability to use nonstandard country/region codes, such en-EU.

As specified in this link' Add a Custom language section, Sitecore has the capability to add a custom language. To explain the new enhancement: In earlier versions, although you could add a specific custom language like en-Tn (note that Tn is a random locale I chose for this example and unsure if en-Tn is actually valid but hopefully it serves well for this example!), it wasn't visible during an item publish (probably needs more configuration) but from 10.4.0, this has been opened-up as shown in the following screen shots - the new language locale is visible in the publish item modal window as soon as added to the list of languages:

In 10.3.1:


From 10.4.0:


9. The Publish Manager now supports the publishing of multiple items.

The PublishManager class is part of Sitecore.Publishing namespace in Sitecore.Kernel.dll. You can see a sample example of how to use it in this blog post. In earlier versions of Sitecore, there were a couple of overloads for a method named PublishItem based on a single item. From 10.4.0,  apart from the old PublishItem methods there is a new method named PublishItems that accepts an array of items for publishing:

public static Handle PublishItems(Item[] items, Database[] targets, Language[] languages, bool deep,      bool compareRevisions, bool publishRelatedItems)



10. The data template name is now included in the payload of a webhook event handler request.

Based on my last year's blog post that sends a slack notification via a webhook handler on Sitecore item deletion, I deployed the SitecoreReceiver project to the SitecoreReceiver local virtual directory(with the correct slack incoming webhook api url in  SitecoreJsonWebHookHandler.cs):



After creating a webhook event handler in the 10.4.0 instance and making all necessary webhook handler setup (ditto as in my last year's blog post), when i deleted an item from the Sitecore content tree and loaded the event list page, could see the Template Name attribute in the payload:

10.3.1:


10.4.0:


11. Apart from enhancements, bug-fixes are also part of 10.4.0 release, one interesting fix is related to bulk upload media files wherein UploadAsFiles set to true wasn't respected in versions until 10.4.0. Note that this issue was only with bulk upload while single file upload behaved fine. With 10.4.0, when the setting is true, both during bulk upload and single file upload, media files are properly stored in the web server file system instead of the Blobs table (stored when setting is false) as depicted in the following comparison:

Media.UploadAsFiles Setting overview (correct flow):



10.3.1:




10.4.0:


12. There are also probably corrections required in the Sitecore documentation like for instance, Sitecore.Context.Language.CultureInfo is an existing static property rather than a new one as stated in this link but of course there are a few new properties like these in the new version:


10.3.1 vs 10.4.0:


References
https://www.sitecore.com/blog/news/sitecore-xp-10-4-now-available-features-more-than-200-enhancements
https://developers.sitecore.com/downloads/Sitecore_Experience_Platform/104/Sitecore_Experience_Platform_104/Release_Notes
https://doc.sitecore.com/xp/en/developers/104/what%27s-new/what-s-new-in-sitecore-experience-platform-10-4.html
https://developers.sitecore.com/downloads/Sitecore_Experience_Platform/104/Sitecore_Experience_Platform_104/Release_Notes#resolved-issues


Comments

Popular Posts