SITECOREing

One of the most common issues that arise on load balanced content delivery servers, is that there is a problem only with one of the servers. But troubleshooting this should be easy if you follow one (or in my case, all) of the following three options. 1. Set Http response headers for each content delivery server Within IIS, at the root server node, choose "HTTP Response Headers". From Actions, add a unique value for each of your servers. For example Name      Value x-s            01 x-s            02 x-s            03 Now when you bring up your webpage, you can go to Chrome developer tools and find the x-s value in the response headers section as shown in the image below 2. Add the below line (above the </body> tag) to your default layout (master page) so that all pages on your website inherit it. <!-- Server MachineName = @HttpContext.Current.Server.Ma...

There are times when you need to debug your Sitecore codebase and find out what part of the code is taking the most time and troubleshoot page load times. One of the most useful methods is to load the following page (after you have logged into Sitecore) http://{YourWebsite}/?sc_mode=normal&sc_debug=1&sc_trace=1&sc_prof=1&sc_ri=1&sc_rb=1 sc_mode – don't load the experience editor sc_debug - turn on the debug mode sc_trace - turn on Sitecore trace sc_prof - turn on Sitecore profiler sc_ri - show rendering information sc_rb - show rendering borders Next scroll down to the bottom of your page and you should see something similar to this image It should show you where the most time is spent. The next step would be to identify the section of your code base that is taking the most time and drill down to more specifics. To find out exactly how long a particular section of code takes, add the following: Sitecore.Diagnostics.Profiler.StartOperation(...

Sitecore has extensive cache settings. You can add caching at the rendering level so it affects all instances of that rendering. Or you can add caching at the component level on a particular page via the presentation details. This is all good when you are setting it up, but once this goes to production, the way caching is supposed to work is that the cache should get cleared after an item is published. So after an item is published, any associated cache should also automatically get updated. In our case, we saw that once we went to production (with extensive caching enabled) our pages loaded much faster. However when the content authors were updating content, the updates were not making it to the delivery servers. The content seemed to be stuck in the cache. We noticed that we had to do one of the following to see the updated cache. Go to the admin cache page [SitecoreSite/sitecore/admin/Cache.aspx] and click the "Clear all" button. This is not viable long term solution ...

I had a deployment today and wanted to find a list of users who were logged into the Sitecore admin site. This was mainly so that I can contact them and let them know that a deployment was going to happen. I found the following link very useful as it gave me exactly what I was looking for. A list of users that were logged in and I contacted them. It also has the ability to Kick off users! http://{YourWebsite}/sitecore/client/Applications/LicenseOptions/KickUser Note: You can only see other users in this list if you have the right administrator permission. Logging in with a lower access level user only gave me the logged in user and no one else on the list.

On your Sitecore site what is the media file extension you see? If you see .ashx for all your media (images, pdfs) read on. Ideally the IIS application pool for your website should be configured to use Integrated mode instead of classic mode. If that is the case, there is one default Sitecore 8 setting that you should change in your Sitecore.config   FROM: TO: This configures Sitecore to use the original file extensions rather than .ashx extension. So images would be jpg, gif, png's while pdfs would have the pdf extension. I also notice that Sitecore themselves have this configured on their website, so we should be good making this change. There are multiple benefits to the end user. They know the file types of media like pdfs before clicking on the download link CDN have cache settings that will be honoured for the respective file types Local browser cache setting will also work better Pages just load faster! Make this change and Happy Sitecoreing!

I was getting the following error when try to re-index Coveo in a new environment. The parameter 'p_Communication' must not be null This was fixed by setting the Sitecore username/password needed for communication between Coveo and Sitecore. You can do this by going to the Control panel in Sitecore. Under the Coveo search section, click on "Configuration" and then the "Configure" button under the Sitecore Credentials heading. This is not an issue in a lower environment like your local since Coveo uses the default admin b password to authenticate. But this becomes an issue in any higher environment that doesn't use the default admin password. Hope this helps someone else. 

Download the MongoDB installer from its website  and follow the installation steps in the wizard. Choose the Windowsx64 from the platforms dropdown.  https://www.mongodb.com/download-center?jmp=nav#enterprise Set Up Mongodb to Run as Windows Service Create data folders for mongodb, e.g.:  c:\mongo\db c:\mongo\log Navigate to C:\Program Files\MongoDB\Server\3.2\ Create file mongod.cfg. File content:  systemLog: destination: file path: c:\mongo\log\mongod.log storage: dbPath: c:\mongo\db Open command prompt as administrator Run the following command:  sc.exe create MongoDB binPath= "\"C:\Program Files\MongoDB\Server\3.2\bin\mongod.exe\" --service --config=\"C:\Program Files\MongoDB\Server\3.2\mongod.cfg\"" DisplayName= "MongoDB" start= "auto" Run command to start service:  net start MongoDB