Register Custom ASP.NET MVC Routes in Sitecore

Sitecore allows custom ASP.NET MVC routes to be used on a Sitecore site.

However, improper adding of such routes may lead to different problems with using Sitecore Client, such as broken dialogues, non-functioning buttons, etc.

For example, this may be the result of defining custom routes in the Global.asax file, causing conflicts with a number of default routes defined by Sitecore and used for Sitecore Client functionality.

You can also find more information about ASP.NET Routing in the following article:
https://msdn.microsoft.com/en-us/library/cc668201.aspx

Follow the steps below to define custom ASP.NET MVC routes in a way that does not conflict with the default Sitecore routes.

Create a custom processor for the initialize pipeline and define a custom route in the Process method similar to the following:

public class RegisterCustomRoute

{

  public virtual void Process(PipelineArgs args)

  {

    RouteTable.Routes.MapRoute("CustomRoute", "some/route/{controller}/{action}/{id}");

  }

}

Add this processor to the initialize pipeline right before the Sitecore InitializeRoutes processor. You can do this with the help of the configuration patch file in the following way:

<?xml version="1.0" encoding="utf-8"?>

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

     <sitecore>

          <pipelines>

               <initialize>

                    <processor type="MyNamespace.RegisterCustomRoute, MyAssembly" patch:before="processor[@type='Sitecore.Mvc.Pipelines.Loader.InitializeRoutes, Sitecore.Mvc']" />

               </initialize>

          </pipelines>

     </sitecore>

</configuration>

Important: ensure your custom configuration patch file is applied as the last patch to Sitecore configuration.
You can do this by placing the patch file into a subfolder of the /App_Config/Include directory. The name of the subfolder must be the last one alphabetically related to other subfolders (such as Z_CustomConfigs).

Implementation of Dependency Injection in C#.

What is Dependency Injection?

Dependency Injection (DI) is a software design pattern that allows us to develop loosely coupled code. DI is a great way to reduce tight coupling between software components. DI also enables us to better manage future changes and other complexity in our software. The purpose of DI is to make code maintainable.

For example, Suppose your Client class needs to use two service classes, then the best you can do is to make you Client class aware of abstraction i.e. IService interface rather than implementation i.e. Service1 and Service2 classes. In this way, you can change the implementation of the IService interface at any time (and for how many times you want) without changing the client class code.

We have the following different ways to implement DI :

Constructor Injection

• This is a widely used way to implement DI.
• Dependency Injection is done by supplying the DEPENDENCY through the class’s constructor when creating the instance of that class.
• The injected component can be used anywhere within the class.
• Recommended using when the injected dependency, you are using across the class methods.
• It addresses the most common scenario where a class requires one or more dependencies.

public interface IService {

 void Serve();

}

public class Service1 : IService {

 public void Serve() { Console.WriteLine("Service1 Called"); }

}

public class Service2 : IService {

 public void Serve() { Console.WriteLine("Service2 Called"); }

}

public class Client {

 private IService _service;

 public Client(IService service) {

 this._service = service;

 }

 public ServeMethod() { this._service.Serve(); }

}

class Program

{

 static void Main(string[] args)

 {

 //creating object

 Service1 s1 = new Service1(); 

 //passing dependency

 Client c1 = new Client(s1);

 //TO DO:

 Service2 s2 = new Service2(); 

 //passing dependency

 c1 = new Client(s2);

 //TO DO:

 }

}

The Injection happens in the constructor, bypassing the Service that implements the IService Interface. The dependencies are assembled by a "Builder" and Builder responsibilities are as follows:

• Knowing the types of each IService
• According to the request, feed the abstract IService to the Client

Property/Setter Injection

• Recommended using when a class has optional dependencies, or where the implementations may need to be swapped.
• Different logger implementations could be used in this way.
• Does not require the creation of a new object or modifying the existing one. Without changing the object state, it could work.

public interface IService {

 void Serve();

}

public class Service1 : IService {

 public void Serve() { Console.WriteLine("Service1 Called"); }

}

public class Service2 : IService {

 public void Serve() { Console.WriteLine("Service2 Called"); }

}

public class Client {

 private IService _service;

 public IService Service {

 set { this._service = value; }

 }

 public ServeMethod() { this._service.Serve(); }

}

class Program

{

 static void Main(string[] args)

 {

 //creating object

 Service1 s1 = new Service1(); 

 Client client = new Client();

 client.Service = s1; //passing dependency

 //TO DO:

 Service2 s2 = new Service2(); 

 client.Service = s2; //passing dependency

 //TO DO:

 }

}

Method Injection

• Inject the dependency into a single method and generally for the use of that method.
• It could be useful, where the whole class does not need the dependency, only one method having that dependency.
• This is the way is rarely used.

