Friday, July 28, 2017

Glass Surprise - Get Your Ancestors like a champ

Glass just makes me so happy!  I do not have to write same 10-15 lines of code every time to do something very mundane when it comes to Sitecore.  Every other feature on sitecore demands some kind of relationship driven items to be accessible from context page on which your module would do some magic on.
Typically, developers tend to write their own custom code to do such things which would lead to bad performance when not done right.  Why not just go with Glass if you are using it in your instance development? It is far more easier.  I had done a similar blog post to grab children from Glass, but, this time around it is Ancestors.  Though similar, it could help some one who did not think or know that it could be used on both the relation ships on the tree, upwards or downwards.

Steps to do this is quite simple and three step process

  1.  Declare a custom partial class that extends your auto generated class based on say a template.  For example like below.  I like to keep these guys organized, usually do it in special Model project and namespace related to it, to keep things easy and manageable, so some one can easily know if the model has been extended. 
  2. Next up, add a Attribute that comes with Glass such as below, pass your template ID.  I actually tried getting this ID from a config setting which would have been great for maintenance, see if you can do that based on your project settings 
  3. Access the new ancestor strongly typed( A bonus, so you dont need to cast and make a messy view, the view simply get's what it needs and you access and ensure your checks are in place)

Sample Code Of Custom Partial Class 


namespace YourProject.Models
{
    public partial class Your_Template_Auto_Generated_Class
    {

        [SitecoreQuery("./ancestor-or-self::*[@@templateid='{7E6BC980-362C-4BBB-97E5-9DAA83B70812}']", IsRelative = true)]        
        public virtual Your_Strongly_Typed_class myAncerstorItem { get; set; }
    }
}


Voila! Goal accomplished and the best part clean code, clean views and happy MVC. 

Have a great weekend ahead!!!

Tuesday, July 25, 2017

Custom Sorting on Coveo Facet

I got to use a new feature of Coveo today because of new requirements.  How fun, though the request that came through felt not needed and a corner case in terms of user experience.  Pushing through limit is what we have to do if you have got super picky clients. :)
The outcome is always precious as you get to learn something new.   Here is the snapshot of what happened and how we were able to get it working per request and requirement.

Goal - Regardless of selections made on Coveo Facet because of url appending, the sort order of values available on facet stay per the field on which sort is based on.

Problem - The inherent default behavior of Coveo for better UX experience.  To be honest, I actually like what they have in terms of grouping the values selected to the top and rest are sorted based on the sort field set up.  But, we have to some how overwrite this default behavior.

Firstly, our front end contact explored why this happens and how coveo groups them the way it does inherently.  The reason for special attention that these selected values get is because of the below. Thanks to our front end resource to find this out.  Though we did not pursue anything in modifying this, it is always good to know the reasons behind how it is currently done.

https://developers.coveo.com/display/public/SearchREST/Group+By+Results






So, the reason is that when there is an appending in URL for a selection of a value or set of values in the facet, Coveo inherently tags these as Desired and hence the special treatment for those to be on the top.

For example, if your URL is like below may be because the user clicked on back button post user selected few values and moved on his journey, the user could land on pages like this or if marketing team linked off the user to a page with pre-selected values on a facet.  There could be more scenarios where your user would bump in to this situation, but to name a few.

Example URL - https://www.domain.com/press-releases-events-and-webcasts-landing#f:articlePostYear=[2017,2018]

The selected would be grouped on top like below due to the above explained reason.


 Again, I like what Coveo does inherently and I suspect that this needs to overridden in simple cases, but, if you absolutely need to do this? Which is where we stood, I logged a Q and A below and luckily got a direction.  I only wish there were more graceful options, but, we took what we got as well, we had to overwrite this and there was no other option unfortunately.

If you are curious, follow the discussion here and I will explain more in detail how I actually implemented what was recommended by Coveo team.

https://answers.coveo.com/questions/12071/facet-values-mentionedgrabbed-in-allowed-values-be.html?childToView=12086#answer-12086

