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!

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.

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.

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:

Out the box, sitecore offers several options for caching the output of sublayouts. Some of the options you have for this are things like ‘vary by querystring’ and ‘vary by data’. This post will demonstrate how to setup custom sublayout cache keys.

Behind the scenes Sitecore builds up a cache key by appending together information from the current request based on the parameters selected in the caching options. The result of this being the cache key is longer, the more permutations you select.

For typical builds, the out the box options cover all scenarios however what do you do if you need to customise this?

In a recent project we exploited * (or wildcard) items so we could accomodate data fed from an external api. This would map known url patterns to one node in the tree, allowing the presentation components on the page to be set in sitecore but the data in the body content be fed from and external system. The mvc routing dll solves the same problem in a similar fashion.

With the default cache options we ran into the issue that the cache key for each wildcard page would always be the same since the ‘vary by data’ option used the items id, rather than the dynamic url we were assigning. Essentially every page would share the cache key for the * node.

Solution
There are only two steps needed for this implementation:

1. Create custom implementation of a sublayout
2. Create custom sublayout factory

Custom sublayout

To use this on the front end, you would then embed in the markup using:

If you want sublayouts instantiated from Sitecore to make use of your new type, you need to update the sublayout renderingControl in the config:

And finally the new rendering type:

In the example above the new sublayout is used for wildcard items as well as items which match an MVCRoute – this is some new functionality currently being developed by Steven Pope @ Sitecore UK.

One of the common issues when using Sitecore HTML Caching is how to execute dynamic scripts based on code behind actions when the control front end is being cached.

The solution listed below defines the theory behind the approach rather than the concrete implementations.

Consider the following scenario:
You need to display the date to the user using javascript. To solve the issue, you decide to make use of either RegisterClientScriptBlock or RegisterStartupScript and register some javascript to write out alert(‘DateTime.Now’) [psuedo code].

This works fine during development since you are building your project a lot and the full use of caching isnt implemented. Down the line, you tune up / turn on caches and the date is only shown the first load after the caches are emptied 🙁

Do not fear, there is a solution to the issue and that is to make use of Sitecore Html Cache. Rather than calling asp.net RegisterClientScriptInclude(Block, Resource), setup your own methods (for the demo, these are exposed off SScriptManager):

In your master page, add another control (for the demo, known as SScriptManager).

When you register the script includes / blocks, store this information in the html cache remembering to build the cache key from current item, current language and script key.

During the Render/PreRender phase of the page lifecycle, the SScriptManager can then iterate through all keys in html cache and if the keys match the current page, relay on the script calls to the page.