public interface IService {

 void Serve();

}

public class Service1 : IService {

 public void Serve() { Console.WriteLine("Service1 Called"); }

}

public class Service2 : IService {

 public void Serve() { Console.WriteLine("Service2 Called"); }

}

public class Client {

 private IService _service;

 public void Start(IService service) {

 service.Serve();

 }

}

class Program

{

 static void Main(string[] args)

 {

 //creating object

 Service1 s1 = new Service1(); 

 Client client = new Client(); 

 client.Start(s1); //passing dependency

 //TO DO:

 Service2 s2 = new Service2(); 

 client.Start(s2); //passing dependency

 }

}

Advantages of Dependency Injection

• Reduces class coupling
• Increases code reusability
• Improves code maintainability
• Make unit testing possible

If you want to implement DI within your ASP.NET MVC application using DI container, please does refer Dependency Injection in ASP.NET MVC5 using Unity IoC Container.

Dependency Injection in ASP.Net MVC5 using Unity Ioc Container.

Please does refer to Implementation of Dependency Injection in C#.

What is Inversion of Control?

Inversion of Control (IoC) refers to a programming style where a framework controls the program flow with the help of Dependency Injection.

The term Inversion of Control (IoC) refers to a programming style where the flow of a program has been inverted i.e. changed from the normal way. As you have done in the example of Class A and Class B. Here, dependencies are instantiated by a framework or runtime and supplied to the desired class as needed.

Step 1: Create a new ASP.NET MVC Application

Step 2: Install Unity Container

Right click on the project and click on Manage NuGet Packages and search for Unity.mvc5. Click to install Unity. mvc5 package in ASP.NET MVC application.

Note

Make sure you are connected with internet.

When it will be installed successfully, you will find the following two references add to your project and UnityConfig.cs file in App_Start Folder at a project level, as shown below:

Step 3: Register all your components with the container as in the following screenshot;

public static class UnityConfig

    {

        public static void RegisterComponents()

        {

var container = new UnityContainer();

            // register all your components with the container here

            // it is NOT necessary to register your controllers

            // e.g. container.RegisterType<ITestService, TestService>();

            container.RegisterType<IRepositry, Repositry>();

            DependencyResolver.SetResolver(new UnityDependencyResolver(container));

        }

    }

Step 4: Add a new Folder in the project of the name Repository and add the following interface and a class in this folder:

//IRepositry.cs

public interface IRepositry

    {

        string GetName();

    }

//Repositry.cs

public class Repositry: IRepositry

    {

        public string GetName()

        {

            return "Vikash Sah";

        }

    }

Step 5: After this register UnityConfig in Global.asax,

Step 6: Finally, use it in your MVC Controller,

Add Publishing Targets in Sitecore 9.1

You are usually adding new publishing targets in Sitecore because of different geographic regions or databases in different data centers where you are hosting these web databases.

For a long time, for Sitecore 8, the process for creating a new publishing target was more or less the same. You have created a new entry in ConnectionStrings.config, added new <database> entry in web.config and added new definition item in master database under “/sitecore/system/Publishing targets” node.

In Sitecore 9 process has been slightly changed. You are not changing web.config anymore but Sitecore.config and 2 additional steps are now involved for adding a new publishing target. These two more steps are adding <eventQueue> and </PropertyStoreProvider> elements in Sitecore.config.

In my example below, I will use “Pub” as the name of the publishing target database. I will use “QA” as the name of the publishing target. In my example below, I will use “Pub” as the name of the publishing target database. I will use “QA” as the name of publishing target.

Steps to add new publishing target in Sitecore 9:Steps to add new publishing target in Sitecore 9:

1. Create new target database in ConnectionStrings.config where you want content to be published:
   
   <add name="Pub" connectionString="Data Source=.\;Initial Catalog=webdbname;User ID=pubuser;Password=Password" />
2. Add new entry in master database under “/sitecore/system/Publishing targets” node.
   
   
   
   
   
   
   
3. Create a patch file under C:\inetpub\wwwroot\instancename\App_Config\Include\Project\ or any other folder based on your setup. I have named my patch config file “PublishingTargets.config” and this is it’s content (you can just copy it and change web_secondary based on name of your secondary web database specified in ConnectionStrings.config):

