Sitecore Swamp

Dive in the Sitecore Swamp


Object Exporter - Visual Studio Extension

Has it happened to you that you want see and save a variable value when you doing debug in visual studio. For example, for a particular exception, you want save and share the detailed information, or you have a list of objects too difficult to watch. You can type the variable in immediate command window, and copy/paste the output, or you can use Object Exporter.

Start your debug mode, and make a break point. Now highlight the variable, and tools > Export Objects:

You can choose output format as C# Object Initialization Code, JSON and XML. Pretty cool!

Sitecore TDS Tips

  • Sync the templates/rendering first, then sync content
  • Sync and refresh until nothing comes up. TDS may not complete all the synchronizations in one sync, always refresh until no more new things are found. Sometimes, you maybe need to sync three or four times until everying in sync.
  • When you GLV (get latest version) from TFS, the TDS may not include all the items. When happens, It complains some errors about field missing. You can manually include the item into the project.
  • When you use TDS with GlassMapper CodeGen. After the TDS Sync, the code generated may not be perfect, errors sometimes. When it happens, simply right click the TDS project in VS solution explorer, and select Re-Generate Code for all items

Display More Details in Visual Studio Build Output

If you demand more information from Visual Studio output when building the VS solution, here the way:

VS > Tools > Options > Projects and Solutions > Build and Run

By default, the minimal is selected, and it only displays the most important messages. Normally, I change it to Detailed, you will see the difference as much more information will be in the output. Together with VSColorOutput, you will have the best experience on the VS build output.

Sitecore Version History

  1. Kiran Patil:
  2. John West :
  3. Kim Hornung :

Querying items in Sitecore

Sitecore Query

Sitecore Query is probably the most commonly used approach as its the standard way to query content. Sitecore-certified developers likely all know Sitecore query as a starting point. An easy way to help build up your queries correctly is to use the XPath builder in the Developer Center.

Unfortunately, Sitecore Query has performance issues depending on how you build your queries. Creating very specific queries has a performance hit because the query magic built into Sitecore has to do more checks on each item. A recommended practice when using Sitecore Query is to make your queries as generic as you can and use .NET to loop over the results and filter them further.

Let’s consider the following type of query and how it can be adjusted. Say you want to retrieve all items at a specific path of a certain template type where each item has specific field values. A good approach would be to not include the check for the field values in the query, but filter the results using C#. So for example, let’s find all Employees under the About section and filter them with C# based on some field criteria. The example below makes a fairly generic Sitecore query and uses LINQ to filter the results:

Item[] allEmployees = db.SelectItems("query:/sitecore/content/home/about/*[@@templatename='Employee']");
IEnumerable<Item> employeesWithNames = allEmployees.Where(item => item.Fields["First Name"].Value != "" && item.Fields["Last Name"].Value != "");

The lines of code above will: (1) get all immediate children of template “Employee” under the “about” item, and (2) will use LINQ to loop over each resulting Sitecore Item and will check if both the “First Name” and “Last Name” fields are not empty strings. The resulting IEnumerable<Item>now contains only Employee items with those fields filled in. The above code is fairly useless but it shows how you can use LINQ to filter your general result sets as opposed to writing a long Sitecore Query to be very specific.

One important thing to note is that a self-or-descendant selector (i.e. //*) is not recommended. This performs a recursive query down all subitems and will cause performance issues. It is recommended that both front-end code and template field queries not use self-or-descendant as they can slow down the front-end of the site or even the content editor itself.

It’s also important to note that special characters in queries need to be escaped with a hash, for example, a hyphen in a query will break the parser and needs to be handled by being wrapped in #.

This query will not work:


This one will:


Fast Query

Fast Query is very similar to Sitecore Query but it is more restrictive on what you can query with, however is performs faster than a reulgar Sitecore query. Fast Query is recommended to retrieve many more items than a Sitecore query. The prefix for a fast query is “query:fast:”. Fast queries are actually translated directly into SQL statements and executed on the database, so there are limitations. I recommend you read the Fast Query doc on the SDN.

Lucene Search

My experience with querying Sitecore with Lucene is fairly new, but is the result of Alex Shyba’s work at Sitecore with Lucene. Alex has created a great toolkit called the Advanced Database Crawler to make it easier for developers to setup and query Lucene with some pretty simple C#. The best way to get started using Alex’s toolkit would be to watch his video series on sample search scenarios and configuration settings. In the future I will publish a summary of my findings with this new tool and the things I’ve learned while using it.

Determine How You Should Query Sitecore

Below is a table of recommended approaches to querying Sitecore based on the number of items in the result sets. Note that the web.configsetting Query.MaxItem affects the number of items that a Sitecore query can return. Say if you want to return 150 items from a Sitecore query (not recommended), you’d need to adjust the setting. The higher this number is, the more you can get back from your Sitecore queries which means the worse your app can perform because of these large queries.

Query ApproachResult Items
Sitecore Query100 items or less
Fast Query1000 items or less
Lucene Search1000+ items

Domain Cookie

Mapping this knowledge onto your questions, the following should apply:

  • Cookie with will be available for
  • Cookie with will be available for
  • Cookie with will be converted to and thus will also be available for
  • Cookie with will not be available for
  • will be able to set cookie for
  • will not be able to set cookie for
  • will not be able to set cookie for .com

And to set and read a cookie for/by and, set it for and respectively. But the first ( will only be accessible for other domains below that domain (e.g. or where can also be accessed by any other domain below ( or