Ghanendra's Tips

Is a newly launched car's astonishing features tempting you to buy a new car or upgrade your existing one?  Or are you thinking of purchasing a new car for your growing family needs?? If yes, welcome to jungle ruled by dealers and car manufacturers. They are fully geared up to trick you in making a purchase which will benefit them most. Not convinced? Make a visit to a nearby car dealer and get astonished by their courtesy and numerous suggestions (over a machine made cup of coffee) as if they are your best friends. Soon enough you will know that all the discussions and showroom visits lead you only into a world of confusions!! Believe me, you are not alone. Every car enthusiast has gone through same and all wish if there was a checklist they can use to decide what's best for them. No doubt, I too have stumbled here and there to get good advice. Based on my research over years and after going through hundreds of car reviews and expert suggestions, I have came up with a list of

Dianoga is an automatic image optimizer for the Sitecore media library. It reduces the size of your images served from Sitecore by 8-70% automatically.  Dianoga is great for situations where content editors may not be image editing experts. How Dianoga works? By default, Dianoga runs asynchronously after the image is saved into the media cache. This means it has practically no effect on the site's frontend performance (though it does use some CPU time in the background). Dianoga updates the cache after the first image request. This means the first hit to images will serve the unoptimized version of image. Subsequent requests will receive the optimized version from cache. Where is the problem? Dianoga's behavior of serving unoptimized images on first request creates problem while using CDNs. CDNs cache the responses of media requests. Since first hit to images serve unoptimized image, CDN will cache the unoptimized version. CDN will serve this unoptimized version of image in it

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