Dynamic Placeholder Keys in Sitecore

One of my colleagues at True Clarity has come up with a really neat solution to one of the challenges introduced by the Sitecore Rendering Engine. If you want to have the same container sublayout multiple times, its difficult to achieve since the placeholder’s xpath will be the same for each row.  The solution was to setup dynamic placeholder keys which allow for similar containers to be repeated in a page’s layouts.

The setup this then allows for is:

Placeholder main
– Container in main with placeholders left and right
— Widget in container left / Widget in container right
– Another container in main with placeholder small
— Widgets in container small
– Container in main with placeholders left and right
— Widget in container left / Widget in container right

Without the updated placeholder keys, you would never get the last row of widgets since the xpath for each row would evaluate to the same value (/main/left and /main/right for each row)

You can read all about it at http://trueclarity.wordpress.com/2012/06/19/dynamic-placeholder-keys-in-sitecore/

Add component in Sitecore Page Editor

In a recent 6.5 build I ran into the problem where the add component button in the sitecore page editor wasnt offering any possible placeholders in the ui. I’d setup placeholder settings so that the item names tied up to the placeholder keys in my layout.

The expected behaviour would the ‘Add to here’ flyout is available as shown below:

The difference in the newer versions of sitecore is that Placeholder settings template have a new field ‘Placeholder key’:

If this field is blank, the page editor doesnt know how to pair up the placeholder keys and settings. Note, historically this was done via the items name.

Navigate quickly around the Sitecore Content Editor

During the lifecycle of a Sitecore project, the content editor will be used by several types of user. Here are some tips on how to navigate quickly around the Sitecore Content Editor. As a developer, a lot of these techniques have been discovered trying to save time during the development phase of a project. That’s not to say they don’t apply for anyone!

  1. Every item in the Sitecore tree has a unique guid – this is seen in the ‘Quick Info’ bar. If you know an items guid, use this to your advantage! You can either search at the top of the content tree or alternatively the search box in the taskbar. Both options will jump you to the item if it exists.
  2. Raw values is useful for tracking down related items. If you have a multilist / treelist etc then toggling raw values will show the guid’s of all the selected items. Plug this into step 1 and you can very quickly jump to the related items. You can toggle ‘raw values’ from the ‘View’ section of the ribbon.
  3. The ‘Links’ flyout in the navigation panel gives you the relationship between items – here you can see all the items ‘referring to’ or ‘referred by’ the current item. A good example of this is seeing all the items which are of a certain template type.
  4. Single clicking the items path / guid / template path / template guid selects the whole value. This might seem like a minor point but saves clicks when navigating the content editor.
  5. Shortcuts – the content editor is packed with them – highlighting items in the content editor often shows the keyboard shortcut . A lot of them are listed at http://www.sitecore.net/Community/Technical-Blogs/Sitecore-Australia-Blog/Posts/2010/06/Top-100-List-of-Sitecore.aspx
  6. ‘Go to template’ available in the developer section of the ribbon. This jumps you directly to an items template.
  7. The ‘inheritance’ tab of a template. Here you can see all the templates that make up the item in question – clicking any takes you to that field section / field.

Automatically set the language of the content editor

In a recent build we had a request from the client to automatically set the language of the content editor based on where in the tree they were viewing. The rules for selecting the language were quite simple:

– sitecore
— Content
— English site – field with value for default language set to be ‘en’
— French site – field with value for default language set to be ‘fr-fr’

If the user was making changes within the English site, they wanted the Content Editor to default to ‘en’. If they were editing within the French site, they wanted the Content Editor to default to ‘fr-fr’.

With the help of support, the following solution was suggested:

  1. Create your own class inherited from Sitecore.Shell.Applications.ContentManager.ContentEditorForm
  2. Add a new method:
  3. Edit \sitecore\shell\Applications\Content Manager\Default.aspx, changing the sc:CodeBeside reference to point to your new class:

    Note, you need to keep the CodeBeside reference on one line as per the out the box version (the other controls are eg DataContext, RegisterKey etc)
  4. Edit \sitecore\shell\Applications\Content Manager\Content editor.js, adding a call to your new method. This needs to happen in the onTreeNodeClick method after LoadItem.

Moq – the basics

During a recent XP programming course we made use of the Moq’ing framework. I’d not used this before so tried to come up with some example moq basic tests. There are several tutorials on the internet which offer up the basics so do hunt around. Hopefully the following provides some simple examples for people to get started with.

The following code relies on the following assemblies:

The real crux of TDD is that you program your functionality to interfaces – here we have a simple interface and dto:

Note the importance of the virtual property in MyObject will be highlighted in the tests. In the following examples not all the tests pass – this is intentional! Failing tests are included to demonstrate specific features of Moq. Apologies for the long dump of test code – the idea is really to copy it into a test class and let NUnit do the work.

Here is the expected results when evaluated in NUnit:

$name in your Sitecore content

One issue that seems to regularly occur in Sitecore builds is pages showing $name in the content. Its the sort of problem that seems to creep into projects the further through you get.