<?xml version="1.0" encoding="utf-8"?>
<configuration xmlns:patch="http://www.sitecore.net/xmlconfig/">
     <sitecore>
         <eventing defaultProvider="sitecore">
            <eventQueueProvider defaultEventQueue="core">
                <eventQueue name="Pub" patch:after="eventQueue[@name='web']" type="Sitecore.Data.Eventing.$(database)EventQueue, Sitecore.Kernel">
                     <param ref="dataApis/dataApi[@name='$(database)']" param1="$(name)" />
                     <param hint="" ref="PropertyStoreProvider/store[@name='$(name)']" />
                </eventQueue>
            </eventQueueProvider>
         </eventing>
         <PropertyStoreProvider defaultStore="core">
             <store name="Pub" patch:after="store[@name='web']" prefix="Pub" getValueWithoutPrefix="true" singleInstance="true" type="Sitecore.Data.Properties.$(database)PropertyStore, Sitecore.Kernel">
                  <param ref="dataApis/dataApi[@name='$(database)']" param1="$(name)" />
                  <param resolve="true" type="Sitecore.Abstractions.BaseEventManager, Sitecore.Kernel" />
                  <param resolve="true" type="Sitecore.Abstractions.BaseCacheManager, Sitecore.Kernel" />
             </store>
         </PropertyStoreProvider>
         <databases>
         <!-- Pub -->
             <database id="Pub" patch:after="database[@id='web']" singleInstance="true" type="Sitecore.Data.DefaultDatabase, Sitecore.Kernel">
                 <param desc="name">$(id)</param>
                 <icon>Images/database_web.png</icon>
                 <securityEnabled>true</securityEnabled>
                 <dataProviders hint="list:AddDataProvider">
                     <dataProvider ref="dataProviders/main" param1="$(id)">
                         <disableGroup>publishing</disableGroup>
                         <prefetch hint="raw:AddPrefetch">
                              <sc.include file="/App_Config/Prefetch/Common.config" />
                              <sc.include file="/App_Config/Prefetch/Webdb.config" />
                         </prefetch>
                     </dataProvider>
                 </dataProviders>
                <PropertyStore ref="PropertyStoreProvider/store[@name='$(id)']" />
                    <remoteEvents.EventQueue>
                        <obj ref="eventing/eventQueueProvider/eventQueue[@name='$(id)']" />
                    </remoteEvents.EventQueue>
                    <archives hint="raw:AddArchive">
                        <archive name="archive" />
                        <archive name="recyclebin" />
                    </archives>
                    <cacheSizes hint="setting">
                         <data>100MB</data>
                         <items>50MB</items>
                         <paths>2500KB</paths>
                         <itempaths>50MB</itempaths>
                         <standardValues>2500KB</standardValues>
                    </cacheSizes>
              </database>
         </databases>
     </sitecore>
</configuration>


After applying these changes, you can see now pretty new publishing target in publishing dialogue in Sitecore 9:

Check SiteCore Items Publish or Not using GutterRender

What is Gutter in Sitecore?

Gutter also is known as a quick action bar, can be seen when you right click on the left bar of the content tree.

Sitecore provides default gutters to know the

• Item buckets
• Cloned Items
• Personalizations
• Multivariant Tests
• My Locked Items
• Locked items
• Workflow state
• Broken links
• Missing Version
• Publishing Warnings
• Validation Rules
• Presentation overridden

In addition to these default Gutters, we can create custom Sitecore Gutters.

Steps to Create Custom Sitecore Gutter

1. Create a class which inherits the GutterRenderer.
2. Override the GutterIconDescriptor method in the GutterRenderer class, to set the appropriate icons to the gutter.
3. Switch to core database in Sitecore interface.
4. Create Custom Gutter using the /Sitecore/templates/Sitecore Client/Content editor/Gutter Renderer.
5. Populate the Header and Type fields of the Gutter, Header field should contain the name you want to give to the Gutter, Type field should contain the fully qualified class name, the dll which contains the class.
   
   
   
   
   
6. Right click on the left side of the Content tree and select your Gutter. see below screen 
   
   
   
   
   
7. The Gutter now indicates the publication status of your items
   
   
   

CUSTOM SITECORE GUTTER TO INDICATE PUBLISH STATUS

Never Published:
Check whether the item is present in the web database if not implies the item has never been published.

Published:
Compare the revision fields of the item in master and web databases, if found same implies that the latest revision has been published to the web.

Published to at least one target:
Check whether the item is present in any one target database if found implies the item has been published in at least on the target database.

Code & Implementation

namespace testforsitecore.Models

{

    public class PublicationStatus : GutterRenderer

    {

        private readonly ID publishingTargetsFolderId = new ID("{D9E44555-02A6-407A-B4FC-96B9026CAADD}");

        private readonly ID targetDatabaseFieldId = new ID("{39ECFD90-55D2-49D8-B513-99D15573DE41}");

        protected override GutterIconDescriptor GetIconDescriptor(Item item)

