Well, Sitecore has just announced the newest members of the MVP club. You can read all about the 2009 MVPs and the MVP programme in Sitecore’s press release which you can find here: http://www.sitecore.net/News/Press-releases/2009/Sitecore-MVPs.aspx.

I’d like to welcome to the club the following 2009 Sitecore MVPs.

• Guillaume Buat-Ménard from Aqueduct
• Jason Davey from Bullseye
• Sebastian Winslow from Codehouse
• Stefan van Dockum from Colours
• Kern Herskind Hansen
• Vincent van Middendorp from Evident Interactive
• Sean Kearney from Hedgehog Development
• Andreas Bergström from Metamatrix
• Jens Mikkelsen from Pentia
• Matt Hovany from The Revere Group
• Aren Cambre from Southern Methodist University
• Gabriel Boys from Velir

I did my best to collate the blogs and company websites of the 2009 MVPs. If I got any wrong please let me know so I can update the links. Especially for the non-English sites .

Mark Cassidy (fellow MVP) compiled a very good list of the 2008 MVPs at http://www.cassidy.dk/blog/sitecore/2009/01/sitecore-mvps-announced.html. As you can see, MVP is not just for bloggers. It is an award for anyone who promotes and evangelises Sitecore and knowledge about developing with Sitecore.

Sitecore MVP awards last for 2 years, so all the 2008 MVPs (one of which is me) still stand. This brings the total worldwide MVP count to 27. Actually, I think it’s more like 25 cause you lose MVP status if you start working for Sitecore as the MVP award is for professionals outside of Sitecore.

And I’ve gotta say, given what I was shown as an MVP last year before the rest of the crowd, I’m quite excited at what I might be privy to this year.

Congratulations to all the 2009 Sitecore MVPs. If we manage to meet up I’ll show you the secret handshake .

It’s been a very long ride, but the next minor version of Revolver has finally been released. If you currently hold a license for Revolver you can download the new version from the Revolver downloads page on the codeflood website. The quick start guide has also been updated.

In case you haven’t seen it yet, Revolver is a module I wrote for Sitecore to provide a command prompt inside the Sitecore desktop. This allows the developer or administrator to interact with Sitecore in a much different way (through text) which is much better for performing certain actions like executing ad-hoc queries against the content tree or performing bulk update operations.

So what’s new in Revolver 1.1? There have been lots of updates. Some you’ll be able to see, some you won’t. There has been a bit of a reworking of some of the internal code to make it more consistent and easier to maintain in the future. The following is a list of the new features and commands of Revolver 1.1 in implementation order.

1. No Stats for find and query. I’ve added the -ns flag to pass to the find and query commands. This causes the command to not output the count of how many items were found. This will allow you to use these commands in sub commands.

2. Path parameters for query. Now, this is kind of a funny one. Sitecore query already allows you to specify a path. But to remain consistent with the rest of the Revolver commands I added the ability to specify a path to run the query at.

3. Slash = root. The cd command has been updated to allow the use of slash (/) to refer to the root item of the content tree (sitecore item).

   cd /
   

4. Added the split command. The split command allows you to split a string on a given token, newline characters or tab characters then execute a command against each element. So I could split a multilist field and display the names of each item.

   split -s | < (gf -f multilist) (ga -a name $current$)
   

   The token $current$ can be used in the command parameter and represents the current element from the split string. I could also do something like create a bunch of items based on a text file on the file system that contains a single name per line.

   split -n < (echo -i -f itemnames.txt) (touch -t document $current$)
   

5. Added the ct command. The ct command allows you to change the template of an item. The command checks to ensure the target template contains the right fields so you don’t lose field data. You can force the change if you want to change to a new template which doesn’t contain all the currently used fields and you’re happy to lose that field data by using the -f flag.

6. Case insensitive regexs The regular expressions used on the ls and find commands previously were case sensitive, but more often than not we don’t care about the case. So the regexs are now case insensitive by default and you can pass the -c flag to the command to make them case sensitive.

7. Added the users command The users command can be used to list the current sessions of the Sitecore application and also to kick a session. Note though, even though the session is kicked to allow another session to start, if the owner of the kicked session makes another request before the available sessions runs out they will have a new session automatically created for them.

8. Fast query support Revolver now supports Sitecore’s fast query. Simply prefix the Sitecore query you pass to the query command with fast:

9. Added support for branches Sitecore 6.0 did away with masters and introduced branches. Revolver now supports branches on a number of commands.

10. Purge all languages The rmv command now supports passing an -a flag to indicate you want to remove versions in all languages and not just the current language.