Steps I did to Implement this solution:


  1. Created a copy of default Coveo MVC view for facet and named it differently and placed under correct project specific location. 
  2. Add the below line to the view created just above end of div tag in place for the facet
    data-custom-sort="2024,2023,2022,2021,2020,2019,2018,2017,2016,2015,2014">
  3. Note - With addition of this, we should be good on sorting with lower limit of 2014 to upper limit of 2014, based on your project data you could decide on good numbers for these limits. Only deal is post 2024, if this project has same implementation, we will need a code deploy to ensure sort works as expected. 
  4. Use this new view item on presentation for the facet and select all appropriate values that a coveo facet would need on the templates affected or will use such type of facet  
  5. That is it!! Post this change regardless if values are selected via url or not, the ordering will be based on data-custom-sort 






Sunday, July 9, 2017

Sitecore Launch Hiccups and Resolution

I know it has been a while, Vacationing and launch has been no joke on my side. :)
It has surely taken a toll and kept me away from blogging for quite a few days.  Finally, today I got some time to jot down the experiences of my launch after a pause.

Time Taken: 14 hrs straight starting 5.00 PM to Mid night around 2.00 AM PST, it was a grueling long night and I was supporting the go-live from India, how fun!

Sadly, I did not expect any issues or what so ever because we had code already up and running on the actual servers with all the things working and QA/UAT pass.  The only thing that was changing was DNS and binding being different, rest everything was absolutely same.  Well, everything does not happen as planned especially on the launch day.   I was supporting using a fairly fast internet for Indian standards, but, still fell a little short as I was used to things being done fast.

Below are few hiccups and how we resolved each of these, hope it helps some one who is stuck in a similar situation.


  1. xDB Cloud working excellent on sandbox license, but, lot of issues when swapped to prod license.    While launching the site, we obviously have to swap the connection strings to use production xDB license provided by sitecore.  We did so, but, as a surprise we encountered bunch of errors on logs and had to re-visit all the related configs to ensure we did everything as expected.  Sitecore did not mention in support ticket that extra steps would be needed on live license which are additional as compared to non-prod xDB license.  We followed the below blog and added host file entry as mentioned and left hostname empty on configuration. https://sitecorehacker.com/2017/02/12/sitecore-analytics-tracker-common-issues-and-how-to-resolve-them/
  2. IIS security hardening done prior to enabling anonymous access to the site.  It is kind of common practice that when we have a pre-prod or staging site behind some kind of authentication to ensure site is not publicly available since it is meant to be.  As part of deployment strategy, we had steps listed and unfortunately they were ordered incorrectly.  Since, enabling anonymous on parent site would trigger that change to all children and folders within the site, the hardening we had done per sitecore recommendations on CD servers was lost and we had to re-do the steps.  These things add time post launch especially on VPN, connected to remote servers from INDIA. lol
  3. Coveo cache - Still unsure what was causing Coveo to access a URL that is no longer configured on either Server URL or for that matter any where else.  While rebuilding master index, it kept failing saying that could not reach to a binding which is no longer available.  I am assuming it is some kind of cache, unsure where or what at this time.  I ensured there was no trace of old/outdated URL any where by going to /showconfig.aspx and also reviewing coveo configuration files.  Still a mystery to solve, but fortunately the error did not mean indexes were not built, so, we were safe to move forward and were successfully able to rebuild other web and liveweb indexes with out errors. 
  4. Cache - It is a boon and blessing.  We had set up cache on all renderings applicable.  But, there was a slight miss.  Parent placeholders that carried WFFM should not be allowed to cache, but, there were few misses which were uncovered only on regression testing that few forms were not working, once we removed cacheable setting on these renderings forms started working like a charm. 
  5. Errors on Log files -  It is important to monitor log files to check for any major errors on the logs that clutter the server and could have slow response times.  We un-covered a few and still in progress on identifying all the outstanding issues. 
  6. Redirects -  On our lower environments we had few different settings like www was being forced as it was not needed which was enabled post launch as a requirement.  This started throwing off the logic and plan around redirects.  We had to revamp the redirects loaded to ensure they are working alright and corrected few instances.  Especially when migrating or unifying multiple sites this could pose a challenge.  How I wish we had exact same settings and tested the logic against that to reduce this back and forth. 
At the end, all was well.  I am glad we stretched it instead of calling it off, it is a worst feeling to do a rollback.  Launch would mean a great move in the forward direction, never would want to associate it with a failure.  I am glad the site went live and has been appreciated both internally and public facing. 

Looking forward to more adventures in the future.   

Happy Weekend every one!