Using the new Sitecore 7 Field Types

Using the new Field Types

Sitecore 7 introduced a few new Field Types for you to use. The main additions were all based around search and offering field types that would allow you to utilise the power of the new ContentSearch LINQ layer. If you have not already seen the documentation I would recommend checking out Chapter 5.1 in this guide here. We had a quick peek and realised there is a lot of explanation that has been left out.

We will use this medium to explore different use cases and the sources you would set to meet those requirements while we patch all this into the official documentation. Firstly, the new field types are:

  • Multilist with Search
  • Treelist with Search
  • Query Builder
  • Query Datasource

Multilist with Search

This is a field type that is an extension of the inbuilt Multilist field that has existed within Sitecore for some time. Instead of handling things on post back, it has inbuilt ajax to post back to the server on client side events triggered through entering text into the text box, clicking next, previous, refresh or go to item. If you are interested you will be able to put any browser into DEV/Debug mode and see all the posts that are happening to the server.


Like most fields, you can set a default filter on all searches made through this control. We will be the first ones to admit that the sources can be complex and that they do not follow the standard Sitecore approach. Why? Because something like this has not been in the system before and we are allowing a lot of flexibility in the sources so that you can get at all your data. In essence, the source you set for this field type is talking directly to the LINQ layer. A LINQ query looks like this for the new ContentSearch namespace:

using (var context = new ContentSearchManager.GetIndex(<StartSearchLocation>).CreateSearchContext()) 
    var query = context.GetQueryable<SomeType>.Where(<Filter>);

The Multilist with Search field is asking you to set these to properties. The StartSearchLocation is used for two reasons:

  1. To lookup which index should be searched. This is necessary as you could be using a sharded index approach or you could be search the Core or Web database.
  2. To set a default "path" filter in your Filter i.e. "Make sure you only search under this path". (This is will be overridden if you set a location filter in your Filter).

Let's get onto some examples (feel free to suggest more in the Comments):

NOTE: We used Update 3 of Sitecore 7 to run these samples. If you have not upgraded to this version, please update before running these queries.

**1: Search anywhere in the content tree**


**2: Search only on a certain part of the content tree**


**3: Search in two or more places of the content tree**


**4: Only search for a particular template**

StartSearchLocation={11111111-1111-1111-1111-111111111111}&Filter=+_templatename:sample item

**5: Only search for 2 template types**

StartSearchLocation={11111111-1111-1111-1111-111111111111}&Filter=_templatename:sample item|_templatename:media folder

**6: Field search**


**7: Field search (mandatory)**


**8: Field search (must not have)**


**9: Use Sitecore Query**

StartSearchLocation=query:/sitecore/content/*[@@name -> 'Home']&Filter=+_name:sitecore

**10: Dynamic Page Size**


**11: Wildcard**


**11: Filter Version**


**12: Filter Language**


So, as you can see, in most cases you only need to think about two parameters i.e. StartSearchLocation and Filter. Here are a couple of "Gotcha's" which you should know about and that we will iron out in an update if we have not already.

  • If you have an empty Filter then you will get an error i.e. &Filter=
  • If you do not specify a StartSearchLocation then nothing will show up
  • The Filter is essentially running a raw query against the index. It uses our SearchStringModel class which has 3 properties. These properties are Operation, FieldName, FieldValue. This is why you enter the syntax is like +fieldname:fieldvalue.
  • In your Filter we separate the queries by a "|" as whitespace will not work in this case.
  • Don't forget the "-" or "+" in front of the query if you want to force or negate a field in the filter

Treelist with Search

This is a field type that is an extension of the inbuilt Treelist field that has existed within Sitecore for some time. This control is AJAX enabled as well and you will notice straight away....this is not a tree :) In fact this was a feature that we chose to de-prioritise and opted for a simple textbox instead. The Sources work exactly the same as the multilist above however you get the opportunity to change the StartSearchLocation on the fly. You may wish to set a default StartSearchLocation and then let authors override this dynamically per field that is based off this field type.

Query Builder

This is a field type that you can give authors so if the value of the field should be in the format to run a search query then they don't need to format it themselves (error prone). Instead you are given a search screen to build up the query. We use this internally for datasource queries for controls (if you are using that feature).

Query Builder

Query Datasource

This is a field type is for internal use only so far.

Dev Team

  • Hi Guys,  Is there any way to get the repository items with newest version? I've got an issue in multilist with search, I'm trying to get items as source in multilist but the item should only visible the latest version. Right now whole version appear in selection box, if one item has 3 version whole version visible in selection box.  Thanks, NK

  • Seconding Novan's comment here. Multiple language versions are also listed - is there a possiblity to limit the search to only search for items that exist in a specific language?

  • Do you know why the "Treelist with Search" is already deprecated ? ( in 7.2 )

  • We were essentially using this filter  StartSearchLocation={11111111-1111-1111-1111-111111111111}&Filter=+_templatename:sample item  And encountered a problem during paging and searching. Essentially, the + gets converted to a space during the AJAX request, after the request querystring parsing.  For a list with 2 pages, clicking the next page brought back an empty list, and the paging numbers stated "Page 2 of 0"  I tried converting it to the URL Encoded variant, %2B, with limited success (I expect it would have worked if I pursued it further), but in the end, removing the + from the filter gave me the result I was expecting.  A quick fix (so no one has to change their filters) would be to replace space in querystring keys to + on the server side.  We are using the following version:  Sitecore.NET 7.2 (rev. 140526)  May 26, 2014 .NET Framework 4.0.30319.17929 Database version: 500  Thanks!  Jason

  • Would be cool if grouping of terms was supported, as described by lucene query syntax.