Improving the usability of Sitecore’s bucket facets

My dear colleague Steve McGill pointed something out to me I never noticed before. However after noticing it I could not help but be extremely bothered about it.

A true case of:

what has been seen

(I might or might not be exaggerating just a tad here)

In any case, I’m talking about the search facets when searching for bucketable content in the Sitecore Content Editor:

search.png

So far so good. Lets select a couple of facets.

facets.png

It’s still not too bad – but now imagine if we’ve have multiple custom facets selected – especially booleans. The facet, when selected, would just say ‘0’ or ‘1’ – but we don’t know which facet this would be.

facets2

This is definitely less useful… So how can we make this more useful? The file that we’d be interested in changing here is webroot/sitecore/shell/Applications/Buckets/Scripts/ItemBucket.js.

A quick fix might be to change one line of code in that JavaScript. In line 263 (on Sitecore 8.1 update 2 at least) the line is:

facetList += '<li class="filter"><a href="javascript:void(0);" onclick="javascript:RemoveFacet(\'' + this.value + '\');" title="' + escapedText + '" class="facetClick facetClickSelected">' + innerText + "</a></li>";

Which we can change to (I’ve added the bold for emphasis):

facetList += '<li class="filter"><a href="javascript:void(0);" onclick="javascript:RemoveFacet(\'' + this.value + '\');" title="' + escapedText + '" class="facetClick facetClickSelected">' + this.value.split('|')[0] + ':' + innerText + "</a></li>";

‘this.value’ is simply the field name Sitecore facets on. I added ‘.split’ as well because it passes the value in there as well (so for English language facet it would pass ‘culture|en’).

facets3

This isn’t flawless either, since the ‘Author’ facet is using the ‘parsedcreatedby’ field in the index. If we wanted to change anything there we’d have to change the AppendFacet method in the same file to take in the display name of the facet as well (rather than the field).

One big consideration to keep in mind here is that we’re overriding a Sitecore file, which of course might change with future updates in Sitecore, so use with caution.

Content Editor – New window from here

If you ever have had to create a new item, but wanted to copy a bunch of text over from a different one you have had to either:

  • Copy the text, go to the new item, paste the text, save, rinse and repeat
  • Open a new window of the content editor, navigate to the item, select it and copy/ paste

I figured I could make this easier by creating something like ‘New window from here’, which will just pop up a new Content Editor window opening on the item I select.

This is actually very easy to do: I’d have to create a new command for my right-mouse click and implement a bit of code.

As always, the commands can be found in the Core database. The menu for the right-click is defined in /sitecore/content/Applications/Content Editor/Context Menues/Default (No, Menues is not a typo). I’ll create my command directly underneath the Insert button as displayed below.

 New command under the default folder

Now I need to make sure the correct command gets executed:

values

Notice I’m actually passing in an ID to my command as well. This is not required, but I wanted to show how to use that.
This leads to the following result when I right-click on an item:

menu

Now to the code. First of all, I’ll create a config file which I can stick in the Include folder:

<configuration xmlns:patch="http://www.sitecore.net/xmlconfig/">
  <sitecore>
    <commands>
      <command name="testapplication:newwindow" type="TestApplication.NewWindowFromHere.NewWindow, TestApplication" />
    </commands>
  </sitecore>
</configuration>

As always, beautifully named 😉

Next up: The NewWindow class. This class needs to inherit from the Sitecore.Shell.Framework.Commands.Command class and implement the Execute method at the very least, but the command can also be disabled if that’s required by overriding the QueryState method.

Option one, without the parameter:

public class NewWindow : Command
{
  public override void Execute(CommandContext context)
  {
    Assert.IsNotNull(context, "context");
    Assert.IsNotNull(context.Items, "items");
    if (context.Items.Length >= 1)
    {
      var parameters = new Sitecore.Text.UrlString();
      parameters.Add("id", context.Items[0].ID.ToString());
      parameters.Add("fo", context.Items[0].ID.ToString());

      Sitecore.Shell.Framework.Windows.RunApplication("Content Editor", parameters.ToString());
    }
  }
}

This code is pretty straightforward. We will build a UrlString and pass this along when we start the Content Editor. It’s worth noting  that the parameter in the Message field is not used here. In this case the Message field could simply be: testapplication:newwindow instead of testapplication:newwindow(id=$Target)

Option two, with the parameter being passed in:

public override void Execute(CommandContext context)
{
  Assert.IsNotNull(context, "context");
  Assert.IsNotNull(context.Parameters["id"], "id");

  var parameters = new Sitecore.Text.UrlString();
  parameters.Add("id", context.Parameters["id"]);
  parameters.Add("fo", context.Parameters["id"]);

  Sitecore.Shell.Framework.Windows.RunApplication("Content Editor", parameters.ToString());
}

I can get to the ID passed along in the parameters very simply, as you can see in line 4. In this case the Message field needs to be testapplication:newwindow(id=$Target), otherwise the Assert in line 4 would not pass.