Ghanendra's Tips

  The SOLID principle was introduced by Robert C. Martin, also known as Uncle Bob and it is a coding standard in programming. This principle is an acronym of the five principles which is given below- Single Responsibility Principle (SRP) Open/Closed Principle Liskov’s Substitution Principle (LSP) Interface Segregation Principle (ISP) Dependency Inversion Principle (DIP) Single Responsibility Principle:  A class should have only one reason to change This  means every class should have a single responsibility or purpose. The class shall be updated only when a the behavior for this single responsibility changes. For E.g. If a class is responsible for login logic, then that is all it should do. Any other similar functionalities like Registration or Change Password should be implemented separately. As such, only when a change is required in Login logic will cause the class to be updated. If we keep updating a class for adding features which are not related to a single purpose, it makes the

Workflow implementation is important for content governance. When content author updates a page in Sitecore experience editor, Sitecore notifies content author to submit the page to push it to next workflow state.  But what about the rendering data sources present on the page. Do they get pushed to next workflow state or not?  Sitecore does push the rendering data source items present on page to next workflow state if you have the below setting set to true in your configs (which is true by default Sitecore 8.2 onwards) -  <setting name="WebEdit.AffectWorkflowForDatasourceItems" value="true" patch:source="Sitecore.ExperienceEditor.config"/> However, that's not all. Some of the rendering data sources may be dependent on other items (we will call them linked items), especially for container renderings (which act as container for other data items). There is no setting in Sitecore OOB that can push the linked items to next workflow state. Content auth

In this post, I am going to share a script which can help you find all the pages which contain a keyword in its content. This requirement came from the business team who wanted some insights about pages which use keywords like finance, commerce etc. One can easily get this information from search functionality on Sitecore site or client. Or one can always create a powershell script and generate a report that can be shared with business users (yes, they love reports). We had a few assumptions -  We looked for keyword only in Rich text fields. You can modify script to include more field types. We needed the page links rather than Sitecore content path as the business users were not familiar with Sitecore. Mostly, the keyword was present in content items placed within _content folder under the page. For such items, we preferred to resolve the URL to the page ancestor to the content item. For this, we checked if the item path contains _content . If yes, then we limited the URL to page ite

A code shall be easy to read and understand. In this post, I am outlining basic principles  about clean coding after researching through expert recommended books, trainings and based on my experience. A common example to start with is a variable declaration like - int i  The above statement did not clarify the purpose of variable i. However,  the same variable can be declared as -  int pageNumber The moment we declared the variable as int pageNumber, our brain realized that the variable is going to store the value for number of pages. We have set the context in our brain now and it is ready to understand what the code is going to do next with these page numbers. This is one of the basic advantages of clean coding. Reasons for clean coding -  • Reading clean code is easier - Every code is revisited after certain amount of time either by the same or different developer who created it. In both the cases, if the code is unclean, its difficult to understand and update it. • To avoid s