Why does it happen?

When you setup Sitecore templates they are typically built up from several other templates eg:

  • A content page is comprised from:
    • Page Title field section
    • Meta Data field section
    • etc

Down the line you decide you want to add ‘Page Content – (Header and Body fields)’ to all pages so you setup a new Field Section template along with corresponding fields and __standard values. So that new pages automatically push the item name to the Header field, you set the __standard values to contain $name.

All this gets published and you then come to check the front end of the site – pages created before adding the Page Content field section now have the new header and body fields but the header field shows $name 🙁

The reason being these fields are inheriting their value from __standard values – variables such as $name are processed when items are created. See http://adeneys.wordpress.com/2009/12/29/custom-tokens-and-nvelocity-for-item-creation/ for info on how to create custom replacement tokens. There is also more information on http://learnsitecore.cmsuniverse.net/en/Developers/Articles/2010/08/Standard-values-in-sitecore.aspx

How to solve the problem?

When items are created they are processed by a set of pipelines. An example of this is expandInitialFieldValue pipeline. Out the box, this makes use of  the MasterVariablesReplacer.

You now have a couple options, either you can call the MasterVariablesReplacer for the problematic items or you could manually script the same functionality. The following code demonstrates the manual approach:

Its worth noting this can introduce some interesting challenges if Language Fallback is used on your site. The script above works fine for content items on a single language site. If you need similar functionality when language fallback is in place it may actually be meaningful to set $name = ” for non-primary languages. This will ensure the fallback will occur correctly, rather than finding $name and thinking it is valid content.

How do Sitecore commands work in the cms?

Under the hood the Sitecore api offers huge amounts of functionality. When you are using the cms environment, chances are you are triggering this functionality via sitecore commands.

Most buttons in the cms are tied into these commands so how do you pair up specific buttons to specific code?

There is an excellent Firefox plugin – Firebug, which is essential if you do a lot of web development. If you haven’t ever used this, download it now!

Once installed, run through the following steps:

  1. Fire-up your cms environment inFirefox (once firebug is installed)
  2. Activate firebug and select ‘inspect element’ – then click the button you are interested in
  3. Check the firebug window for the JavaScript attached to the button click – this should be wrapped in a sitecore form post JavaScript method eg javascript:return scForm.postEvent(this,event,’item:setdisplayname’)
  4. Open /app_config/commands.config and search for the command name. Examples of this are: item:setdisplayname, item:publish
  5. Find the assembly referenced in the commands file and fire up your favourite decompiler eg reflector or ilspy and search for eg <command name=”item:setdisplayname” type=”Sitecore.Shell.Framework.Commands.SetDisplayName,Sitecore.Kernel” />

You should now have a route into the source code for each button in the cms!

Sitecore packages

If you have ever developed with Sitecore, chances are you will have deployed content via Sitecore Packages.

A sitecore package is essentially a zip file containing the xml to be stored in the sitecore databases along with any files you choose to deploy. Some upgrades make use of *.update files – this is out the scope of this post.

When you install content from packages, items should have the same guid. If conflicts are found during an install you are presented with several options. One word of caution – if you choose overwrite, its pretty easy to blow away large chunks of the tree if you package only contains a few items.

If you want to see what is in a package you have a few options:

  1. Drill into the zip file with your favourite zip program – content items are nested by database and then path
  2. Load the package into the Sitecore Package Designer (I wish I knew about this one sooner!!!!!)

For the second option, there is a hidden button (why this is hidden I dont know!) in the package designer:

When you click ‘From Existing’ you are shown the contents of your data -> packages folder. If you have been sent the package, copy it to this folder.

Once the package is selected you should see items in the package designer as if you had created the package yourself. From here you can then save the xml definition as per normal.

Add item anywhere in the tree without setting any Sitecore insert options

Consider the following scenario: you setup a new Sitecore template (or branch) which you want to add anywhere in the tree without setting any sitecore insert options

The reason you may want to do this is you have several templates in place throughout the tree, if the insert options can’t be inherited then you would need to update a lot of standard values!

If you dont use the rule engine for this (see this post) you can still achieve the same solution.

In the following example, we want the user to be able to add a Generic Form anywhere under the home node of the site.

Which then needs patching into the uiGetMasters pipeline (/App_Config/Include):


After the talk at the Bristol Sitecore User Group yesterday, Raul demonstrated the rule engine for this kind of thing – the exact same problem can be solved without any code 🙂

You need to set yourself up a rule eg:

Note, one step remains – you need to select the root item.

API techniques – accessing items in the sitecore tree

Sitecore offers various methods for accessing items in the sitecore tree. The following shows some examples:

Typically we will store key item guids and key template guids in static classes so they can be used throughout the code.

From experience it is rare to use path to access items since an items path can change over time – essentially it is content rather than something fixed. An items guid should never change even when it is packaged up and distributed to multiple environments.

Its worth noting that once you have accessed an item, it may be it is null. Another scenario is that it doesnt have any versions – this can be caused by an item being published when it isnt in a final workflow state.
These are easy things to check: