LinkProvider is now Obsolete!

Sitecore’s LinkProvider is used to generate urls of items.  

There are several scenarios where one might need to override Sitecore’s link provider.  

In our project, we had this particular item type – Guide Articles – which the client specifically said would only be PDF files as opposed to being pages. But, they did want these to show up in search results like all other pages, linked through to the downloadable media item only. 

There were also multiple components on the site, which were linked to these Guide Articles, where they always wanted the corresponding link to be of the associated media item. 

While working on this requirement, it was also determined that the client might, at a later date, want to convert these to pages. 

This is one of the scenarios where, overriding Sitecore’s default LinkProvider would seem most beneficial. We would only update the way links are generated for items of this Guide Article type, and we wouldn’t need to make any special accommodations in any other component, or even the search feature. 

Additionally, flipping the switch when Guide Articles were to be updated to pages, would require minimal effort – and would simply involve turning off the LinkProvider override. 

This was on Sitecore 9.3, and when we tried overriding the LinkProvider, we noticed that it was marked obsolete: 

On digging around a bit, the solution was to override the itemUrlBuilder instead. 

using Sitecore.Data.Items; 
using Sitecore.Links.UrlBuilders; 
using Sitecore.Resources.Media; 
 
namespace MySite.Foundation.Search.Links 
{ 
    public class MySiteItemUrlBuilder : ItemUrlBuilder 
    { 
        public MySiteItemUrlBuilder(DefaultItemUrlBuilderOptions defaultOptions) : base(defaultOptions) 
        { 
        } 
 
        public override string Build(Item item, ItemUrlBuilderOptions options) 
        { 
            // Code to override link generation of items which use Guide Article Template 
            if (item.TemplateID.ToString() == Constants.Templates.GuideArticle) 
            { 
                // Fetch the associated media item 
                Sitecore.Data.Fields.FileField fileField  
                    = item.Fields[Constants.Fields.GuideArticlePdf]; 
                Item file = fileField.MediaItem; 
 
                if (file != null) 
                { 
                    MediaItem media = new MediaItem(file); 
 
                    // Return the url of the associated media 
                    return MediaManager.GetMediaUrl(media); 
                } 
 
                // If the media item was not found - we still don't want to return the url  
                // of the item - since it is non navigable 
                return "#"; 
            } 
 
            // For items using any other template, use default url builder logic. 
            return base.Build(item, options); 
        } 
    } 
}

The configuration patch that goes with this: 

Just a small note to wrap this scenario up – since we had Guide Articles within the home node, we set the presentation in the standard values – to use a component that simply redirected the user to the home page. Even though this would ideally not be used, since links to the page would not be rendered any place due to the link provider override, it seemed like a good idea just to cover all bases.  

<?xml version="1.0" encoding="utf-8" ?> 
<configuration xmlns:patch="http://www.sitecore.net/xmlconfig/" xmlns:role="http://www.sitecore.net/xmlconfig/role/" xmlns:search="http://www.sitecore.net/xmlconfig/search/"> 
  <sitecore role:require="Standalone or ContentManagement or ContentDelivery" search:require="solr"> 
    <links> 
      <itemUrlBuilder> 
        <patch:attribute name="type">MySite.Foundation.Search.Links.MySiteItemUrlBuilder, MySite.Foundation.Search</patch:attribute> 
      </itemUrlBuilder> 
    </links> 
  </sitecore> 
</configuration> 

Just a small note to wrap this scenario up – since we had Guide Articles within the home node, we set the presentation in the standard values – to use a component that simply redirected the user to the home page. Even though this would ideally not be used, since links to the page would not be rendered any place due to the link provider override, it seemed like a good idea just to cover all bases.  

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s