11. Comments in scripts You can now include comments in your scripts by starting the line with a hash (#) symbol.

12. Help for scripts The script data template now has fields to support the help system of Revolver including adding examples.

13. Added lsdb command The lsdb command lists all the databases of the current system.

14. Added the lm command The lm command allows you to manipulate lists. So now you can add an ID to a multilist field and be sure it won’t add it twice.

    sf multilist < (lm -a < (gf -f multilist) | {945F96B9-5A7D-459C-8240-3A61362A0D32})
    

    Or you could remove the ID and not have to worry about where it appears in the list or having an empty element resulting in two pipes next to each other in the field.

    sf multilist < (lm -r < (gf -f multilist) | {945F96B9-5A7D-459C-8240-3A61362A0D32})
    

15. Added exit command You can now close a Revolver window by simply typing exit. Although I say it is a command, it’s not actually…

16. Ajax submission The previous version of Revolver used Sitecore’s postEvent function which causes the entire form to post back to the server. That includes all the text in the command window including all the commands you’ve typed and all the responses. The new version of Revolver now uses Ajax to send only the current command to the server, then inserts the response into the textbox. Much more efficient.

17. More operations in expressions Expressions (used in the find command) now support the following operations. Starts with ([), ends with (]) and contains (?). So I could now look for any child item of the current context that starts with “abc”.

    find -e (@@name [ abc) pwd
    

    Or search for items which contain “Sitecore” in the text field.

    find -e (@text ? sitecore) pwd
    

18. Added support for UNC paths to echo The echo command now supports files on UNC paths and not just local files.

19. Ensure output folder in echo The echo command now also ensures folders which you’re outputting to exist before writing any output files, and if the folder doesn’t exist it will create it.

20. Sorting on ls command The ls command now supports sorting of the content. By default the items will be displayed in Sitecore order. But they can be reversed using the -d flag or alphabetically using the -a flag.

21. Output text limit Revolver now contains an outputbuffer environment variable which defines the maximum number of characters that can be contained in the output window.

22. Input a newline in a field The Revolver UI now allows you to use shift + enter to input a newline. This can be used to enter multiple lines into a rich text or multiline text field.

23. Added grep command The grep command works the same way as grep on a unix or linux system. grep is used to filter multiple lines and match each line against a regular expression. This allows you to search through a lot of input. So you could search through a list of sessions returned by the users command.

    grep admin < users
    

24. Added links command The links command allows you to list incoming, outgoing and bad links for the context item.

And remember, you can always use the help command to get detailed help for any command in Revolver.

It is with great pleasure I finally announce the launch of my new website, codeflood. So what is codeflood? codeflood is an attempt at a more professional web presence than my previous self indulgent website World of Al. codeflood is where I will host my projects such as Revolver for Sitecore and SashimiCMS.

Although the current project pages on World of Al will remain, all the new stuff and new versions will be released through codeflood. I’ll add a nice little message to the deprecated pages on World of Al to point users to codeflood.

I’ve gotta say, I’m quite excited to finally get this website live. I’ve been slaving over getting it live since the start of December, and interrupting my other projects such as the next version of Revolver and the Sitecore shared source Integrated Help Module. More on both of those to come…

We’d all be familiar with the tokens you can use in template standard values which get replaced on item creation in Sitecore. They are a great way to set some default field values based on some other data such as the name given to the item or the current date.

The following lists the tokens available in Sitecore 6.2.

$name

The name of the item being created

$id

The ID of the item being created

$parentid

The ID of the parent of the item being created

$parentname

The name of the parent of the item being created

$date

Date part of the current datetime in Sitecore ISO format

$time

Time part of the current datetime in Sitecore ISO format

$now

The current date in Sitecore ISO format

I remember being told during the Sitecore 5 time frame that token replacement used NVelocity. In fact, I’m sure I remember it being in the training material. Well in Sitecore 6 it doesn’t appear as if it is. The tokens look like Velocity variables, but that’s just coincidence.

But could I get some value from using NVelocity to process the replacements?

Firstly, let’s just look at adding our own token into the replacement. It’s actually quite simple. All we have to do is add a processor to the expandInitialFieldValue pipeline. So let’s go ahead and create a processor which will insert the domain for the current request (which is quite commonly the same URL used to access the public site).

using Sitecore.Pipelines.ExpandInitialFieldValue;
using System.Web;

namespace CustomReplacers
{
  public class DomainReplacer : ExpandInitialFieldValueProcessor
  {
    public override void Process(ExpandInitialFieldValueArgs args)
    {
      var context = HttpContext.Current;
      if(context != null)
      {
        if (args.SourceField.Value.Contains("$domain"))
        {
          var uri = context.Request.Url;
          args.Result = args.Result.Replace("$domain", uri.Scheme +
            "://" + uri.Host);
        }
      }
    }
  }
}

And add our custom processor to the expandInitialFieldValue pipeline.

<processor type="CustomReplacers.DomainReplacer, CustomReplacers" />

Add this processor at the bottom of the pipeline below the default Sitecore processors to allow Sitecore to do it’s thing before our custom processor gets involved. As with other pipeline processors you can abort a run in a processor and the expandInitialFieldValue pipeline is no exception; note the SkipStandardValueItems processor. You don’t want your processor doing extra work it didn’t have to.

Inside the custom processor you’ll notice all the magic happens around the ExpandInitialFieldValueArgs parameter which is passed into the Process method. You have access to the source field through the SourceField property where you can grab the current value to process. We need to put our output into the Result property. But seeing as though our processor is not the first to run, we’ll want to process the existing Result property, not the original field value as the previous processors may have already altered the result and if we just processed the source field value again we’d lose the processed value.

After you’ve adding this processor in and setup a template’s standard values with the $domain token when you now create an item based on this template the token will be replaced with the current domain URL.

As you can see, adding your own tokens is pretty simple. But let’s explorer the idea of using NVelocity to process the fields. We’ll of course need to start with a new custom processor. This processor will use NVelocity and add the item being currently processed into the context for use.

using System.IO;
using NVelocity;
using Sitecore.Pipelines.ExpandInitialFieldValue;

namespace CustomReplacers
{
  public class VelocityProcessor : ExpandInitialFieldValueProcessor
  {
    public override void Process(ExpandInitialFieldValueArgs args)
    {
      if (args.SourceField.Value.Contains("$item"))
      {
        var context = new VelocityContext();
        context.Put("item", args.TargetItem);
        NVelocity.App.Velocity.Init();
        var output = new StringWriter();
        NVelocity.App.Velocity.Evaluate(context, output,
          "VelocityProcessor", args.Result);
        args.Result = output.GetStringBuilder().ToString();
      }
    }
  }
}

We’ll of course also need to add the processor to the pipeline.

<processor type="CustomReplacers.VelocityProcessor, CustomReplacers" />

Objects you put into a velocity context are not just strings; they are real objects which you can interact with and call on their properties and methods.

Now we can do some pretty cool stuff using VTL (Velocity Template Language). Just add some of these into your template standard values.

The name of the item:

$item.Name

The path of the item:

$item.Paths.FullPath

The name of the item’s grandparent:

$item.Parent.Parent.Name

The ID of an ancestor whose key is “home”:

$item.Axes.SelectSingleItem("ancestor::*[@@key='home']").ID

That’s right, we can use Sitecore Query in our item creation now. This is because the Item class is a very rich class which gives access to a lot of functionality. In the above Sitecore Query example I use the Axes property of the class so I can execute a Sitecore Query using the SelectSingleItem method. I could also use the SelectItems method to return an array of items. And VTL allows me to iterate over those items.

<ul>
#foreach($i in $item.Axes.SelectItems("
  ancestor::*[@@templatekey='sample item']"))
  <li>$i.Name</li>
#end
</ul>

To learn more about VTL check out the Velocity User Guide. Note that VTL used by NVelocity should follow that used by Velocity (the original Java project which NVelocity is based on).

And I should also point out an article which I stumbled upon whilst writing this article. Looks like our man Alexey Rusakov beat me to this idea way back in 2005. Check out his Velocity master variables replacer.

When Sitecore 6.2 was released I wrote a post about some of the new features included in the release. One of which was inbuilt RSS. I think this feature was quite underplayed on my part, so allow me to make a song and dance about it here.

The RSS capabilities of Sitecore 6.2 comes in 2 parts. The first is standard content RSS. It’s now quite easy for content authors to create RSS feeds for their content. The Shared Source RSS module always allowed us to do that but now it’s handled natively. The RSS module is also quite old and had to provide it’s own way of doing certain things that have since been added or changed in the CMS.

Content RSS feeds in Sitecore 6.2 are very easy to create and have been designed to allow non-developers to create and maintain them. There are 2 parts to creating a content feed. Firstly you have to define the appearance of the feed; which data fills in which RSS element. This is done using the feed designer form which sits on the presentation tab in the content editor. The feed design is saved back to the item’s template standard values so all items based on the same template will look the same. After all, you don’t want to have to go through every single item and define it’s feed presentation.

The feed designer presents a selection of fields you can use to populate each of the RSS elements. And this would be fine for most content authors. But what if you need to create a more complex aggregation? What if you want to generate the body of the feed based on several fields, or even refer to other items as well? All the feed designer is doing is setting a presentation for the RSS device of the item’s template standard values. This is the same way in which you’d define presentation for any other kind of device. You’ll notice after you’ve designed the feed that the feed device now uses the “Feed Delivery Layout” layout and the FeedRenderer control. Being that this is standard presentation definition you could change this if you needed more flexibility in designing the feed.

After we’ve designed the item’s feed presentation we need to define a feed item which when requested will output the RSS. This is as simple as creating an item in the content tree which inherits from the /sitecore/templates/system/feeds/rss feed template. You’ll need to fill in the items field which points to the parent of the items you want to syndicate through the feed.

If we need more control over the behavior of how the feed works we can also specify a custom type in the type field of the feed item to override these default behaviors. This custom feed type must inherit from Sitecore.Syndication.PublicFeed.

Let’s say I wanted to be able to filter based on template, so only items that are based on certain templates will be included in the feed. I would first create a new template which inherits from the rss feed template and add an additional field Include Templates of type TreeList to my new template. I could then use the following class in the type field of a feed created from that template to perform the filtering.

using System.Collections.Generic;
using System.Linq;

namespace Sitecore_Custom_Feed
{
  public class CustomFeed : Sitecore.Syndication.PublicFeed
  {
    public override IEnumerable<Sitecore.Data.Items.Item>
      GetSourceItems()
    {
      string templateIDs = FeedItem["Include Templates"];
      var items = base.GetSourceItems();
      return items.Where(i => templateIDs.Contains(
        i.TemplateID.ToString()));
    }
  }
}

Now only items which are based on any of the templates in the Include Templates field will be included in the feed.

Another handy extension to have on each page is the ability to check if an item contains a feed item as a child and provide the alternate link tags in the html head to have the browser detect the feed for this page. Firefox for example will display an RSS icon on the right-hand side of the address bar if the page contains an alternate link.

Some XSLT you might use to output that tag:

<xsl:for-each select="child::item[@template='rss feed']">
  <link rel="alternate" type="application/rss+xml"
    href="{sc:path(.)}" title="RSS feed"/>
</xsl:for-each>

Just make sure your alt link rendering is included in the head section of your HTML.

Content authors can also simply link to the feed item after they’ve created it in the rich text editor.

After publishing your changes you’ll be able to see the feed on the live website.

The second part of the new RSS capabilities in Sitecore 6.2 is Sitecore Client Feeds. Sitecore now allows you to subscribe via RSS to a workflow, workflow state or individual content item’s updates. This is really awesome cause it means content approvers no longer have to log into Sitecore each day to check their workbox. All the information they would have received from this application is available through RSS, including the ability to execute commands directly from the RSS.

Lars Nielsen noted in a comment on my original Sitecore 6.2 new features post that he has subscribed to workflow using Outlook. I’ve also heard other people calling this client feeds capability “Outlook integration for workflow”. This is a misnomer. Calling this feature as such is actually limiting it’s potential. RSS is more pervasive than just Outlook and Windows. With this capability I can now have native support for workflow information using any RSS program on any platform (or device ). I can approve articles directly from my Linux machine (Sitecore supports the content editor cross browser, so I could have already done that, but now I’m using a native application), or from my mobile phone. Anything that can support RSS.

I’m actually quite disappointed in the workflow RSS capability. Why you might ask? Does it lack a particular feature? Does it lack some polish? Do I not like how it works? No. None of the above. Earlier this year I achieved a very similar result using email. Actually I should say it was one of my colleagues as it was he who wrote the thing (thanks Michael!). The basic idea of the Next Digital extended workflow action was to provide an email action that can be included in workflow and provide both extended capabilities in terms of field data and provide workflow commands inside the email. This action was based on Alexey Rusakov’s extended email action. So I’m quite disappointed in the workflow RSS capability because our really cool Sitecore extension is not as unique as it once was.

To subscribe to a workflow feed simply log into Sitecore and open the workbox then click on any of the RSS icons in the UI. The RSS icon in the workflow title bar is of course for the entire workflow and the RSS icon in the title of each workflow state is of course just for that state.

Now whenever an item enters the state (for state RSS) or when it changes state (for workflow RSS) you’ll get a notification in your RSS client. You’ll get a bunch of information about the item along with the available commands you can execute against the item, taking into account your security. This means that if you don’t have the required permissions to the command, you will not see the command in the feed.

And just to prove it really does work outside of Outlook, here’s a few other programs and platforms.

Sitecore workflow RSS on an Android phone – List view.

Sitecore workflow RSS on an Android phone – Article view.

Can you imagine as a content approver being able to approve content whilst on the run straight from your mobile phone?

Sitecore workflow RSS in Akregator in Kubuntu (Linux).

For more information on RSS feeds in Sitecore 6.2 and for full instructions on how to create them, refer to the Content Author’s Reference and Cookbook for Sitecore 6.2 which can be downloaded from the SDN.

It was a real shame when Sitecore removed Firefox support when they released Sitecore 5.3. In prior versions of Sitecore you still had the option to log into the desktop from the login screen when using Firefox. And even though it didn’t look quite as perfect as it did in IE, it was so much faster thanks to the faster javascript engine in Firefox.

But there are ways around that. Check my previous blog post on how to login to the desktop using Firefox in Sitecore 6.x .

Even though desktop support was removed you could still log into the page and content editors and edit content that way. A little while ago I had a client reporting that the scrollbars were missing in the content editor tree when they were using Firefox. This seemed quite odd, but sure enough, when I checked a Sitecore 6.0.2 site using the latest Firefox (version 3.5.5) after expanding out the content tree and clicking on an item the scrollbars disappeared. Thinking this may have been fixed in a later update I checked a 6.2 site, and the same error could be seen.

After much investigation and firebugging I finally found the issue. It lies in the /sitecore/shell/Controls/Gecko.js file. On line 495 is the following line:

element.setStyle({ height: "100%" });

This is the culprit. To solve the issue simply comment that line out.

What I believe to be happening; the content tree sits inside a table cell. When you set a style with 100% height that means the element should be 100% of the height of it’s containing element. In this case, a table row. This row also holds the fields section to the right of the content tree, which is much longer than the content tree and will push the height of the table row out. So when we set 100% height on the content tree panel, it should now be the same height as the fields section. At least that’s what I think is happening.

I must point out that I haven’t tested the above solution exhaustivly and this update may affect other areas of the system. I’ve also only checked the solution with the Firefox version mentioned above (3.5.5) and I suspect that this would break earlier versions on Firefox. If that were the case it wouldn’t be too difficult to update the script so instead of commenting out line 495 just detect the browser version and use that in an “if” statement.

I’ve already logged the issue with Sitecore support so this post is just for the interim if you really need a fix and can’t wait for another release from Sitecore. I’m also posting this to explain how I can do some of the things I do in my next post.

Recently I had a situation where I needed to run a lengthy process inside my Sitecore solution which needed to run some custom code. The actual process itself was to update a separate Lucene index we were using for a user search component on an intranet. I prefer to perform user search against an index rather than the user store itself. Primarily for performance and secondly to provide more options for the search.

The normal way I’ve seen a lot of this kind of thing done is someone will create a very plain looking web form (aspx) and drop it in a folder, then have the admin user hit that page directly. The problem with this approach is that the page is normally quite ugly and doesn’t feel like part of the solution. And if your process takes a while you would have to custom code the ajax calls to update your UI and provide feedback to the user.

Can you tell this page was designed by a developer?

Realistically it’s a sin to burdon your users with this ugly kind of page. Especially when Sitecore is so extensible and already contains a location for these occasional utilities; the control panel.

It’s very easy to add your own entries into the control panel. All the categories and utilities themselves are defined under /sitecore/content/Applications/Control Panel in the core database. To add your own utility it’s as simple as adding an item under an existing category (based on the /sitecore/templates/Sitecore Client/Tasks/Task page template) based on the /sitecore/templates/Sitecore Client/Tasks/Task option template. The Header field is just the text displayed on the UI and the Click field is the Sitecore command to execute when the utility link is clicked.

The command is normally in the form of category:command_name such as myproject:updateuserindex. This command needs to be defined either in the App_Config/Commands.config file or in a configuration include file. The command definition contains both the full command name and a .net type to instantiate when the command is executed. The .net type needs to inherit from Sitecore.Shell.Framework.Commands.Command and override the Execute method.

If we have a short process to perform then we could perform that process from this method, then use something like the ClientResponse.Alert method to pop up a javascript alert dialog to let the user know the outcome of the process (success, failure, etc). If it’s a lengthy process you could also kick off a job here and then start a client pipeline which could make periodic requests to the server to get the status of the job and display. For my example here I’m going to launch a sheer wizard to kick off the process. Sheer UI also provides a facility to periodically update the user on the progress of the job. Another reason I chose a wizard here is because it’s what the user would expect. None of the other utilities in the control panel execute the desired process directly, they launch up either a dialog or a wizard. A wizard is also a great idea if you need to collect information from the user to execute the process.

To have my wizard open and display in a modal dialog, launch the dialog with the following from within the Execute method of the command.

Context.ClientPage.ClientResponse.Broadcast(
  Context.ClientPage.ClientResponse.ShowModalDialog(
  "/sitecore/shell/default.aspx?xmlcontrol=RebuildUserSearchIndex"),
  "Shell");

The xmlcontrol parameter in the url needs to refer to a sheer control. Inside our sheer layout file (XAML like file with XML extension) the control name is given as the child of the root “control” element.

<control xmlns:def="Definition"
  xmlns="http://schemas.sitecore.net/Visual-Studio-Intellisense">
  <RebuildUserSearchIndex>
  </RebuildUserSearchIndex>
</control>

Note that because we’re not going to use this control in a presentation definition inside Sitecore, then we don’t need to register the control using the developer centre. We can just write it and as long as the XML file is in the correct location Sitecore will pick it up.

It’s a little funny how the sheer engine works, but it’s this element name that matters. Sheer doesn’t locate controls by filename, so it doesn’t actually matter what I call the file in which this control is defined, or even where I put it. As long as the location in which it exists is included in the controlSources element in web.config. It’s pretty safe to put your file below the /sitecore/shell/controls folder as this folder is required by Sitecore itself and is already included.

Sheer UI has built in support for wizards, so immediately inside my control name tag I can define a control of type WizardForm.

<WizardForm
  CodeBeside="MyProject.RebuildUserSearchIndex,MyProject">
</WizardForm>

Note the CodeBeside attribute in which I define the type which handles the forms behavior. Now I can fill in the pages of the wizard. A wizard form consists of a number of pages including a first page and a last page. The first page normally describes to the user what the wizard does and the last page provides a summary of the process that was executed. The first and last pages are given inside the WizardForm element with WizardFormFirstPage and WizardFormLastPage elements respectively. All the other pages will be given by WizardFormPage elements.

In my simple example above I will have 3 pages. The first page describing that the index will be rebuilt, a progress page to show the user the process is indeed executing, and the final page providing a summary of the operation. I’ll define my pages (and complete the rest of my XAML file) with the following which is inserted inside the WizardForm element.

<WizardFormFirstPage ID="FirstPage" Icon="People/32x32/User1.png">
  <Border Class="scWizardWelcomeTitle">
    <Literal ID="Welcome" Text="Welcome to the User Search Index Wizard."/>
  </Border>
  <Literal Text="This wizard helps you:"/>
  <ul>
    <li class="scWizardBullet">
      <Literal Text="Rebuild the user search index."/>
    </li>
  </ul>
  <Literal Text="To begin, click the 'rebuild' button below"/>
</WizardFormFirstPage>

<WizardFormPage ID="Rebuild" Header="Rebuilding"
  Text="This may take a few minutes." Icon="People/32x32/User1.png">
  <Edit Mode="Hidden" ID="JobHandle" Width="0" Height="0"/>
  <GridPanel Width="100%">
    <Space Height="64"/>

    <ThemedImage Src="People/48x48/User1.png" Width="48" Height="48"
      GridPanel.Align="center"/>

    <Space Height="16"/>

    <Border Align="center">
      <ThemedImage Src="Images/progress.gif" Width="94" Height="17"/>
    </Border>

    <Space Height="16"/>

    <Border Align="center" GridPanel.Align="center" GridPanel.Style="font-weight:bold">
      <Literal Text="Rebuilding..."/>
    </Border>

    <Space Height="16"/>

    <Border Align="center">
      <Literal ID="StatusMessage"/>
    </Border>

  </GridPanel>
</WizardFormPage>

<WizardFormLastPage ID="LastPage" Icon="People/32x32/User1.png">
  <Border ID="SuccessMessage">
    <Literal Text="The index has been rebuilt successfully."/>
  </Border>
  <Border ID="ErrorMessage">
    <Literal Text="The index rebuild failed." />
  </Border>

  <Border>
    <Literal ID="Status"/>
  </Border>
</WizardFormLastPage>

The WizardForm control provides the buttons and handling of switching pages of the wizard. You can also override the ActivePageChanged and ActivePageChanging methods to customise this behavior. By default the pages of the wizard are presented in the order in which they are defined in the XAML file. But using these method overrides you can conditionally skip certain pages. You can also cancel the transition in the ActivePageChanging method so you have opportunity to perform validation on user input.

If you’ve read the XAML above you’ll see that instead of having a “next” button on the welcome screen, I want to have it labelled “rebuild”. I also want to disable the navigate buttons when the index is being rebuilt. The following ActivePageChanged method will achieve this.

protected override void ActivePageChanged(string page, string oldPage)
{
  base.ActivePageChanged(page, oldPage);

  NextButton.Header = "Next >";

  if (page == "FirstPage")
    NextButton.Header = "Rebuild";

  if (page == "Rebuild")
  {
    BackButton.Disabled = true;
    NextButton.Disabled = true;
    StartRebuild();
  }
}

Note I also kick off the rebuild process when we change to the “Rebuild” page. I’ll run the rebuild in a job which is a background thread. This way the job can run asynchronously and my request can return.

private void StartRebuild()
{
  // Start job for index rebuild
  var options = new JobOptions("Rebuild User Search Index",
    "IndexRebuild", Context.Site.Name, this, "RebuildIndex");
  var job = JobManager.Start(options);
  JobHandle.Value = job.Handle.ToString();

  // Start client pipeline to check progress
  Context.ClientPage.ClientResponse.Timer("CheckStatus", 500);
}

When creating a JobOptions object you can specify an object to run your process as well as the method to invoke on that object (last 2 parameters in the above call). So the rebuild will be run using this form and calling the “IndexRebuild” method on it. The Timer method call down the bottom causes the client to wait the specified time (second parameter, milliseconds) then call the method given in the first parameter. So I’ll need to define the IndexRebuild and CheckStatus methods.

One of the nice things about Sitecore jobs is that they provide a way to update status across threads through the job’s Status.Processed property. There are a few ways to find an existing job when the call for CheckStatus comes in but I like to use the job handle of the job returned by the JobManager. I’ll need to store the handle so I also have access to it on the call to CheckStatus. For this I’ll use a hidden field and store the handle value in that.

To get access to the controls of the form we have to get a little “2003 old school” and define the variables in our code file. The controls come out of the Sitecore.Web.UI.HtmlControls namespace, so include a reference to that namespace at the top of your file, then inside your class define the controls as protected so they can be populated on the postback.

protected Edit JobHandle;
protected Literal StatusMessage;
protected Border SuccessMessage;
protected Border ErrorMessage;
protected Literal Status;

I won’t actually build the index in this example, as I’m only concerned with describing how to create such an application. Instead I’ll simulate the lengthy operation so we can witness the UI updating while the background thread runs.

private void RebuildIndex()
{
  // Simulate a lengthy operation so the client pipeline can execute
  Context.Job.Status.Processed = 0;
  for (int i = 0; i < 20; i++)
  {
    Thread.Sleep(500);
    Context.Job.Status.Processed++;
  }
}

So I update the processed count in the method above and I’ll read that status from the client pipeline server method.

protected void CheckStatus()
{
  var handle = Handle.Parse(JobHandle.Value);
  if (handle != null)
  {
    var job = JobManager.GetJob(handle);
    if (job != null)
    {
      StatusMessage.Text = "Processed: " + job.Status.Processed.ToString();
    }

    if (job.IsDone)
    {
      Active = "LastPage";
      ErrorMessage.Visible = false;
      Status.Text = StatusMessage.Text;
    }
    else
      Context.ClientPage.ClientResponse.Timer("CheckStatus", 500);
  }
}

This callback is also where we check on the status of the job and when complete move to the next page of the wizard by setting the “Active” property to the ID of the page you want to swap to. If the job isn’t finished we’ll tell the client to check the status in another 500 milliseconds.

And after you fill in the proper index creation method, you’re done! I know that may have been a little more work than the ugly util page that was whacked together above, but this wizard shows a lot of polish and enhances the user’s experience when using your solution. Not to mention the built in mechanisms for starting a background thread and having the client periodically check on the status of the running job. Once you get the hang of sheer you’ll be knocking out these wizards for those utils quicker than you can make that UX expert shake his head in dismay.

If you need some help with sheer, keep in mind that the XAML files are not compiled; meaning you can open up the XAML files for any of the Sitecore UI components. Especially when working with dialogs and wizards, the existing Sitecore controls are invaluable as a reference.

And here’s the final result in all it’s sheer glory!

Control panel showing my user search index rebuild option.

Welcome page of the wizard

Processing page of the wizard

Summary page of the wizard

Sitecore 6.2 was released last night in probably the quietest release Sitecore has done in a long time. Why am I saying it was a quiet release? Well I had no idea it was coming and only found out after reading John West’s blog and finding a reference to the new version hidden in one of his posts. Normally I should get an email from Sitecore about new releases, but nothing.

So I’m doing my part for the publicising of Sitecore 6.2. I don’t normally post to tell you all about a release you probably already know about, but seeing as though I had no idea about 6.2 being released I’m assuming a lot of you haven’t heard yet either.

Anyway reading through the release notes for 6.2 I am filled with excitement. Some of the features I got a sneak peek at during an MVP only preview of Everest earlier this year. Let me point out a few here.

Word field type: Sitecore 6.2 includes a brand new field type; the word field. This field uses an Active X control to allow the user to use Word 2007 to edit text fields. This means users who are familiar with word can continue to use it. One caveat of this is of course that you’ll be lumped with Word’s awful HTML generation. So if you really don’t care about compliancy, then go for it .

WebDAV for drag and drop support of uploading media files: Sitecore 6.2 adds support for webDAV which allows users to drag media files straight from their desktop into the IE window and have those files uploaded into the media library. No more clicking around dialogs, just drag your files onto the Sitecore window.

Zipped icon files: When copying or zipping a Sitecore install folder, what takes the most time? The icon files of course. Sitecore has included since version 5 a very comprehensive library of icon files, all in different resolutions to really provide a good looking UI. Each icon file is only small, but there are so many of them. And the number of files is what slows down those zip and copy operations. From memory a standard install of Sitecore 6.1 contained about 24,000 files. The standard install of Sitecore 6.2 contains only 7,500 files. This should really help when moving Sitecore installs around.

Index folder default location: This is a little trick I leant from Mark Cassidy. Previously in a default Sitecore install the index folder would exist below the web root. Problem was that at times when packages were being installed or publishes being run with the index updates running crazy IIS would restart the application due to too much file activity (or something like that). So to solve this issue you can add a setting named “indexFolder” which provides the location of the index folder. With the indexes outside the webroot the index updates no longer affect the stability of the IIS application. Well, Sitecore 6.2 by default has added this setting into web.config and moved the index folder below the data folder.

And of course there are a heap of other updates, enhancements and bug fixes. Just be careful about the breaking chances in the API (mostly to do with the analytics API, check the release notes).

There’s a few things going on at the moment in the world of Sitecore.

Firstly the Sitecore Australian and New Zealand user group is having it’s second user group meeting, this time in Sydney Australia on 28th October 2009. Tim Ward, Solution Architect for Sitecore Australia will be taking attendees through some of the new features of Sitecore 6.1 and some of the up coming features of Sitecore 6.2. Mark Stanton from Gruden will also be speaking to the group. Everyone is welcome to attend this event, you just need to RSVP to Tim at tiw@sitecore.net so he can make sure he has enough beer. You can view the invitation online at http://img36.imageshack.us/img36/3907/usergroupinvite2.jpg .

Kind of in conjunction with the user group meeting, we’re also holding a Sitecore module competition. So if you’re in Australia or New Zealand and you have an awesome module you’d like to share with the world (and score a cool prize for it too) then make sure you get your entries in before 28th October 2009 to either Tim or myself.

And something that will interest more than just Sitecore devs in Australia and New Zealand, do you remember the Html Agility Pack? Sitecore bundles this library and I’ve spoken previously about how to use this library to aid in testing static behavior controls in Sitecore. Some of you may have looked for info on this module or found it’s CodePlex page and been turned off due to it’s lack of recent activity. Well, those days are now over.

Jeff Klawiter has picked up Html Agility Pack and started working on it again to fix bugs and add features which have been requested. So it is no longer an abandoned project. You can help Jeff out by telling him about how you use this library and if you’ve found any bugs, nuances or have feature requests. Kudos to Jeff for picking this project up. I look forward to seeing how it evolves.

So, just a little recap of why you should use Html Agility Pack for your testing. It allows you to easily load in HTML and treat it as XML, no matter what HTML standard it was written to. The earlier standards such as HTML 4.01 allowed you to leave off closing tags in some circumstances like on a paragraph. You can’t load HTML 4.01 into an XML document for testing as it’s not valid XML. But Html Agility Pack hides all that from you and just allows you to treat it as if it were XML.

But wouldn’t you want to know if your HTML was badly formed? Shouldn’t you be testing every single character of your control’s output? Well, that depends on how pedantic you want to get, and can even come down to which .net controls you may have used for your build. I would recommend against testing every single character as it doesn’t matter for (X)HTML. (X)HTML doesn’t care if you have a newline between a closing and separate opening tag, or you indented that tag too much. And how much time do you really have to spend on getting the output “character perfect”?

Instead I would suggest you treat any validation of control output as a separate activity in your test. You can use Html Agility Pack to test the markup as the browser would treat it and then you can test the conformity of the output to standards using something like HtmlTidy or the W3C validator .

And before you go jumping into vast string manipulation to verify your output, remember that it is much easier to navigate the structure of the document as XML. Especially when it comes to checking the value of an attribute on a tag. Rather than Substring and IndexOf I can just use XPath to find the attribute value.

Sitecore has done a very good job of making item management in Sitecore very much like file management in your OS. Operations such as moving items, ordering items, copying and pasting items is as simple as a drag or a click. All this works quite well, but only for the current server you’re on.

If you have a look at the data on the clipboard after a copy command has run you’ll see it contains the ID of the item you wish to copy along with some meta data about the action to perform.

sitecore:copy:{39F265B4-1FF0-4DA2-BCA6-A3056D5BCCFE}

But often I find myself wanting to be able to copy an item from one server and paste it onto another. This normally happens when I want to pull specific content back from a QA or production server and paste it onto dev. Sitecore already provides a mechanism to do this; packages. But a package feels like a lot of effort when all I want is a single item (or tree).

So I got to working on a way in which to do this. My first thought was to alter the copy command to also place the URL of the server into the clipboard. Then provide a WCF service on the source server that the paste command could call to pull the data back. But after a little more consideration I worked out how to avoid the WCF service as well.

The Item class in Sitecore provides the ability to copy an item’s XML data, and create new items based on this XML through the GetOuterXml(bool) and Paste(string, bool, PasteMode) methods respectively. So if I could get the item’s entire data onto the clipboard, there would be no need for a WCF service.

First things first. Let’s create our custom copy command which will copy the item’s XML onto the clipboard. Our CopyItemXml command will extend Sitecore.Shell.Framework.Commands.ClipboardComman as we’ll be using the clipboard. We’ll also override the Execute and QueryState methods. The heavy lifting of the Execute method will be done in another method to allow us to run client pipelines to prompt and receive input from the user.

public override CommandState QueryState(CommandContext context)
{
  if (!ClipboardCommand.IsSupported(false))
    return CommandState.Hidden;

  if (context.Items == null || context.Items.Length == 0)
    return CommandState.Disabled;

  if (!context.Items[0].Access.CanRead())
    return CommandState.Disabled;

  return base.QueryState(context);
}

The QueryState method is called by Sitecore to determine what state to give the command in the UI such as hidden, disable or enabled.

public override void Execute(CommandContext context)
{
  if (ClipboardCommand.IsSupported(true) &&
    context.Items != null && context.Items.Length >= 1)
  {
    var parameters = new NameValueCollection();
    parameters.Add("id", context.Items[0].ID.ToString());
    parameters.Add("dbname", context.Items[0].Database.Name);
    parameters.Add("initialCall", "1");
    Context.ClientPage.Start(this, "Run", parameters);
  }
}

The Execute method does a few checks to ensure this command is supported by the browser (clipboard access) and then starts the client pipeline with the appropriate parameters.

protected void Run(ClientPipelineArgs args)
{
  if (args.Parameters["initialCall"] == "1")
  {
    args.Parameters["initialCall"] = "0";
    Context.ClientPage.ClientResponse.YesNoCancel(
      "Do you want to copy the children as well?", "200", "100");
    args.WaitForPostBack();
  }
  else
  {
    if (args.Result == "yes" || args.Result == "no")
    {
      var includeChildren = args.Result == "yes";
      var db = Sitecore.Configuration.Factory.GetDatabase(
        args.Parameters["dbname"]);

      if (db == null)
      {
        SheerResponse.Alert("Failed to locate target database");
        return;
      }

      var item = db.GetItem(args.Parameters["id"]);
      if (item == null)
      {
        SheerResponse.Alert("Failed to locate source item");
        return;
      }

      var data = item.GetOuterXml(includeChildren);
      data = data.Replace("\\", "\\\\");
      data = data.Replace("\"", "\\\"");
      data = EscapeEscapables(data);

      SheerResponse.Eval(
        "window.clipboardData.setData(\"Text\", \"" + data + "\")");
    }
  }
}

The Run method first checks to see if this is the first call to the method as a result of starting the client pipeline. If it is it sets into the response to prompt the user if they wish to also copy the children of the current item. If this is not the initial call then we grab the parameters, perform some error checking then find the source item and copy it’s XML data onto the clipboard. Note the formatting calls on the data variable towards the end of that method which will help escape the XML data to be shot back down to the browser in the response and executed in javascript. And here’s the EscapeEscapables util method which is also used.

private string EscapeEscapables(string input)
{
  var builder = new StringBuilder();
  builder.Append(input);
  builder.Replace("\r", "\\r");
  builder.Replace("\t", "\\t");
  builder.Replace("\n", "\\n");
  return builder.ToString();
}

Now we need to bind this command into the UI so we can execute it from the content editor. I’ll add this new command to the context menu. You could also add it to a ribbon if you liked.

Log into the Sitecore desktop and swap over to the core database. Next, open a content editor and navigate down to /sitecore/content/Applications/Content Editor/Context Menus/Default item. Here you can either create a new menu item definition, or copy the existing copy menu item definition. Either way the most important fields to fill in of the menu item are as follows:

The Message field specifies a command to execute when this menu item is clicked. This command name needs to map to our custom copy class above in the App_Config/commands.config file. Open that file and scroll down until you find the existing item:copy command, then copy that line and adjust it as follows:

<command name="item:copyXMLtoclipboard"
  type="CustomCommands.CopyItemXML,CustomCommands" />

That’s the first half done. We now have a custom command on the content editor context menu which can be used to copy an item’s XML data onto the clipboard.

Now we have the data on the clipboard we need to create the paste menu item to handle pasting the item data onto a different server. But rather than creating a brand new menu item, command and command class, why not just extend the existing paste command to be able to deal with item XML data as well?

public class ExtendedItemPaste :
  Sitecore.Shell.Framework.Commands.PasteFromClipboard

I know the normal paste command above is structured very similarly to the copy command we created. So I can leave the QueryState method and Execute method alone and just override the Run method which is invoked as a result of the Execute method running a client pipeline.

protected new void Run(ClientPipelineArgs args)
{
  if (args.Parameters["fetched"] == "0")
  {
    args.Parameters["fetched"] = "1";
    Context.ClientPage.ClientResponse.Eval(
      "window.clipboardData.getData(\"Text\")").Attributes["response"] = "1";
    args.WaitForPostBack();
  }
  else
  {
    if (args.Result.StartsWith("<item "))
    {
      var db = Sitecore.Configuration.Factory.GetDatabase(
        args.Parameters["database"]);

      if (db == null)
      {
        SheerResponse.Alert("Failed to locate target database");
        return;
      }

      var parent = db.GetItem(args.Parameters["id"]);
      if (parent == null)
      {
        SheerResponse.Alert("Failed to locate parent item");
        return;
      }

      parent.Paste(args.Result, false, PasteMode.Merge);
    }
    else
      base.Run(args);
  }
}

In the paste method we need to use the ClientResponse.Eval method in conjunction with the ClientPipelineArgs.WaitForPostBack method to pull the data off the clipboard in javascript and return the result to our method. Next we check to see if the data from the clipboard is item XML or not. If it is we will handle it, otherwise let the default paste class handle it.

Now I have to override the existing command to use my new command class. Open the App_Config/commands.config file and find the command definition with name item:pastefromclipboard. Replace the type attribute with our ExtendedItemPaste command from above.

<command name="item:pastefromclipboard"
  type="CustomCommands.ExtendedItemPaste,CustomCommands" />

Now when we paste, the paste command will recognise the item XML and create new items based on that. To get the most out of this you’ll want to set up another server with these custom commands so you can copy from one server and paste to the other. If you paste onto the same server you’ll notice that no new item is created. This is because of the second parameter we’re passing to the Item.Paste method, changeIDs. If this parameter were true then the IDs in the XML would be replaced with new IDs and new items would be created. By not changing the IDs the existing item will have it’s data and fields updated from the XML. I left this parameter as false as the issue I am trying to solve with this solution is to be able to copy items from one server to another. I retain the original ID incase something else references this item by ID rather than name or path.

But if you really wanted new IDs you could change the paste code to set changeIDs to true, or even better, prompt the user using the same technique as used in the copy command to ask if they want new items or update existing (if found).

So my original issue is solved right? Well…if you’ve tried this technique using 2 separate and different servers you may have noticed 1 significant issue. If the template which the item is based on does not exist on the target server then my new item will not contain any fields.

So to have a full solution I should really grab the item’s template too. What about the template’s base template (and there could be multiple of those)? What about any references the item might use such as droplists or link fields to internal items? What about the presentation components used by the item (renderings, layouts, sublayouts, etc)? What about media? …

As you can see, once you start down the dependency paths you realise how big the graph can be. The easiest thing is to draw some definite boundries around what you will include in a copy and what you won’t. Below is a quick list of things that you might want to include and whether you easily can include them onto the clipboard as text.

For my solution I’ll draw the following boundaries. I’ll copy the item (and children if required), the template hierarchies of the items and any item references. Basically just the data required to support my copied item.

The following shows my completed CopyItemXML command class.

using System.Collections.Generic;
using System.Collections.Specialized;
using System.Text;
using Sitecore;
using Sitecore.Data.Items;
using Sitecore.Shell.Framework.Commands;
using Sitecore.Web.UI.Sheer;

namespace CustomCommands
{
  public class CopyItemXML : ClipboardCommand
  {
    public override void Execute(CommandContext context)
    {
      if (ClipboardCommand.IsSupported(true) &&
        context.Items != null && context.Items.Length >= 1)
      {

        var parameters = new NameValueCollection();
        parameters.Add("id", context.Items[0].ID.ToString());
        parameters.Add("dbname", context.Items[0].Database.Name);
        parameters.Add("initialCall", "1");
        Context.ClientPage.Start(this, "Run", parameters);
      }
    }

    public override CommandState QueryState(CommandContext context)
    {
      if (!ClipboardCommand.IsSupported(false))
        return CommandState.Hidden;

      if (context.Items == null || context.Items.Length == 0)
        return CommandState.Disabled;

      if (!context.Items[0].Access.CanRead())
        return CommandState.Disabled;

      return base.QueryState(context);
    }

    protected void Run(ClientPipelineArgs args)
    {
      if (args.Parameters["initialCall"] == "1")
      {
        args.Parameters["initialCall"] = "0";
        Context.ClientPage.ClientResponse.YesNoCancel(
          "Do you want to copy the children as well?", "200", "100");
        args.WaitForPostBack();
      }
      else
      {
        if (args.Result == "yes" || args.Result == "no")
        {
          var includeChildren = args.Result == "yes";
          var db = Sitecore.Configuration.Factory.GetDatabase(
            args.Parameters["dbname"]);
          if (db == null)
          {
            SheerResponse.Alert("Failed to locate target database");
            return;
          }

          var item = db.GetItem(args.Parameters["id"]);
          if (item == null)
          {
            SheerResponse.Alert("Failed to locate source item");
            return;
          }

          var items = new List<Item>();
          var templates = new List<Item>();
          AddItems(item, includeChildren, true, items, templates);

          var data = GetXMLData(items, templates, item);
          data = data.Replace("\\", "\\\\");
          data = data.Replace("\"", "\\\"");
          data = EscapeEscapables(data);

          SheerResponse.Eval(
            "window.clipboardData.setData(\"Text\", \"" + data + "\")");
        }
      }
    }

    private void AddItems(Item item, bool includeChildren,
      bool includeReferences, List<Item> items, List<Item> templates)
    {
      // Add the item itself
      if (!ListContainsItem(items, item))
        items.Add(item);

      // Add any children (if required)
      if (includeChildren)
      {
        var children = item.GetChildren();
        for (int i = 0; i < children.Count; i++)
        {
          AddItems(children[i], includeChildren, false,
            items, templates);
        }
      }

      // Add references
      var links = item.Links.GetValidLinks();
      for (int i = 0; i < links.Length; i++)
      {
        var linkItem = links[i].SourceItemID == item.ID ?
          links[i].GetTargetItem() : links[i].GetSourceItem();

        var path = linkItem.Paths.FullPath.ToLower();
        if (!ListContainsItem(items, linkItem) && (
          path.StartsWith("/sitecore/content") ||
          path.StartsWith("/sitecore/templates")))
        {
          if (path.StartsWith("/sitecore/templates"))
            AddTemplateHeirarchy(linkItem, templates);
          else
            items.Add(linkItem);
        }
      }
    }

    private void AddTemplateHeirarchy(Item template, List<Item> items)
    {
      items.Add(template);
      items.AddRange(template.Axes.GetDescendants());
      var templateItem = (TemplateItem)template;
      for (int i = 0; i < templateItem.BaseTemplates.Length; i++)
        {
          if (templateItem.BaseTemplates[i].ID !=
            Sitecore.TemplateIDs.StandardTemplate &&
            !ListContainsItem(items, templateItem.BaseTemplates[i]))
            AddTemplateHeirarchy(templateItem.BaseTemplates[i], items);
        }
      }

    private bool ListContainsItem(List<Item> items,
      Item itemToFind)
    {
      return items.Exists(item => item.ID == itemToFind.ID);
    }

    private string GetXMLData(List<Item> items,
      List<Item> templates, Item rootItem)
    {
      var builder = new StringBuilder();
      builder.Append("<itemData>");
      builder.Append("<items>");

      for (int i = 0; i < items.Count; i++)
      {
        builder.Append("<itemData>");
        builder.Append("<path>");
        if (items[i].ID != rootItem.ID &&
          !items[i].Axes.IsDescendantOf(rootItem))
          builder.Append(items[i].Paths.FullPath);

        builder.Append("</path>");
        builder.Append(items[i].GetOuterXml(false));
        builder.Append("</itemData>");
      }

      builder.Append("</items>");
      builder.Append("<templates>");

      for (int i = 0; i < templates.Count; i++)
      {
        builder.Append("<itemData>");
        builder.Append("<path>");
        builder.Append(templates[i].Paths.FullPath);
        builder.Append("</path>");
        builder.Append(templates[i].GetOuterXml(false));
        builder.Append("</itemData>");
      }

      builder.Append("</templates>");
      builder.Append("</itemData>");
      return builder.ToString();
    }

    private string EscapeEscapables(string input)
    {
      var builder = new StringBuilder();
      builder.Append(input);

      builder.Replace("\r", "\\r");
      builder.Replace("\t", "\\t");
      builder.Replace("\n", "\\n");
      return builder.ToString();
    }
  }
}

You’ll see from above that I recursively (if required) collect the selected item and it’s descendants then on each item in the AddItems method I add any references as found in the links property of the item. For a good introduction to using the links database have a look at Mark Cassidy’s post Listing Related Articles with Sitecore using the LinkDatabase. Note how I’m only adding links under the content and templates sections of the content tree. The AddTemplateHeirarchy method adds the template hierarchy of the given item. When I construct the XML data I need to add the original path of any items not under the direct item being copied. Things like the templates and the references items need to be place in an appropriate location. I’ll use the path element in the paste command.

The following paste command is used to create items from this extended XML data block.

using System;
using System.Xml;
using Sitecore;
using Sitecore.Data;
using Sitecore.Data.Items;
using Sitecore.Web.UI.Sheer;

namespace CustomCommands
{
  public class ExtendedItemPaste :
    Sitecore.Shell.Framework.Commands.PasteFromClipboard
  {
    protected new void Run(ClientPipelineArgs args)
    {
      if (args.Parameters["fetched"] == "0")
      {
        args.Parameters["fetched"] = "1";
        Context.ClientPage.ClientResponse.Eval(
"window.clipboardData.getData(\"Text\")").Attributes["response"] = "1";
        args.WaitForPostBack();
      }
      else
      {
        if (args.Result.StartsWith("<itemData>"))
        {
          var db = Sitecore.Configuration.Factory.GetDatabase(
            args.Parameters["database"]);
          if (db == null)
          {
            SheerResponse.Alert("Failed to locate target database");
            return;
          }

          var parent = db.GetItem(args.Parameters["id"]);
          if (parent == null)
          {
            SheerResponse.Alert("Failed to locate parent item");
            return;
          }

          var doc = new XmlDocument();
          doc.LoadXml(args.Result);
          CreateTemplates(doc, db);
          CreateItems(doc, parent);
        }
        else
          base.Run(args);
      }
    }

    private void CreateTemplates(XmlDocument doc, Database database)
    {
      var templateNodes = doc.SelectNodes(
        "/itemData/templates/itemData");
      for (int i = 0; i < templateNodes.Count; i++)
      {
        var pathNode = templateNodes[i].SelectSingleNode("path");
        if (pathNode != null)
        {
          var path = pathNode.InnerText;
          var parent = GetParent(path, database);
          var itemNode = templateNodes[i].SelectSingleNode("item");

          if (itemNode != null)
            parent.Paste(itemNode.OuterXml, false, PasteMode.Merge);
        }
      }
    }

    private void CreateItems(XmlDocument doc, Item parent)
    {
      var itemNodes = doc.SelectNodes("/itemData/items/itemData");
      for (int i = 0; i < itemNodes.Count; i++)
      {
        var pathNode = itemNodes[i].SelectSingleNode("path");
        if (pathNode != null)
        {
          var path = pathNode.InnerText;
          var target = parent;
          var itemNode = itemNodes[i].SelectSingleNode("item");

          if (path != string.Empty)
            target = GetParent(path, parent.Database);
          else
          {
            if (itemNode != null)
            {
              var itemParent = parent.Database.GetItem(
                itemNode.Attributes["parentid"].Value);
              if (itemParent != null)
                target = itemParent;
            }
          }

          if (itemNode != null)
            target.Paste(itemNode.OuterXml, false, PasteMode.Merge);
        }
      }
    }

    private Item GetParent(string itemPath, Database database)
    {
      var parts = itemPath.Split(new string[]{"/"},
        StringSplitOptions.RemoveEmptyEntries);
      Item item = null;
      for (int i = 0; i < parts.Length - 1; i++) // Don't include last item
      {
        if (item == null)
          item = database.GetRootItem();
        else
        {
          var next = item.Axes.GetChild(parts[i]);
          if (next != null)
            item = next;
          else
            item = item.Add(parts[i],
              new TemplateID(Sitecore.TemplateIDs.Folder));
        }
      }

      return item;
    }
  }
}

In the Run method I load up the XML as an XML document which allows me to select the appropriate items out of the document for each operation. I also create the templates through the CreateTemplates method before I create the items which use the templates in the CreateItems method.

And there we have a slightly more robust solution.