Sitecore’s renderField pipeline is a supporting pillar for the Page Editor. The pipeline ties together XSL and .NET field rendering code into one and provides a single place to affect how each field type (rich text, image, link) is rendered on the website.

It doesn’t matter if the field is being output using XSL extension methods (sc:field, sc:image), XSL controls (<sc:text />, <sc:image />) or the new family of .NET web controls (Sitecore.Web.UI.WebControls.FieldRenderer, Date, Image, etc) – the renderField pipeline is always the one that provides the actual output.

How does this support the Page Editor? Whenever a page is being run in the page editor mode, the renderField pipeline knows that and renders additional html/javascript around each field.

How is the pipeline useful to you? The ability to hook into a field rendering process and modify the look of any field on a website is a powerful feature. For example you could completely change the way some or all images are rendered, or merely postprocess the rich text fields, like in the following example. This pipeline would also interest implementers of new field types, because it’s now possible to teach standard output methods to render third party fields types.

The code below checks all links rendered as a part of the rich text field and adds the “external” CSS class to all external links. This can be useful to style external links differently, like using different colors or adding an icon next to them.

public class MarkExternalLinks {
  public void Process(RenderFieldArgs args) {
    if (args.FieldTypeKey != "html" && args.FieldTypeKey != "rich text") {
      return;
    }

    if (!args.Result.ToString().ToLower().Contains("<a")) {
      return;
    }

    var firstPart = new HtmlDocument();
    firstPart.LoadHtml(args.Result.FirstPart);
    MarkLinks(firstPart);
    args.Result.FirstPart = firstPart.DocumentNode.OuterHtml;
  }

  private void MarkLinks(HtmlDocument document) {
    var nodes = document.DocumentNode.SelectNodes("//a");
    if (nodes == null || nodes.Count == 0) {
      return;
    }

    foreach (var node in nodes) {
      if (node.GetAttributeValue("href", string.Empty).Contains("http")) {
        var className = node.GetAttributeValue("class", string.Empty);
        if (className.Length > 0) {
          className += " ";
        }

        className += "external";
        node.SetAttributeValue("class", className);
      }
    }
  }
}

OK, what happens here? First, the check for the field type is performed. This processor is only designed to alter the output of html and rich text fields. If the field contains any links, output is being processed using the Html Agility Pack. The rendered field is stored in args.Result. The reason for having both FirstPart and LastPart is to render fields that can have other content embedded in them, such as general link; rich text fields only have the FirstPart.

Now the processor needs to be placed in web.config. I’m putting it just before the RenderWebEditing processor, so that it doesn’t affect the additional links rendered to support Page Editor. It’s also important that it comes after the GetLinkFieldValue processor:

<renderField>
  <processor type="Sitecore.Pipelines.RenderField.GetFieldValue, Sitecore.Kernel"/>
  <processor type="Sitecore.Pipelines.RenderField.ExpandLinks, Sitecore.Kernel"/>
  <processor type="Sitecore.Pipelines.RenderField.GetImageFieldValue, Sitecore.Kernel"/>
  <processor type="Sitecore.Pipelines.RenderField.GetLinkFieldValue, Sitecore.Kernel"/>
  <processor type="Sitecore.Pipelines.RenderField.GetInternalLinkFieldValue, Sitecore.Kernel"/>
  <processor type="Sitecore.Pipelines.RenderField.GetMemoFieldValue, Sitecore.Kernel"/>
  <processor type="Sitecore.Pipelines.RenderField.GetDateFieldValue, Sitecore.Kernel"/>
  <processor type="Sitecore.Pipelines.RenderField.AddBeforeAndAfterValues, Sitecore.Kernel"/>
  <processor type="Pipelines.MarkExternalLinks, Pipelines" />
  <processor type="Sitecore.Pipelines.RenderField.RenderWebEditing, Sitecore.Kernel"/>
</renderField>

Once again, here are the different ways of properly rendering a field:

1. sc:field XSL extension method, and the family of field type specific methods such as the sc:image, sc:link, sc:date and so on
2. XSL controls: <sc:text />, <sc:image />, <sc:date /> and so on
3. The Sitecore.Web.UI.WebControls.FieldRenderer web control, and a family of field type specific web controls, such as Sitecore.Web.UI.WebControls.Image, Date, etc [new]
4. The Sitecore.Web.UI.WebControls.FieldRenderer.Render() shortcut method. Use it when having the web control is not desirable, and you’d rather just have a string. [new]

It’s important to understand when the renderField pipeline is not used:

1. sc:fld XSL extension method returns raw field value, bypassing the pipeline.
2. Field values read using the Sitecore API (item[“FieldName”] or item.Fields[“FieldName”].Value) also return raw values.
3. Any static html included in the aspx or ascs files is also not processed.

Consequently, these are also the ways of supporting the new Page Editor in Sitecore 6: as long as you output the field using any of the options from the first list so that the renderField is used, you’re automatically getting the full Page Editor support.

In the next post I’ll focus on the new FieldRenderer web control and the family of field controls, added to make rendering fields in .NET to be as easy as using XSL controls.

I’m on vacation in Copenhagen, on 7-10th of September (i.e. next week).

I’ll be checking email from time to time: “alexey at this domain dotcom”.

Sitecore CMS 6.0.0 Update rev.080820 is released: http://sdn5.sitecore.net/SDN5/Resources/Sitecore%206/Sitecore%206.0.aspx.

The most notable fix is .NET 3.5 Service Pack 1 compatibility.

Sitecore comes with some keyboard shortcuts predefined. The purpose of this post is to compile a full list of these shortcuts and for a little extra, show how to define new ones.

Global Shortcuts

F9 – Publish
F2 – Expose (tiles all windows so that you can select the one you need)
Ctrl+/ – Focus in the startbar search

Content Editor Shortcuts

Tabs (hover over each tab to reveal the shortcut):

Alt+H – Home
Alt+N – Navigate
Alt+R – Review
Alt+P – Publish
Alt+V – Versions
Alt+C – Configure
Alt+E – Presentation
Alt+S – Security
Alt+I - View

Some ribbon commands have direct shortcuts. Most important one is Alt+F1, which reveals the shortcuts assigned to ribbon buttons:

F2 – Rename
F7 – Validation
F8 – Edit (Lock / Unlock)

Ctrl+S – Save
Ctrl+D – Duplicate

Ctrl+Shift+F – Launch the search application
Ctrl+Shift+Home – Move to the Home  item
Ctrl+Shift+Alt+L – Protect / Unprotect

Ctrl+Shift+Alt+Up – Sort Up
Ctrl+Shift+Alt+Down – Sort Down

Assigning New Ribbon Shortcuts

Each item representing a ribbon button has a KeyCode field, accepting a shortcut string. How to build this shortcut string?

First, you need to know they keycode corresponding to each key. This is the code used by the javascript event model, and here you can find a list of these keycodes. Then, if Shift, Control or Alt buttons are involved in the shortcut, prepend the code with “s”, “c” and “a”  respectively.

Examples: Ctrl+S is translated into c83 - c for control, 83 for “s”. Ctrl+Shift+Alt+Down is sca40 – s for Shift, c for Control, a for Alt and 40 is the keycode for the down key.

As an exercise, lets assign a shortcut to start the page editor. Page Editor button belongs to the Publish chunk in the Content Editor ribbon. So switch to the core database, and go to the /sitecore/content/Applications/Content Editor/Ribbons/Chunks/Publish/Page Editor.

The shortcut I want for the Page Editor is Ctrl+Shift+E. This translates into sc69 shortcut string (s for Shift, c for Control and 69 is the keycode of “e”), so write “sc69” in the KeyCode field.

That’s it. Not only pressing Ctrl+Shift+E will start the page editor from now on, but pressing Alt+F1 will also reveal the shortcut along with the ones that came predefined with Sitecore.

I’m really excited about ubiquity: http://labs.mozilla.com/2008/08/introducing-ubiquity/ is definitely worth a few minutes if you care about where the web is going.

I loved Aza Raskin’s Enso launcher and wrote a few commands for Enso 2 prototype but it was too buggy to use. I envy mac users because they have quicksilver.

But now Aza, being the head of user experience in Mozilla Labs, has found a perfect place to push his ideas forward: firefox, the best cross-platform browser.

