Wednesday, October 13, 2021

SXA Custom Token - Best practices to include the operation correctly.

 When implementing SXA custom token, it would be good to consider the options like must, should or not, this is already part of the SXA model, so basically we need to make sure to include the below conditions.

Pass the model operation name as a parameter -


 public override void Process(ResolveSearchQueryTokensEventArgs args)

        {

            if (args.ContextItem == null)

                return;

            for (int index = 0; index < args.Models.Count; ++index)

            {

                SearchStringModel model = args.Models[index];

                if (model.Type.Equals("sxa") && this.ContainsToken(model))

                {

                    string str = model.Value.Replace(this.TokenPart, string.Empty).TrimStart('|');

                    var fieldNames = str.Split('|').ToList();

                    if (fieldNames.Any() && fieldNames.Count == 2)

                    {

                        args.Models.Insert(index, this.BuildModel(fieldNames[0], fieldNames[1], model.Operation));

                        args.Models.Remove(model);

                    }

                }

            }

        }


  protected virtual SearchStringModel BuildModel(

            string replace,

            string fieldValue, string operation)

        {

            return new SearchStringModel("custom", FormattableString.Invariant(FormattableStringFactory.Create("{0}|{1}", replace.ToLowerInvariant(), fieldValue)))

            {

                Operation = operation

            };

        }

Model operation values - Just for the reference.



SXA boosting rule - Search Box Query

 As we know that Sitecore has provided a lot of rule-based boosting options, I found the below rule very useful in a recent implementation.





We can see the appropriate logs to see that boosting is applied correctly.

2021-10-13 22:34:12.460 INFO  (qtp23211803-22) [c:sitecore_sxa_dev_master_index s:shard1 r:core_node2 x:sitecore_sxa_dev_master_index_shard1_replica_n1] o.a.s.c.S.Request [sitecore_sxa_dev_master_index_shard1_replica_n1]  webapp=/solr path=/select params={q=((((((_template:(c03a48a03baf4ba09f10774f365841a4)+OR+_template:(911e99589fa64e85901eac0e0fc96009))+AND+((_path:(0513592509aa40188c47987bc6f9236a)+AND+searchable_b:(True))+OR+(_path:(e86fa7d2714741548e25c0bcdb9217fb)+AND+searchable_b:(True))+OR+(_path:(225d1bc67544492d8d752fdaa1a7151c)+AND+searchable_b:(True))+OR+(_path:(9377586f8345460b8dd01e24a451aeb6)+AND+searchable_b:(True))))+AND+sxacontent_txm:(lifestyle~0.5))+AND+_latestversion:(True))+AND+((content_t:(*lifestyle*))^5+OR+(-_name:("")++_name:[*+TO+*])))+AND+((title_t:(*lifestyle*))^5+OR+(-_name:("")++_name:[*+TO+*])))+AND+_val_:__boost&start=0&fq=_indexname:(sitecore_sxa_dev_master_index)&sort=title_t+asc&rows=5&wt=xml&version=2.2} hits=3 status=0 QTime=17






Wednesday, September 15, 2021

Move Docker data to a different drive to save space from the c drive - Quick configuration.


Recently, while working on a project I found the space issue in C Drive and because of that, the docker container was getting shut down automatically.



Although the VM has good space in the d drive, I did the path change in the configuration and it basically saved my work.

How to make that change - We can directly do it from the docker UI settings option or can change the C:\ProgramData\Docker\config\daemon.json


Reference - https://github.com/docker/for-win/issues/185

Results in D Drive - 






Monday, September 13, 2021

Sitecore 10 - Fix for deleted child items remain in the web database.

While working on the current project (Sitecore 10) with SXA, We have noticed that when we deleted a child item of the composite component ( like an accordion).

We also raised the Sitecore ticket and came to know a few suggestions like 

Option 1 

You can modify the RemoveUnknownChildren processor in publishItem pipeline to always check for deleted item by removing this line:

if (!ShouldProcess(context))

{

return;

}

Note that this might incur higher overhead for the publishing process.

Option 2

If editing the code is not feasible, you can first publish the pages with "publish related items" and "publish subitems" settings to publish the media items and data source items. Next, you need to publish the page and the Data item under the Site with "publish subitems" setting only to remove the deleted item from target database.

Please try these workaround and let me know if you need further assistance. Thank you.

As this is a critical functionality, here is the fix for this issue.



Create a patch file -


<configuration xmlns:patch="http://www.sitecore.net/xmlconfig/">

    <sitecore>

        <pipelines>

            <publishItem help="Processors should derive from Sitecore.Publishing.Pipelines.PublishItem.PublishItemProcessor">

                    <processor type= "CustomSolution.Project.SitecoreFix_Sitecore.Publishing.Pipelines.PublishItem.RemoveUnknownChildren, CustomSolution.Project.SitecoreFix_Sitecore" patch:instead="processor[@type='Sitecore.Publishing.Pipelines.PublishItem.RemoveUnknownChildren, Sitecore.Kernel']"/>

                </publishItem>

        </pipelines>

    </sitecore>

</configuration>

 and add a class 

using Sitecore.Data;

using Sitecore.Data.Items;

using Sitecore.Diagnostics;

using Sitecore.Publishing;

using Sitecore.Publishing.Pipelines.Publish;

using Sitecore.Publishing.Pipelines.PublishItem;


namespace CustomSolution.Project.SitecoreFix_Sitecore.Publishing.Pipelines.PublishItem

{

    public class RemoveUnknownChildren : PublishItemProcessor

    {

        public override void Process(PublishItemContext context)

        {

            Assert.ArgumentNotNull(context, nameof(context));

            Assert.IsNotNull(context.PublishContext, "context.PublishContext");

            foreach (ID unknownChildId in context.PublishHelper.GetUnknownChildIds(context.ItemId))

            {

                PublishingCandidate publishingCandidate = new PublishingCandidate(unknownChildId, context.PublishOptions)

                {

                    PublishAction = PublishAction.DeleteTargetItem

                };

                Item obj = context.PublishOptions.TargetDatabase.GetItem(unknownChildId);

                if (obj != null)

                {

                    publishingCandidate.ItemName = obj.Name;

                    publishingCandidate.ItemUri = obj.Uri;

                }

                context.PublishContext.DeleteCandidates.Enqueue(publishingCandidate);

            }

        }

    }

}

that will fix the issue and will not see any pending deleted items in the web DB.

Monday, August 23, 2021

Sitecore Best Practices (V10.1) 009 - Scriban best practices

I think we need to make sure to add the proper object null handling while using the scriban, as an example below.


{{ if  i_item.propertyname != "" }}

{{ end }}

or, in case if you are using the custom Scriban extension or trying to read the object property

{{ if object!= null }}

or 

{{ if object }} 


Add the proper formatting for the scriban scripts so it is easy to read 



Sitecore Best Practices (V10.1) 008 - Apply Sitecore patches and fixes.

It's always good to apply the Sitecore patch in the correct way so this can be easily tracked(identified) that what all fixes/patches applied.

Although Sitecore has a good practice to include the patch (.txt) file in the Sitecore-->shell folder so we can see all the applied patches.

I usually prefer to apply the patch with the below approach.

1. Create the hotfix folder in the solution root. example src-->hotfixes--> here I would prefer to create the categories like if the fix is related to Sitecore core, SXA forms etc, so create the folder accordingly.

2. For the search folder(feature) as mentioned in point #1, create a separate solution under the project.


Example -