Tridion 2011 Search Hacks

August 16th, 2012 | Posted by Robert Curlette in Tridion 2011 - (0 Comments)

If you recently upgraded to Tridion 2011 and your search results are not what you expected please read on – with a few simple tips your search results will improve and you’ll stop singing that U2 song ‘I Still Haven’t Found What I’m Looking For’.

Tridion 2011 comes with the super-powered Solr search engine – this is an open-source search engine from the Apache project built on top of Lucene; new in Tridion 2011.  Previous versions used Verity.

The search box on the dashboard works as advertised – it searches within the current context for matches – in all types of items from Components to Templates to Schemas.  Context is important here.  And you can still type Tridion TCM URIs in the box and open the item directly.

Wildcards are your friend

What makes the difference from a few items found and many are the wildcards you use.  Simply place a * before the word and after and your chances for finding matches increases exponentially.  This is especially true when searching in template code.

For example, if I want to find where the field intro_text is used in a template I can use *intro_text*.

Other wildcard combinations are possible with the ? character, saying to use any character.  For example te?t will match test and text.  Although probably not as useful as the * keyword – it is possible.  Solr is built on top of Lucene – meaning it uses the Lucene search engine and adds additional features such as facets and an http-based API.  For additional search help see

Advanced Options

Using the Advanced search window you can increase the amount of items returned (default is 50) and filter the types of items searched.  Perhaps the most important setting is the amount of items returned.


Populating the search index

After upgrading your existing installation to Tridion 2011 you will need to populate the Solr Search index first before search results are returned.  You can do this with the  TcmReIndex.exe tool located in the Tridion/bin folder.  Without running this tool your search index is empty.  Afterwards, whenever a user saves any item in Tridion the Seach Service populates the Tridion search index with that items’ content.

Tridion did a good job of including the powerful Solr search engine with Tridion 2011.  With the new engine we have faster searches and more possibilities.  With a little bit of luck your searches will help you find what you’re looking for.

Tridion 2011 brought us the ability to change the users experience in the GUI. This is something I wanted (and needed) to do for the last 10 years – but was not allowed to but was not comfortable doing with the lack of documentation and support. The ability to officially modify the Tridion GUI and modify the default experience for users arrived in Tridion 2011 Tridion 5.2 and was continually expanded on until fully embraced in 2011. Before 2011 it was possible, but the official response from Tridion was ‘It’s not supported’ and if a customer called Tridion with a modified GUI Tridion ASP system files and would not receive support.  Needless to say, we never modified the GUI as a general practice as part of an implementation – it felt too unsupported and undocumented.

This changed in Tridion 2011. One of the features added was to write our own ‘GUI Extensions’ and these new extensions were supported – and documented. Not only that, but we had a brand new javascript framework called Anguilla that we have available to use for extending the GUI. Next to the Anguilla framework we also have the ability to add buttons to the GUI, extra columns to the list view and even tabs to the Edit windows of item types. This is revolutionary in the Tridion world, where previously our GUI was locked down by R & D generally not open to edit except for specific extension points, and then not documented as in 2011, and I instantly fell in love with this new concept. After attempting to create my own extensions using existing blog posts and documentation I quickly got stuck – all guides showed how to add the buttons, etc – but what about functionality with Tridion? I found some great code samples on Tridion World – but no explanations. So, I decided to spend some serious quality time and dig into the Anguilla framework and GUI Extension technology. I was very lucky to have the full support of the Tridion Community and before too long I had a working GUI extension and started to make sense of the madness. I did it – and decided to share my newfound love with the world. What followed was a series of blog posts about creating GUI extensions. I tried to fill the gap between what documentation was available and what was possible. I tried to give a code sample and explanation for each type of new extension. I did this with the thought that everyone should be able to write this code, and do it with a good understanding of what it does.

Now Alvin wrote his post and it made me think – is it now understood as a common step in an implementation to modify the GUI? For me writing custom pages and modifying the GUI are always part of an implementation, but a small part with a big impact on daily usability, often saving users hours of time per week. Another way to save users time each week is to have a well-defined Schema, clear folder structure, solid Blueprint, and clear instructions. This is Alvin’s point and I 100% agree – this is the main goal of every implementation – clean, well-defined, and clear. These goals do not require GUI Extensions but they require a clear understanding of the business requirements and an architecture design that enables ease of use in the Tridion system. Indeed, Tridion is an open box and everything is possible- allowing customers and partners to misuse various features or not use them to full effect. An amazing GUI Extension will not compensate for this basic lack of a solid foundation.  GUI Extensions are the whipped cream on top. Not all implementations need it – but when it is there it gives a very nice finish to an already great product.