I’m sure some people have noticed that the Sitecore Package Designer contains a “Post Step” field. How can that be used and what for?

The Post Step lets you input a method to be run after the package has been installed.

To make it work, you need a class that either already exists on the target Sitecore or is in the assembly that is installed with the package.

The class should implement Sitecore.Install.Framework.IPostStep interface that has a single RunPostStep(ITaskOutput output, NameValueCollection metaData) method.

Your code will run in the “shell” site. What’s more important, it will run in the background thread, so you cannot use the ClientResponse or SheerResponse methods. Instead, the output parameter provides a few basic methods of interaction, such as showing the alert box or a confirm dialog.

Below is a trivial example that renames the home item after the package installation:

public class Sitecore6Patch2 : IPostStep {
  public void Run(ITaskOutput output, NameValueCollection metaData) {
    var home = Context.ContentDatabase.GetItem("/sitecore/content/home");
    if (home != null) {
      home.Name = "Home upgraded";
    }
  }
}

Note: the above example is for Sitecore 6. In Sitecore 5, your class should have a parameterless RunPostStep method instead, which is also supported in Sitecore 6 for compatibility purposes.

Have you seen or used the Sitecore Poll module? Got any complaints, suggestions or feature requests? Mail ar at sitecore dot net or leave them here in comments. The feedback will be put to good use. Go.

A little known fact is that Sitecore 6 comes with Prototype and Firebug lite preinstalled. Prototype is a mind saving javascript library, and firebug lite is a helpful javascript instrumentation console replacing dozens of alert(“I’m here”) calls.

We’d do it for ourselves anyway, but what does it mean for you?

Prototype

Prototype javascript library is automatically included in Sitecore shell applications – both native, such as Content Editor, and the custom ones.

This means you can safely use prototype both in your Sitecore customizations, such as custom fields, and in your own applications. (If you look closely enough, you’ll see that custom FieldTypes I’ve made for Crestone shamelessly use prototype whenever possible).

Needless to say that prototype is great and saves a lot of brain cells if you do any javascript at all. Some great alternatives, such as jQuery, do exist – but if you don’t use anything at all, I really wonder why.

If you’re new to prototype and javascript frameworks in general – they have very solid documentation at http://prototypejs.org/.

Even more, prototype’s cousin – Scriptaculous, a javascript UI controls and effects library is also shipped with Sitecore, but is not included automatically. If you need it, it’s at /sitecore/shell/Controls/Lib/Scriptaculous.

Firebug Lite

Firebug lite is a cross browser javascript console – the fact that it works in Internet Explorer is of biggest interest to Sitecore developers. I’ve praised it before, but now it’s one key press away in Sitecore shell applications.

Press F12 and the firebug lite console will pop up from the top:

This means you can use console.log and other instrumentation methods to debug your javascript.

Sitecore UI has a lot of IFrames, so pay attention where you click before opening the console – each IFrame is a separate javascript realm, and therefore has its own firebug console.

The Website is Safe

I’d like to stress again that both Prototype and Firebug lite are only included in the Sitecore shell applications. Technically, if the sitecore.js javascript file is loaded, the prototype and firebug are also inlcuded.

We don’t add anything to the frontend sites – it’s your decision.

And in case you haven’t seen this elsewhere: Do not install the .NET 3.5 Service Pack 1 on any servers running Sitecore. Service pack updates the LosFormatter class which is responsible for viewstate serialization/deserialization in the ASP.NET, and it looks like they’ve introduced a subtle bug that hit us.

An official release:

Dear Sitecore Enthusiast,

You are receiving this message because you are subscribed to the Sitecore Product Issues and Patches mailing list.

On Monday, August 4th, Microsoft released the following service packs: Visual Studio 2008 SP1 and .NET 3.5 SP1.

Sitecore has discovered that these service packs introduce a bug in the LosFormatter class (System.Web.UI.LosFormatter in System.Web.dll, used to serialize and deserialize an ASP.NET ViewState). This bug causes stability issues in Sitecore products. Sitecore has raised this as an urgent priority issue with Microsoft (case number : SRQ080813600454) and is working to help resolve this issue.

