Ghanendra's Tips

EnableWorkflow attribute defines if the workflow support for the site is enabled or not. This is an important attribute in site definition if you want workflow to work correctly. If you miss this, you may create problems for content authors which we will discuss in the post.  The Problem While testing a customization in Sitecore workflow, we stumbled upon following issue -  Content authors created a page in Experience Editor and left the page in Draft mode expecting all the data source items they edited on page are also in Draft state. Then a nightly automatic publish published all draft data source items to the live servers. Why did this happen? The steps to replicate. Create a new page in Sitecore  Open Experience Editor and add a component that needs a data source.  Select 'create a new data source' in the popup window.  Save the page in experience editor  Open the data source in the Content editor and take a look at the workflow state section. It will be blank instead of ha

So  I was using Sitecore 8.2 and working on one of my development tickets. While committing my changes to source control, I observed,  for some reason,  created field value for TDS item was updated on my local instance (highlighted in snapshot). I knew this was not the Sitecore item created date field which is represented by __Created (also in snapshot). I looked around but didnt find  much information on what this field represents and why it was updated on my local.  So I started digging and also reached out to Sitecore support and below is the observation - Created field values are updated by Sitecore serialization. TDS doesn't directly update them, it uses the Serialization API to get the item and it is changed/updated by the API Created field is ignored by TDS for sync and compare. It was not present in older versions of Sitecore, therefore, we don't use it to maintain backward compatibility. Since it is ignored by TDS, there is not much information about the field, but it

Sometimes we  simply want to know in JS if the user is on regular site view or experience editor view or any other view. In JS, we can do this by below lines of code -  var isEditMode = function ( ) { return typeof Sitecore !== "undefined" && Sitecore && Sitecore.PageModes && Sitecore.PageModes.PageEditor; } var isPreviewMode = function ( ) { return typeof Sitecore !== "undefined" && !isEditMode() } var isNormalMode = function ( ) { return typeof Sitecore === "undefined" }

Validators that take a long time to run can have a negative performance impact while using the Sitecore Content Editor. This post is intended to look for those validation rules in question. Symptoms of Problem     Slow performance while using the Sitecore Content Editor How to Check Long Running Validation Rules   Long running validation rules appear in the Sitecore logs with the following message: Long running operation: Running Validation Rules. To search for these messages you can either search for the above string using your favorite text editor like Notepad++, or by parsing the log file(s) with Sitecore Log Analyzer tool. To parse the log file(s) using Sitecore Log Analyzer:  1. Launch Sitecore Log Analyzer.  2. Use Select Location button to select log file(s) for parsing.  3. Set String filter field to Long running operation: Running Validation Rules value.  4. Press Analyze / Refresh* button.  5. Go to Messages tab and check Warnings checkbox.  6. Check the checkbox of the “* Lo

Hi, So our content authors and testers started reporting that they are getting more and more Page Unresponsive Error dialog appear while working on CM server. They also reported that there were often long waits during edit and save operations. So, I started investigating this and jumped into Sitecore logs to dig out the root cause. I had interesting observations - Created pages in Experience editor and did not encounter any issues during normal editing actions. Created a copy of medium sized folder in site (e.g. /sitecore/content/<SiteName>/<Test Folder Path> and recycled it later. On both the actions, Page Unresponsive error was reproducible and all subsequent requests from Sitecore client kept waiting. This confirmed a large copy/delete/publish operation consumes most of the resources available for SQL operations and other users get blocked. Analyzed the logs for last few weeks and found that the following activities happened a

High performance for any digital platform is elementary. In this post, I will address some basics around Sitecore caching and some best practices that Sitecore developers/architects can follow to boost the performance of Sitecore solution. While working with one of our clients, content authors started complaining about the page load time in experience editor. The environment was Azure IaaS. So, we started looking at all the performance tweaks we could apply. Sitecore Cache Tuning Performance and cache go hand-in-hand :D  So first thing we wanted to explore was Sitecore caching especially the cache sizes.  I assume the readers are already aware about Sitecore caches and  how to configure them . We used the showconfig.aspx (https://<my sitecore hostname>/sitecore/admin/showconfig.aspx ) and looked especially for Sitecore's prefetch, items and data cache sizes. So, how do we  know if the cache sizes are sufficient for our application? First, you need to open Cache Administration

  We have lots of media items and our business wants to copy the data from en version of media item to all other language versions defined in System/Languages. This ensures that media is available in all the languages. So, we created the below powershell script to achieve the same -  #Get all language versions defined in System/Languages $languages = Get-ChildItem /sitecore/System/Languages -recurse | Select $_.name | Where-Object {$_.name -ne "en"} | Select Name #Ensuring correct items are updated by comparing the template ID  $items = Get-ChildItem -Path "/sitecore/media library/MyProjects" -Recurse | Where-Object {'<media item template id>' -contains $_.TemplateID} #Bulk update context to improve performance New-UsingBlock (New-Object Sitecore.Data.BulkUpdateContext) { foreach($item in $items){    foreach($language in $languages){ $languageVersion = Get-Item -Path $item.Paths.Path -Language $language.Name #Check if language versi