        {

            bool existsInAll = true;

            bool existsInOne = false;

            // Find the publishing targets item folder

            Item publishingTargetsFolder = Context.ContentDatabase.GetItem(publishingTargetsFolderId);

            if (publishingTargetsFolder == null)

            {

                return null;

            }

            // Retrieve the publishing targets database names

            List<string> publishingTargetsDatabases = publishingTargetsFolder.GetChildren()

              .Select(x => x[targetDatabaseFieldId])

              .ToList();

            // Check for item existance in publishing targets

            publishingTargetsDatabases.ForEach(delegate (string databaseName)

            {

                if (Database.GetDatabase(databaseName).GetItem(item.ID) != null)

                {

                    existsInOne = true;

                }

                else

                {

                    existsInAll = false;

                }

            });

            // Return descriptor with tooltip and icon

            string tooltip = Translate.Text("This item has not yet been published");

            string icon = "People/16x16/flag_red.png";

            if (existsInAll)

            {

                tooltip = Translate.Text("This item has been published to all targets");

                icon = "People/16x16/flag_green.png";

            }

            else if (existsInOne)

            {

                tooltip = Translate.Text("This item has been published to at least one target");

                icon = "People/16x16/flag_yellow.png";

            }

            return new GutterIconDescriptor()

            {

                Icon = icon,

                Tooltip = tooltip,

                //Click = string.Format("item:publish(id={0})", item.ID), // For Click on publish staus icon publish Item dialog box open

                Click = String.Format("item:load(ID={0})", item.ID)  // For Click on publish staus icon which Item is load

            };

        }

    }

  }

Conclusion:

Sitecore Gutters can be very useful since they visually indicate the state of an item which reduces the extra effort for developers. The above implementation of Sitecore Gutter to indicate the Publish Status of an item comes handy when there is no workflow configured for the items.

Check Sitecore Items has ALIASES or Not using GutterRender

How to hide the "publish subitems" option in the publish dialog box.

When publishing the item given two option "Publish subitem" or "publish related items". When checkbox checked these option then publish item of the subitems or related items are published. If you want to hide these options then follow the below steps.

Hide the Publish SubItem option in the publish dialog box.

Steps:

1. Copy Publish.xml file from "sitecore\shell\Applications\Dialogs\Publish" folder to "sitecore\shell\override" folder, so that you don’t mess up original file in case if you want to revert back your changes, just delete the newly copied file of "sitecore\shell\override" folder.
2. Find XML code for control in Publish.xml file, something similar to below:
   
   
   <Border ID="PublishChildrenPane">
                 <br /><Checkbox ID="PublishChildren" Header="Publish subitems"/>
                  <br />
                  <Checkbox ID="PublishRelatedItems" Header="Publish related items"/>
    </Border>
3. Add Visible = "False" attribute to border control like below: e.g.
   
   
             <Border ID="PublishChildrenPane" Visible = "False">
                        <br /><Checkbox ID="PublishChildren" Header="Publish subitems"/>
                         <br />
                          <Checkbox ID="PublishRelatedItems" Header="Publish related items"/>
             </Border>
4. For default checked or unchecked you can add attribute IsChecked = "True" to the checkbox
   
   <Border ID="PublishChildrenPane" Visible = "False">
    <br />
   <Checkbox ID="PublishChildren" Header="Publish subitems" IsChecked = "True"/
      <br />
   <Checkbox ID="PublishRelatedItems" Header="Publish related items"/>
   </Border>
5. Now you see the dilog box like this. No have to option to checked  "publish subitems"  or  "Publish related items".
   
   
   
   
   
   
   
   
   

   
   

   
   

How to Manage Desktop Shortcuts in Sitecore CMS

Creating a Shortcut

To create a shortcut, right-click on the desktop and select “Create Shortcut”.

In the “Link” section that opens, click the “Browse” button.

This will open the “Insert Item”.

Select the desired item in the content tree and click the “Insert” button to return to the “Link” section.

Be sure to give the shortcut a name (HomeData), and custom icon to make it recognizable.

When finished, click “OK” to create the new shortcut.

Editing a Shortcut

To edit an existing shortcut, right click on the shortcut and select “Properties”.

This will reopen the “Link” modal.

Make any necessary changes to the shortcut and click “OK” when finished.

For Example, name: HomeContent.

Deleting a Shortcut

To delete an existing shortcut, right click on the shortcut and select “Remove Shortcut”.

A confirmation dialogue will appear. Click “OK” to delete the shortcut.

Desktop image change.

Scenario 1: 

Right-click on the desktop and select "Properties".

Select Background which is you want and clicks on the "Apply" button.

Scenario 2 :

Go to control panel and click on "Change desktop background" in  "MY SETTINGS" section.

Select Background which is you want and clicks on the "Apply" button.