In the meantime, PLEASE DO NOT INSTALL .NET 3.5 SP1 and Visual Studio 2008 SP1 on any server running a Sitecore product (including Sitecore WCMS, Intranet Portal, and Foundry) until further notice!

Symptoms associated with installing either of these service packs:

1. Memory consumption increases dramatically and single core CPU usage goes up to 100% when opening the Access Viewer or Media Library applications.
2. OutOfMemoryExceptions thrown in the Desktop and Content Editor.
3. The browser becomes unresponsive when accessing Sitecore.

Please be aware that Microsoft  may include this Service Pack as part of the monthly ‘Patch Tuesday’.  Please take steps to avoid the automatic installation of these service packs.

Please be aware that the final version of SQL Server 2008 will require .NET 3.5 SP1.

If you have any questions about this issue, please contact Sitecore support.

Best Regards,
Sitecore Support Team.

renderItemTitle is another presentational pipeline introduced in Sitecore 6, allowing to modify the appearance of item blocks, or tiles, in the folder views. Folder view is what you see on the right: a default tab on folder items. You can also add it to any other item by adding it to the Editors list.

Hooking into the renderItemTile allows changing the appearance of individual item tiles. Most often, however, customization scenarios include adding a few bits of information, relevant to all items or to specific item types.

This is how the pipeline looks out of the box (simplified):

<renderItemTile>
  <processor type="RenderFolderTile" />
  <processor type="RenderTemplateTile" />
  <processor type="RenderDefaultTile" />
</renderItemTile>

The RenderFolderTile and RenderTemplateTile add information relevant to folders (a number of subitems) or templates (a number of usages).

In this example, I’ll be adding information about a number of validation errors of the item.

The processor has to inherit from Sitecore.Pipelines.RenderItemTile.RenderTileBase. This base class is already capable of rendering a default item tile, so I’m just slightly changing its behavior to also output a number of validation errors.

public class RenderItemTile : RenderTileBase {
  public override void Process(RenderItemTileArgs args) {
    if (args.View != TileView.Tiles) {
      return;
    }

    base.Process(args);

    args.AbortPipeline();
  }

  protected override void RenderTileDetails(HtmlTextWriter output, RenderItemTileArgs args) {
    base.RenderTileDetails(output, args);

    var errorCount = GetErrorCount(args.Item);
    if (errorCount == 0) {
      return;
    }

    var message = errorCount > 1 ? "{0} errors".FormatWith(errorCount) : "1 error";
    output.Write("<div class="\"scTileItemDetailsLine\"" style="color: red">");
    output.Write(message);
    output.Write("</div>");
  }

  int GetErrorCount(Item item) {
    var errorCount = 0;

    var validators = ValidatorManager.BuildValidators(ValidatorsMode.Gutter, item);
    ValidatorManager.Validate(validators, new ValidatorOptions(false));

    foreach(BaseValidator validator in validators) {
      if (validator.Result >= ValidatorResult.Warning) {
        errorCount++;
      }
    }

    return errorCount;
  }
}

A few pieces to notice:

1. args.View defines the mode the pipeline runs in: Tiles, Large Icons, Small Icons, etc. Most of those are reserved for the future use and at the moment Sitecore only uses Tiles or IconOnly modes. In this customization, we’re after the Tiles mode.
   
2. A relatively simple RenderTileDetails method is overriden. This method is only responsible only for the information to the right of the icon. The general shape and style of the tile, as well as the icon, are handled by other more complicated methods, which we’re not interested in.
   
3. Note the usage of the new Validation API to validate the item: GetErrorCount method. Here I’m validating the item in the ‘Gutter’ (which is the old name for Quick Action Bar) mode. This means that the folder view will only run validators configured for the quick action bar (see the validation documentation on SDN and my post on validation for more)
   
4. Once the tile is rendered, the pipeline must be aborted, or the RenderDefaultTile processor will kick in and do it’s job.

As with other pipelines, Sitecore only knows about generic data concepts such as templates, folders and items. We cannot provide the customizations specific to the business domain of each site, but you can. The renderItemTile pipeline can be used to add information that describes each specific item type best: a publication date of the news item, a number of comments of the blog post or a discount percentage for a sales partner. And because it’s a pipeline, you can even display different information to different types of users.