This isn’t a huge release, but does have some important new features. Let’s take a look at each of these.

Support for Sitecore 6.6 (and Sitecore 7)

Sitecore 6.6 introduced some new security features to make the Sitecore client interfaces more secure. One such feature was to protect against cross site request forgery. Sitecore client UI forms now contain a field named __CSRFTOKEN which contains a token which must be posted to the server on each request.

Revolver 2.1 contains an update to submit this field when you execute a command in the Revolver script window. If you’ve tried using Revolver <= 2.0 with Sitecore 6.6 and received an error message mentioning something about missing a “CSRF” field, then make sure you upgrade to Revolver 2.1 to get the fix.

And although it’s not released yet, Sitecore 7 is on the horizon, so I’ve been testing Revolver with the Sitecore 7 release we lucky MVPs have. If you have access to Sitecore 7 and want to install Revolver on it, grab the current 2.1 release for Sitecore 6.6.

No spell check warning for script window

A small UI tweak in Revolver 2.1 is to add the spellcheck="false" attribute to the main script window text field to stop browsers from trying to run spell check on the contents of the script window. Most of what you enter in the script window is not plain English, so this tweak removes the sea of red you would have put up with in Revolver <= 2.0 in some browsers.

“Does not contain” operator for expressions

Expressions in Revolver are like predicates in XPath. They allow defining a condition when using the find command. There are a number of operators available in expressions such as comparing equality, starts with and ends with and check whether a string contains another. One scenario that couldn’t be implemented with those operators was to check the absence of a token from input. “Show me items where __renderings doesn’t contain this ID”.

The find command also supports testing field values against a regex. Regex is great at finding patterns in text, but not very good at finding the absence of a pattern in text. Hence why I added the “doesn’t contain” (written as !?) operator to expressions.

The scenario I gave above about trying to find items without a specific ID in their __renderings field is exactly why I added this operator. I was trying to locate all items in a Sitecore solution where the __renderings field was populated but didn’t contain a particular control. With the new operator I can now use a command similar to the following to locate these items:

find -r -e (@__renderings != () and 
  @__renderings !? {885B8314-7D8C-4CBB-8000-01421EA8F406}) pwd

The above Revolver command will show me the path to all descendant items (from the current context item) that has presentation defined but does not include the control given my the ID {885B8314-7D8C-4CBB-8000-01421EA8F406}.

Preserve ID when pasting from XML

Revolver has allowed you to create items from Sitecore item XML for a while now. And now you can select to keep the IDs in the input XML string. Previously Revolver was changing the IDs to ensure there were no item ID clashes. But what if the XML being pasted came from another Sitecore instance and the ID of the items are vital; perhaps they’re referenced from another XML blob you’re about to paste.

You can now tell Revolver to keep the IDs but using the -id flag when using the touch command to create the items as follows:

touch -id -x (item-xml)

where item-xml is actual Sitecore item XML (you can get that using the gi command).

Conclusion

Like I said, not a huge release, but now supporting Sitecore 6.6.

This is very handy for changing or cleaning up an item once the author has signaled that they’re happy with it (by hitting the save button). Just a side note, don’t do your validation here, use item or field validators instead.

Something that is often done using the item:saved event is to move the item to an appropriate structure. Some may say this is good for SEO, but we do it in Sitecore as a performance measure. Sitecore performance (particularly in the content editor) can degrade if too many items exist under a common parent item. There are various guidelines floating about for the maximum number of child items that should be allowed under a common parent but I generally say try to keep it to less than 100 and definitely less than 200 (less is better).

When we talk about “structuring” an item we generally mean placing it into an item hierarchy of several levels. Each level in the hierarchy is related to some aspect of the item. If the item represents a person then the hierarchy levels may represent letters in their name (the person “John Smith” goes in /person/s/john smith). If the item is date based the levels may represent elements of the date (an event goes in a year folder, then a month folder such as /event/2013/November/my-event).

Let’s say we have a news item with a field called News Date which contains the date the news is being reported on. I prefer a separate date for this kind of item rather than inferring the news date from the updated or created fields as news can be authored ahead of time (press release) or may need to have minor updates made that shouldn’t affect the “date” of the item (fix a spelling mistake). Now we want to structure the news in a hierarchy based on the News Date field.

Though this is good for performance we now have a single piece of data replicated in two places; once in the field and once in the structure. We need to ensure these two instances of the same data are kept in sync. And believe me, don’t trust your authors to ensure they keep the news in the right location.

The easiest way to ensure the date field and structure are kept in sync is by using the News Mover module from the Sitecore Marketplace. This module will move the item to a folder structure based on the date selected in the configured field by hooking into the item:saved event.

Awesome! We’ve got a way to ensure no news item is created in a flat structure…but what if we didn’t anticipate the volume of items beforehand and now we have 700 news items directly under the news root item before the News Mover module was put in place? Adding event handlers after the fact doesn’t retrospectively execute the handlers for any items.

(OK, not quite 700 items in my example screenshot but you get the idea.)

We need a way to execute the item:saved event for all those items without manually going through and hitting that save button 700 items. We can do that with Revolver!

To process a number of items at once I can use one of the find, query or search commands. For this case I’ll use the find command as it uses content tree traversal so I can be sure all my items will be processed.

Next I need a way to save the item. This can be done by updating a field value. But I don’t really want to change anything on the item, I just want to invoke the save event. For setting a field value in Revolver I can use the sf command which also allows me to use the previous field value in the new field value through the token $prev$.

Let’s put it all together.

First I need to navigate down to my news root item. Let’s assume this lives at /sitecore/content/my-site/news.

cd /sitecore/content/my-site/news

Now to execute the find command on all the children of that item.

find (sf -nv __updated ($prev$))

I’ve specified no parameters to find so it will process all children. If I wanted all descendants I would need to add the -r parameter. The parameter passed to find (enclosed in brackets) is the command to execute against each matched item; the sf command. This command will set the value of the __updated field to the current (previous) value. Incidentally this actually has no affect as Sitecore will update the field value immediately after we update the field value to show when it was last updated. The -nv parameter causes Revolver to not create a new version before updating the field value. By setting the field value the item:saved event is raised and News Mover can restructure the news items.

I am happy to say that my first eDynamic blog post has been published, which talks about always selecting a publishing target in Sitecore. This article talks about various options for making sure content authors always publish their content to a content staging publishing target before publishing the content to the web.

Rather than pollute the web by repeating content on two separate blogs, not to mention diluting the SEO mojo, I’ll instead post a note here on Coffee => Coder => Code so all those interested can find the post.

This is evident in the default manner in which workflow works, and how authors push the content from workflow state to workflow state without needing to explicitly state who the content goes to. The workflow works without the authors having to pass the content along the line manually from person to person.

On the whole I think this approach is very good. Don’t get bogged down with individuals. An individual is a bottleneck. For example, people have a tendency to get sick, or go on holidays, or get distracted by more important things (more important to them anyway). I prefer Sitecore’s approach of role based workflow actors. Chances are there will be multiple users in the same role, all able to perform those defined actions in workflow. So if Johnny is unavailable, someone else can pick up the slack.

But sometimes we do need to be a bit more strict and rope individuals into the workflow process for various reasons. Take for example a review process of a piece of content where a subject matter expert (SME) must review the content for correctness and SMEs are so varied in their areas of expertise that it’s not appropriate to create roles for each or to create separate workflow states (or complete workflows) for each.

Well, Sitecore has broken out of the 60′s and added features to allow strict assignment of content to a user. This appears through the inclusion of the system field __owner. Being a Sitecore standard field (inherited through the standard template) you should interact with this field using the content editor buttons.

To view the existing item owner, look in the Quick Info section (top of the field list).

To change the owner, click the change button in the ownership chunk of the security tab. Clicking this button opens the user select dialog which allows you to search for and select a single user to assign ownership to.

In addition to this field, Sitecore contains a dynamic role to refer to the current item’s owner, the Creator-Owner role. This role will reference the user in the __owner field or if that field is empty it will fallback to the user who created the item (user referred to in the __created by field). We can assign security in workflow to the Creator-Owner role so only the item owner (or creator (or admin)) can act on the item.

Now, this is all sounding pretty good right. But it’s not quite what we’re after. Firstly, assignment of ownership of the item is not semantically what I want for the above scenario. The SME shouldn’t own the content, the content owner should remain as whomever wrote the article initially. I just want the SME to review the content for accuracy. What if we need several SMEs to review the content? The item owner field only allows selection of a single user account. But what I really need is review from a panel of SMEs.

The second issue with using the Creator-Owner role is in how this dynamic role is evaluated. Think about how you might implement the above scenario. You’d probably allow the worflowstate:write permission to the Creator-Owner role for the appropriate workflow state definition item right? Well, the dynamic role is evaluated against the item on which the security right is defined, in this case, the workflow state definition item. But what we require for our scenario is the item owner of the item in workflow, not the owner of the workflow state definition item, so we can’t easily implement this scenario using out of the box components.

Instead, we’ll need to follow the ideas I explored in another recent post of mine (which I also mentioned above), Dynamic Roles in Sitecore.

Firstly, I need to add a field to the data template for my items to allow me to select the user accounts that will be the reviewers of that piece of content. To allow specifying multiple accounts for the review I’ll make use of the Account Selector Field from the Sitecore Marketplace. This field allows the user to select multiple accounts using the familiar account selection dialog.

Using the Account Selector Field I’ll add a field to my base template called “reviewers”. Then using the techniques from my previous post I’ll implement a dynamic role that will read membership from this field. This will allow me to leverage the Sitecore security tools to implement this scenario (and make workflow tools work properly).

Firstly, adding the “reviewers” field.

The account selector field has various options to control how it behaves. In the source field I set the following options to allow multiple selection of user accounts only:

AllowMultipleSelection=true&OnlyUsers=true

Now onto the custom roles provider to expose a dynamic role called ‘item-reviewer’. And just to be different, today I’ll be writing my sample code in Boo.

namespace sc66sb

import System
import Sitecore.Security.Accounts

class ReviewerRoleProvider(SqlServerRolesInRolesProvider):
"""Role provider to expose 'item-reviewer' role"""

    override def GetAllRoles(includeSystemRoles as bool):
        # return normal roles
        for r in super.GetAllRoles(includeSystemRoles):
            yield r

        # return custom role
        yield Role.FromName("item-reviewers")

The class above extends the SqlServerRolesInRolesProvider and overrides the GetAllRoles() method to return our new item-reviewers role in conjunction with the roles provided by the base class.

In my previous post regarding dynamic roles I was also able to override the IsUserInRole() method to implement the logic of resolving the members of the dynamic role. This worked because role membership was statically determined; the users membership within a role didn’t change from item to item. In the SME scenario above membership to the dynamic item-reviewers role will change from item to item. The role provider doesn’t support returning different results per item. So we need to identify another appropriate class to override and insert our custom logic.

Sitecore uses the standard ASP.NET membership model. So to alter the evaluation of permissions a user has in the system I can simply extend the Sitecore.Security.AccessControl.SqlServerAuthorizationProvider class to alter this behavior and update configuration to use my new class.

namespace sc66sb

import System
import Sitecore.Data.Items
import Sitecore.Security.Accounts
import Sitecore.Security.AccessControl

class ReviewerAuthorizationProvider(SqlServerAuthorizationProvider):
"""Authorization provider to evaluate membership in 'item-reviewer' role"""

    _reviewerRole = Role.FromName('item-reviewers')

    override def GetItemAccess(item as Item, account as Account, \
        accessRight as AccessRight):
        res = super.GetItemAccess(item, account, accessRight)
        if res.Permission == AccessPermission.Allow:
            return res

        # if access denied for user, check item reviewers role
        if item["Reviewers"].Contains(account.Name) \
            and account.Name != _reviewerRole.Name:
            res = super.GetItemAccess(item, _reviewerRole, \
                accessRight)

        return res

In the above code I’ve overridden the GetItemAccess() method which evaluates the permissions for a specified account for a specified access right to a specified item. Initially the base class method is called to check if the user has access. If not, then I check if the user is included in the reviewers field and if so, return the permissions for the item-reviewers role.

The above customisations now allow an administrator to assign security permissions to our new dynamic role and also resolve access permissions for that dynamic role if the individual user doesn’t have access and the user is included in the reviewers field.

This covers off item security. But workflow security is a little different. When the item:write access right is resolved, Sitecore internally first checks that the user has item:write access on the item and then also checks to ensure the same account has workflowstate:write access to the current workflow state the item is in.

So why is the above authorization provider not adequate? This is similar to the Creator-Owner issue above. In the above authorization provider the item being checked for the access right holds the reviewers field. But we’re checking the workflowstate:write access right of the workflow state definition item itself, and the reviewers field is on the item in workflow, not the state definition item. So we’ll need to tweak the workflow engine to work the way we want.

Unfortunately the default Sitecore workflow class Sitecore.Workflows.Simple.Workflow cannot be overridden for the case above. The class does contain many virtual methods, but I need to override the GetAccess() method which is not virtual.

So instead of overriding the workflow, I’m going to wrap it as I did in another previous post on Get Your Workflow in Order. In that article I showed how the workflow can be wrapped by another class which simply passes the call onto the wrapped workflow, but the methods I want to tweak can be manually written.

Here is my wrapping “reviewer” workflow.

namespace sc66sb

import System
import Sitecore
import Sitecore.Data
import Sitecore.Data.Items
import Sitecore.Data.Managers
import Sitecore.Diagnostics
import Sitecore.Globalization
import Sitecore.Security.Accounts
import Sitecore.Security.AccessControl
import Sitecore.SecurityModel
import Sitecore.Workflows

class ReviewerWorkflow(IWorkflow):
"""Workflow implementation which allows use of the special 'item-reviewer' role"""

    _reviewerRole = Role.FromName('item-reviewers')
    _innerWorkflow as IWorkflow
    _database as Database

    Appearance as Appearance:
        get:
            return _innerWorkflow.Appearance

    WorkflowID as string:
        get:
            return _innerWorkflow.WorkflowID

    def constructor(innerWorkflow as IWorkflow, database as Database):
        _innerWorkflow = innerWorkflow
        _database = database

    def GetAccess(item as Item, account as Account, \
        accessRight as AccessRight) as AccessResult:
        res = _innerWorkflow.GetAccess(item, account, accessRight)
        if res.Permission == AccessPermission.Allow:
            return res

        if item["Reviewers"].Contains(account.Name) \
            and account.Name != _reviewerRole.Name:
            res = _innerWorkflow.GetAccess(item, _reviewerRole, \
                accessRight)

        return res

    def GetCommands(item as Item):
        Assert.ArgumentNotNull(item, "item");
        stateID = GetStateID(item)
        if stateID.Length > 0:
            return GetCommands(stateID, item)

        return array(WorkflowCommand, 0)

    private def GetStateID(item as Item):
        Assert.ArgumentNotNull(item, "item")
        workflowInfo = item.Database.DataManager.GetWorkflowInfo(item)
        if  workflowInfo != null:
            return workflowInfo.StateID

        return string.Empty

    def GetCommands(stateID as string):
        return GetCommands(stateID, null)

    def GetCommands(stateID as string, item as Item):
        Assert.ArgumentNotNullOrEmpty(stateID, "stateID")
        cmds = List[of WorkflowCommand]()
        stateItem = GetStateItem(stateID) as Item

        if stateItem != null:
            for cmd in stateItem.Children.ToArray():
                template = cmd.Database.Engines.TemplateEngine.GetTemplate(\
                    cmd.TemplateID)
                userAllowed = AuthorizationManager.IsAllowed(cmd, \
                    AccessRight.WorkflowCommandExecute, Context.User)

                reviewerAllowed = true
                if item != null \
                    and item["Reviewers"].Contains(Context.User.Name) \
                    and Context.User.Name != _reviewerRole.Name:
                    reviewerAllowed = AuthorizationManager.IsAllowed(cmd, \
                        AccessRight.WorkflowCommandExecute, _reviewerRole)

                if template != null \
                    and template.DescendsFromOrEquals(TemplateIDs.WorkflowCommand) \
                    and (userAllowed or reviewerAllowed):
                    cmds.Add(WorkflowCommand(cmd.ID.ToString(), \
                        cmd.DisplayName, cmd.Appearance.Icon, false, \
                        cmd["suppress comment"] == "1"))

        return cmds.ToArray()

    private def GetStateItem(stateId as string):
        iD = MainUtil.GetID(stateId, null)
        if iD == null:
            return null

        return GetStateItem(iD)

    private def GetStateItem(stateId as ID):
        return ItemManager.GetItem(stateId, Language.Current, \
            Sitecore.Data.Version.Latest, _database, SecurityCheck.Disable)

    def Start(item as Item):
        _innerWorkflow.Start(item)

    def Execute(commandID as string, item as Item, comments as string, \
        allowUI as bool, *parameters):
        return _innerWorkflow.Execute(commandID, item, comments, allowUI, \
            parameters)

    def GetHistory(item as Item):
        return _innerWorkflow.GetHistory(item)

    def GetItemCount(stateID as string):
        return _innerWorkflow.GetItemCount(stateID)

    def GetItems(stateID as string):
        return _innerWorkflow.GetItems(stateID)

    def GetState(item as Item):
        return _innerWorkflow.GetState(item)

    def GetState(stateID as string):
        return _innerWorkflow.GetState(stateID)

    def GetStates():
        return _innerWorkflow.GetStates()

    def IsApproved(item as Item):
        return _innerWorkflow.IsApproved(item)

Most of the methods just pass through to the wrapped workflow, but I override some of the methods. Firstly, I’ve overridden the GetAccess() method so if the user isn’t granted the access right desired and the user exists in the reviewer field, then return the permissions of the reviewer role. That handles access to the item when it’s in workflow. The remaining methods are to do with showing the correct workflow commands to the user. Overriding the command methods was more involved as the OOTB workflow uses many private methods to find the commands, which I also had to implement myself. This all starts with the GetCommands() method and it’s overloads. In particular, I needed to pass the current item in workflow to the GetCommands() method so I had access to the reviewers field.

The last piece of the puzzle is to override the workflow provider to return our custom reviewer workflow instead of the OOTB workflow.

namespace sc66sb

import System
import Sitecore.Data.Items
import Sitecore.Workflows
import Sitecore.Workflows.Simple

class ReviewerWorkflowProvider(WorkflowProvider):
"""Description of ReviewerWorkflowProvider"""
    public def constructor(databaseName as string, \
        historyStore as HistoryStore):
        super(databaseName, historyStore)

    override def GetWorkflow(item as Item):
        workflow = super.GetWorkflow(item);
        return (ReviewerWorkflow(workflow, Database) \
            if workflow != null else null)

    override def GetWorkflow(id as string):
        workflow = super.GetWorkflow(id);
        return (ReviewerWorkflow(workflow, Database) \
            if workflow != null else null)

Note how I am simply calling the base class implementation of the overridden methods to get the OOTB workflow, but then I wrap that with the reviewer workflow before returning.

To tie all these customisations into workflow I’ve added this config patch file to the App_Config\Include folder.

<configuration xmlns:patch="http://www.sitecore.net/xmlconfig/"> 
  <sitecore> 
    <rolesInRolesManager> 
      <providers> 
        <add name="sql"> 
          <patch:attribute name="type">sc66sb.ReviewerRoleProvider, 
sc66sb</patch:attribute> 
        </add> 
      </providers> 
    </rolesInRolesManager>
    <authorization>
      <providers>
        <add name="sql">
            <patch:attribute name="type">sc66sb.ReviewerAuthorizationProvider, 
sc66sb</patch:attribute>
        </add>
      </providers>
    </authorization>
    <databases>
        <database id="master">
            <workflowProvider hint="defer" type="Sitecore.Workflows.Simple.WorkflowProvider, 
Sitecore.Kernel">
                <patch:attribute name="type">sc66sb.ReviewerWorkflowProvider, 
sc66sb
                </patch:attribute> 
            </workflowProvider>
        </database>
    </databases>
  </sitecore> 
</configuration>

This config patch file changes the role provider to our custom role provider, changes the authorization provider to our custom provider and changes the workflow provider of the master database to use our custom workflow provider.

Now to see it all in action!

I have duplicated the sample workflow and adjusted security settings as follows:

In addition to the above workflow security I’ve also granted write, rename, create and delete access rights to the item-reviewers role to the home item and all descendants.

Now when I log in as an SME user, I do not currently have access to the item that is in this workflow in the review state:

Now log in as an admin and add the SME user above to the reviewers field:

Then refresh the SME users content editor and voila! The SME user who is included in the reviewers field, but has no direct access of their own, can now edit and review the item.

When I tried to perform any operation from my TDS project with Sitecore I would receive an error about the response content type, followed by an error to do with the version of the server components: “The content type text/html; charset=utf-8 of the response message does not match the content type of the binding (text/xml; charset=utf-8)”.

Clicking OK to dismiss this dialog showed the next error to do with the version: “Warning: The version of the sitecore connector is from an older version of TDS”

I tried everything I could think of to fix this issue. I used the “Install Sitecore Connector” option in my project context menu, I compared versions of the ASMX and DLL installed by TDS into my Sitecore folder and copied an updated version from another working Sitecore instance, I also applied a patch which was specific to a revision of Sitecore 6.4.

Eventually I logged the issue with Hedgehog support and they worked through the issue with me.

Now, keep in mind that TDS communicates with your Sitecore solution using a custom web service. The ASMX file resides under a folder called _DEV. Also in this folder is a web.config file containing the access GUID. An assembly is also added to your bin folder which contains the type used by the ASMX file.

Now, the fact that TDS uses a standard web service which communicates over HTTP is what saved me here. Hedgehog support suggested using an HTTP debugging proxy like Fiddler to look at the HTTP request and response. Good idea! This allowed me to see what was going on:

As you can see from the screenshot above, the request for the ASMX was being redirected to a lowercase version of the URL. This redirect strips the SOAP action header so instead of trying to execute a web method, this request turned into a GET request. BTW, this was on TDS 3. When writing this blog post I was testing against TDS 4 and it appeared the SOAP action was not stripped by the redirect, though the result was the same.

Now, you may recall I recently blogged about redirect components that can be used with Sitecore? Yeah. Here’s the gotcha. Make sure your redirect rules aren’t overzealous and process system/service requests rather than just limiting themselves to requests for content. The “administrator” modules I wrote about previously are not integrated into Sitecore, so they have no concept of a content request versus a service request. Instead, you’ll have to update your redirect rules so they ignore any requests that aren’t for content. The CMS modules are run from inside the CMS application, so by the time they get a chance to process the request they have already been processed by the CMS and you can be pretty sure that what you’re dealing with is a content request and not a service request which would have aborted before now.

In the above scenario I was using the IIS URL Rewrite module and I had a rewrite rule to redirect any request which contained an uppercase character to a lowercase version of the URL. This is a common SEO technique to help with canonicalization of the URLs on your site to ensure search engines don’t accidentally split your page ranking between several URLs differing only by case. This may seem funny to many Windows developers where we have a file system that ignores case, but to the rest of the world, including that of HTTP, case matters in both files and URLs, so search engines see /My-Page as a different URL to /my-page.

To fix the above TDS issue, I could update my rules to ignore anything in the _DEV folder, but a better solution would be to ignore any request for a web service endpoint; ignore any request ending in .asmx.

When creating your redirect rules for administrator modules (those configured outside of Sitecore), keep in mind that all requests will be processed by the redirect module.

Here’s a list of common exclusions you will probably need to work into your redirect rules when using a redirect module with Sitecore:

• Anything under the sitecore folder
• Anything under the temp folder
• Anything under the virtual ScriptResource folder
• Anything under the virtual WebResource folder
• Any URL ending in .axd
• Any URL ending in .asmx
• Any URL ending in .svc
• Anything under the layouts/system folder
• Any URL with sc_mode in the query string
• Any static resources on disk such as the codeflood embedded test runner (test.aspx file)

The IIS URL Rewrite module allows exclusions to be included in any rule through conditions. For a rule to apply to a request all conditions of the rule must be met. Here’s a sample configuration for a redirect rule for the IIS URL Rewrite module which includes the above exclusions.

<rule name="Lower Case Rule">
  <match url="[A-Z]" ignoreCase="false" />
  <conditions>
    <add input="{URL}" pattern="^/sitecore" negate="true" />
    <add input="{URL}" pattern="^/temp" negate="true" />
    <add input="{URL}" pattern="^/ScriptResource" negate="true" />
    <add input="{URL}" pattern="^/WebResource" negate="true" />
    <add input="{URL}" pattern="\.axd" negate="true" />
    <add input="{URL}" pattern="\.asmx" negate="true" />
    <add input="{URL}" pattern="\.svc" negate="true" />
    <add input="{URL}" pattern="^/layouts/system" negate="true" />
    <add input="{HTTP_URL}" pattern="\?.*sc_mode" negate="true" />
  </conditions>
  <action type="Redirect" url="{ToLower:{URL}}" />
</rule>

The “variables” in the input attribute of the condition entries (the names in curly braces) are server variables. You can find a list of common IIS server variables here: http://msdn.microsoft.com/en-us/library/ms524602%28v=vs.90%29.aspx.

If you’re using the UrlRewriter.net module, exclusions can be implemented through an unless element in configuration. The unless element is a conditional so no rules inside the unless will be processed unless the conditions of the unless are met.

Below is sample configuration for UrlRewriter.net implementing the same exclusions as above.

<unless url="^/sitecore|^/temp|^/scriptresource|
  ^/webresource|\.axd|\.asmx|\.svc|^/layouts/system|\?.*sc_mode">
  <if url="(?-i)[A-Z]+">
    <redirect url="(.*)" to="http://${HOST}${lower($1)}" processing="stop"/>
  </if>
</unless>

Note here how we only have a single attribute to put the condition in, which is in regular expression format. We could have implemented the IIS URL Rewriter configuration into a single regex as well, but I think splitting it out makes it much easier to read.

One nice aspect of the UrlRewriter.net configuration over the IIS URL Rewriter configuration is that you can wrap all rules in a single unless element, helping reduce the repetition of adding the conditions to several rules.

So next time you’re adding redirect rules, keep in mind the global implications.

var someObject = FindObject(); 
someObject.TheEvent += new EventHandler(MyEventHandler);

How that FindObject() method is implemented will depend on the context in which the method will be called (from a control, from a service, etc) and where the object being found resides (who owns it).

Bringing the problem to the realm of Sitecore, let’s start with a solid example.

Let’s say we have 2 sublayouts hosted on a page that need to communicate. The easiest way for one sublayout to find the other would be to expose a method to locate the second sublayout on a component that will host both sublayouts. This could be a parent sublayout if the two sublayouts will always be hosted within that sublayout, or a layout if there is no common parent control layer in the control tree.

The issue with this approach is that it’s quite rigid. Both sublayouts at some point need a common ancestor control to expose the method used to locate the sublayout exposing the event. This ties both sublayouts to that ancestor control for this approach to work. Not to mention the fact that the subscriber sublayout must know about the publisher sublayout and the ancestor control ahead of time.

This approach is tightly coupled, and we know that’s a bad thing…in some situations. On an implementation for a specific site this might be fine as all the components involved are part of the same project. But what if you’re a module developer (like me!) and need to expose events from your component and allow other developers to subscribe where there will not necessarily be a common ancestor control. Or what if you just want to avoid the hassle of all that wiring up?

Enter the Sitecore event pool. The Sitecore event pool allows disparate components to publish and subscribe to events easily. This is because the linking up of the subscriber to the publisher is done through the pool using an event name, thus decoupling the components. Well, loosely coupling them at least.

There are two ways to subscribe an event handler to an event in Sitecore. Firstly events can be subscribed to declaratively through a Sitecore configuration file. Entries in the /configuration/sitecore/events element define the events and show the event handlers for each event. Sitecore defines many events which are fired when things of interest happen in the system such as finishing a publish, adding a new user or saving an item. This is also a perfect example of a good use for decoupled events.

The second way to subscribe to an event is programmatically by calling the Sitecore.Events.Event.Subscribe(string, EventHandler) method. This method allows adding an event handler as a subscriber to an event given the event name.

OK, so that takes care of the subscription to the event, but what about firing the event? It’s as easy as calling the Sitecore.Events.Event.RaiseEvent(string, params object[]) method. One thing to note is that the name of the event (the first parameter) is arbitrary. It does not need to be defined in a configuration file.

Let’s put all this into context. Let’s say we have a sublayout which searches for content using a Lucene index. If I wanted to provide more information about the search results, such as a summary, I would normally have to update the sublayout. And if the sublayout was part of a module it complicates the issue as I’m not in control of the code that I need to update.

We can expose the search results from the sublayout doing the heavy lifting by raising an event. Other disparate code, from other modules or project specific, could then subscribe to the event and act on the parameters passed in the event arguments.

Onto the code. First, we’ll define a custom EventArgs class to expose the data relevant to the event.

public class CustomEventArgs : EventArgs
{
  public Item[] Items { get; set; }
}

Now we’ll raise the event in the sublayout that performs the search.

var args = new CustomEventArgs();
args.Items = GetSearchItems();
Sitecore.Events.Event.RaiseEvent("custom:searchresults", args);

And we’ll need to subscribe to the event in the summary sublayout.

var handler = new EventHandler(ResultHandler);
Sitecore.Events.Event.Subscribe("custom:searchresults", handler);

And the event handler itself.

protected void ResultHandler(object sender, EventArgs args)
{
  var customArgs = Sitecore.Events.Event.ExtractParameter(args, 0)
    as CustomEventArgs;
  ResultCount = customArgs.Items.Length;
}

Note how we extract the custom event args from the generic event args of the handler using the Sitecore.Events.Event.ExtractParameter() method.

Now, a little gotcha. When you subscribe to an event it creates a strong reference through the event handler. The strong reference will prevent the object containing the event handler from being eligible for garbage collection and the object will hang around for the lifetime of the application. While the object lives, the event handler will continue to respond to the event being raised. And in an ASP.NET application, with each request an instance of the sublayout codebehind (well, an derivative of the codebehind class) is created. Because previous instances are not garbage collected due to the strong reference, this actually looks like a memory leak. Memory usage will continue to rise over time.

To counter this, we need to ensure any events subscribed to programmatically are unsubscribed from. We can do this by storing the event handler reference in a member variable and unsubscribing from the event at a point later in the request lifecycle.

private EventHandler m_handler = null;

protected void Page_Load(object sender, EventArgs args)
{
  m_handler = new EventHandler(ResultHandler);
  Sitecore.Events.Event.Subscribe("custom:searchresults", m_handler);
}

protected void Page_Unload(object sender, EventArgs args)
{
  if(m_handler != null)
    Sitecore.Events.Event.Unsubscribe("custom:searchresults",
      m_handler);
}

And one more note, using this technique you’ll need to ensure your event subscriptions occur before any events are raised for that event, or you’ll miss handing that call of the event. This is quite easily done by having the subscriptions occur as early as possible, such as in the constructor of the class.

With this technique you now have components which are only loosely coupled, making it much easier to respond to the event.

Anyway, back to the release.

There have been lots of changes to the module in this update, so let’s cover them off, starting with the biggest change:

Revolver is Now Free!

Yes, I have removed the commercial licensing from the module. I am a huge supporter of open source software and I also use many open source tools. So it was kind of odd that I was going against open source and was holding the module as commercial. I’ve still got a bit of clean up I want to do in the codebase before releasing it into the wild, so I’m stopping short of going open source just yet, but I’m allowing it’s use free of charge.

This change in licensing was also encouraged by the other freely available scripting modules out there, the Sitecore Rocks Power Shell integration, Sitecore Rocks Query Analyser and the Power Shell Console. It was getting very hard to justify the cost of Revolver given the capabilities of the other modules.

Search Command

The new search command allows searching within the Lucene indexes. It works in the same fashion as the find and query commands. The command is used to locate items and then execute some command against each item.

So if we wanted to search for any items that contain “Lorem” in the title field (left over test data anyone?) and just print the path to the item, we could use the following command.

search title:lorem pwd

Note that the fields used in the search are Lucene fields, not Sitecore item fields.

Comms Notification

The Revolver application window now has a status bar to tell you when the client app is communicating with the server. This helps inform you about whether Revolver is waiting for your input or if it’s off and processing your data for you.

Find using Wildcard Field

The find command has been updated to allow use of a wildcard field name when matching items on field values. This allows users to search inside all fields which can come in handy when trying to locate items that might contain a token in a number of different fields.

find -f * lorem pwd

Excluding Standard Values

Sometimes when you’re searching for content you want to be able to exclude anything coming from standard values. For example, if you want to search for items that have overridden presentation. When using the find command you can pass the new flag -nsv (no standard values) to exclude standard values in the operation, and only assess items on field values they contain.

So to find item’s that have overridden their presentation we could use this command:

find -r -f __renderings .+ -nsv pwd

Better Version Support

This version of Revolver has better support for item versions, allowing you to list the various versioned and also change your context to a specific numbered version.

To list the versions of an item:

lsv

To see which version you’re looking at:

pwv

To change to a specific numbered version of an item:

cv 6

The cd command also got an update to make it easier to change your context between languages and versions.

Arguments can now include the language and version you want to change your context to. The language is separated from the item path with a single-semi colon, and the version is separated from the language with a single semi-colon. If the language, path or version is omitted then it won’t be changed. Here’s a few examples.

cd /sitecore/content/home:en:3
cd :de
cd ::6
cd :jp:7

Launch Content Editor

In the previous version of Revolver the ce script which could be used to open a content editor with the current context was broken. This has now been fixed and the script renamed to content-editor. So to open a content editor application on the current context item, just type the following:

content-editor

Better Scripting

Scripting also got better in this release of Revolver.

The new if command allows simple conditions to be evaluated using the expression syntax used by the find command. This can be used to ensure all the required parameters have been provided to a script.

The new exit command allows a script to bail out if required, such as when a parameter is missing.

The following example shows a check for the first parameter and exits if the parameter is not provided.

if ($1$ = \$1\$) (exit (Missing required parameter))

The if command accepts 2 parameters. The first is the expression to evaluate. In the above example if the parameter is provided then the $1$ token will be replaced with the parameter. Note how the dollar signs on the right hand side of the expression are escaped? This prevents the argument from being replaced with the provided parameter, so this expression is checking if the provided parameter was substituted or not.

The second parameter to the if command if the command to execute if the expression evaluates to true.

The exit command accepts an optional message which will be output to the user.

OOTB Scripts

Revolver also ships with some handy scripts out-of-the-box:

More Help

Don’t forget that help is built right into Revolver, so you can get more help on any of the commands by using the help command and passing it the name of the command you want help on:

help search
help lsv

Help is also available for scripts. Access it the same way:

help updates

Go Download It!

So what are you waiting for? Jump over to the codeflood website and download Revolver from the Revolver Downloads page. You’ll also find the module soon on the Sitecore Marketplace.

So, extending the Sitecore UI. On a recent project we had a requirement to provide a utility that was context sensitive. The utility in question was to perform operations on users, so I looked into extending the Sitecore User Manager application. I chose this application cause it already provides the functionality to list and search for users. I can select a user and perform various actions on that user.

Much of Sitecore’s UI is defined in the core database. This is where most of those menus and ribbons that you use every day are defined. When you see an application in Sitecore that contains a ribbon, such as the Content Editor, User Manager, Workbox, etc, those ribbons are defined in the core DB. This is where we can easily extend the applications with our own custom context sensitive commands.

In this article I’d like to add a command to the User Manager to allow me to reset some custom properties for a user. This basic approach can be used to create your own context sensitive application for any of the Sitecore applications mentioned above.

Firstly, we need to create the new ribbon entry to have it appear on the UI. Using the database switcher on the desktop tray, switch to the core database, open the content editor and navigate down to /sitecore/content/Applications/Security/User Manager/Ribbon/Home/Tools. This item is the definition for the tool chunk on the User Manager’s ribbon. Insert a new item based on the template System/Ribbon/Small button and name it “Reset Custom Properties”. Fill in the fields as follows:

The Header and Icon fields are shown on the ribbon. The Click field refers to a Sitecore command which we’ll define in one moment. Your item should look like this:

The Click field contains the name of a Sitecore command to execute. Sitecore will match this command to a command in the /configuration/sitecore/commands configuration element by name. By default, Sitecore defines all it’s commands in the App_Config\Commands.config file. But we’ll define our command in a config patch file so we don’t update any Sitecore provided files. Create a new file at App_Config\Include\CustomCommands.config and enter the following:

<configuration xmlns:patch="http://www.sitecore.net/xmlconfig/">
  <sitecore>
    <commands>
      <command name="usermanager:resetcustomprops"
        type="Demo.Commands.ResetCustomProperties,Demo"/>
    </commands>
  </sitecore>
</configuration>

The type in the command definition refers to the Command type to instantiate and execute. Now onto creating our custom command type. Compile the following code in Visual Studio and drop the resulting assembly into the bin folder. The following code is just the shell of the command, wired up to show everything working.

using Sitecore.Shell.Framework.Commands;
using Sitecore.Web.UI.Sheer;

namespace Demo.Commands
{
  public class ResetCustomProperties : Command
  {
    public override void Execute(CommandContext context)
    {
      SheerResponse.Alert("ResetCustomProperties");
    }
  }
}

In the code above we define a new class which implements the abstract class Sitecore.Shell.Framework.Commands.Command. The Execute() method is called when the user clicks the command in the Sitecore UI, so this is where we implement our logic. In the above code, I’m simply telling the client page to display a javascript alert to the user to prove the code was called through the user of the SheerResponse.Alert() method.

Now when I open the user manager in Sitecore I see our new custom ribbon button displayed and if I click it I see the alert message from our command class.

The above shows the basics for extending the ribbon with new commands. We could implement the logic to fulfil the command inside the Execute() method, but if we have an operation that will take some time to complete, this approach would provide no feedback to the user and would lock the UI as a postback is processing. To make it more usable and non-blocking we can leverage techniques from my article Long Running Process Options. The technique I’ll implement for this scenario is using the Progress Box.

using Sitecore.Security.Accounts;
using Sitecore.Shell.Applications.Dialogs.ProgressBoxes;
using Sitecore.Shell.Framework.Commands;

namespace Demo.Commands
{
  public class ResetCustomProperties : Command
  {
    public override void Execute(CommandContext context)
    {
      ProgressBox.Execute("ResetCustomProperties",
        "Reset Properties",
        new ProgressBoxMethod(ExecuteOperation),
        context.Parameters["username"]);
    }

    protected void ExecuteOperation(params object[] parameters)
    {
      if(parameters == null || parameters.Length == 0)
        return;

      string username = parameters[0].ToString();
      if (!string.IsNullOrEmpty(username))
      {
        var user = User.FromName(username, false);
        if (user != null)
        {
          if (Sitecore.Context.Job != null)
            Sitecore.Context.Job.Status.Messages.Add(
              "Resetting properties for user " + username);

          user.Profile.RemoveCustomProperty("prop1");
          user.Profile.RemoveCustomProperty("prop2");
          user.Profile.RemoveCustomProperty("prop3");
        }
      }
    }
  }
}

In the above code, we’ve used the static Execute() method of the ProgressBox class to create a progress dialog box on the Sitecore client page. The last two parameters of the method are the delegate to run and any parameters to pass. The username parameter in the Parameters property of the command context is set by the User Manager application. The delegate is run inside a Sitecore job. The progress box reads the status of the job and outputs relevant information on the dialog.

So you can see how easy it is to add options to a Sitecore ribbon. For item based commands the Items property of the command context can be used instead of a value from the Parameters property.

One particular challenge in preserving the page rank is if the information architecture (page structure) of the new site will be different to the old. Search engines aside, you still need to help users of your site find their way in the new site. Perhaps it’s not a new site we’re building but instead we’re binding a new domain to the website and need traffic to be directed through to the new domain. In addition, what about existing incoming site links from other sites and user’s bookmarks. These also need to be preserved.

The most common tool of choice for this challenge is redirects. And more often than not, permanent (301) redirects. A 301 redirect instructs the users browser or the search engine that the particular resource they’ve requested has moved permanently to a different location. This helps the user get to the page they were after at the new location as well as having the search engines update their references to your site and it’s URLs.

There are a plethora of redirect options available when working with a Sitecore project. So which to choose…

The first question to answer is if the content author will be managing the redirects or an administrator. At the simplest, a redirect rule will contain a 1 to 1 relationship between the old page URL and the new page URL. And it only gets more complex from there:

“If the user enters on domain 1 and requests anything from the news section, they should redirect to the news search page with the page name prepopulated in the search field”

Something like the above rule would probably be too complex for a content author (well, a non-technical user) to manage. And after all, that’s not their job anyway. They should be focusing on the content.

Some questions to consider when choosing a redirect option:

• Will administrators be managing the redirects or CMS users?
• Will redirects be done 1 to 1 or will we need to implement complex rules?
• Is the target Sitecore item likely to change name or path?

Below is a list of several redirect modules which you could use to help manage the redirect rules.

Administrator Modules

The below modules are more appropriate for administrators or developers as they are both configured through the web.config file (or the IIS admin console for IIS URL Rewrite).

These modules are appropriate for all your complex rules that can cover many cases, or if only the administrator will be managing the rules.

IIS URL Rewrite

The IIS URL Rewrite module is an official Microsoft module for IIS. It allows administrators and developers to manage redirect rules either through IIS itself or through web configuration files. This module is good for complex rules as well as any rule to do with domain redirects. It can also handle request rewriting, presenting your application with a different URL than was requested by the user.

Let me just give you a quick example of when that might be useful. Let’s say we’re adding a language variant to our site. The main English site is hosted at http://www.mysite.com and now we’re adding a German version at http://www.mysite.de. Another SEO best-practise is to provide an XML sitemap file to help robots navigate all the pages of your site. A handy module for automatically generating this file in Sitecore is the Sitemap XML module.

Now although we can have multiple different sitemap.xml files of different names, all referenced from the robots.txt file, for some reason I want the language specific sitemap.xml files to be served from their respective domains. Using IIS URL Rewrite I can rewrite any requests for the sitemap.xml file for either domain to a different filename. To the outside world it looks like I’ve requested http://www.mysite.de/sitemap.xml but the URL that my application sees is http://www.mysite.de/sitemap-de.xml.

Being that this module is an IIS module, it must be installed. It’s also only available for IIS 7. So if you’re working on IIS 6 or previous, or if you don’t have access to install anything on your web server then perhaps the next module can help.

UrlRewriter.net

This one has been around a while, but can still come in handy when you’re running on IIS before version 6 or if you can’t install anything on your web server.

UrlRewriter.net is an HTTP Module handling redirect and rewriting rules from within your ASP.NET application. Because it’s a module it doesn’t need to be installed, simply drop the DLL (which you’ll need to compile from source) into the bin folder, some web.config updates and the module will be handling your requests.

I have in some cases had issues with this module cooperating with Sitecore. For example, when a request is made for an item which doesn’t exist in Sitecore and a rule is matched which produces a redirect, Sitecore would override the redirect with it’s own to the “item not found” URL. But seeing as though you need to compile the module from source, you can easily update that source before compiling to complete the current HTTP request before Sitecore get’s a go (call HttpContext.Current.ApplicationInstance.CompleteRequest() after the redirect is set).

CMS Modules

If you need authors to be able to manage the redirects or if you don’t have easy access to the config files, then you’ll need to expose the redirect functionality through Sitecore itself. And there are several modules available to handle your redirects inside Sitecore too.

One benefit some of the CMS modules have over the administrator modules is that you’re dealing with Sitecore items now, referencing them by ID rather than simple URLs in strings. This means that if the target item name changes, or if it’s path changes, the redirect doesn’t break and doesn’t need to be updated.

301 Redirect Module

The 301 Redirect Module allows creating both 1 to 1 mappings from old URLs to items as well as creating regular expression based redirects allowing a single rule to map multiple URLs onto multiple items.

The 1 to 1 mappings allow selecting a target item using a droptree field. The value of this field is an ID, so the rule will be resilient to name and path changes of the target item.

The regular expression rules (redirect-pattern rule) uses a regular expression to match the incoming URL and makes use of capture groups to perform a regular expression replacement to a Sitecore path.

The redirect rules are created inside the Sitecore content tree so they are easy to backup (serialise via the Developer tab in the content editor), put into source control through TDS or package and deploy via the Sitecore package manager.

Redirect Manager Module

The Redirect Manager Module allows creating 1 to 1 URL to item mappings. It includes UI integration with the content editor to easily display what redirects are pointing at the current item.

This module also supports “automatic redirects”, detecting when an item is moved or renamed and adding a redirect rule to ensure requests for the previous path still resolve to the item.

Unlike the other CMS modules the rules are stored in a SQL DB. This makes it a little harder to backup the rules (you can always use SQL tools to backup the DB), put them in source control or move the rules between servers.

Sitecore Redirect Manager Module

The Sitecore Redirect Manager Module is very similar to the 301 Redirect Module in that it allows creating rules to map between URLs and items.

Conclusion

The above gives a few options for implementing redirects on your Sitecore site and the reasons to use each.

I generally prefer to handle the redirects using the IIS URL Rewrite module as I normally find that most content authors don’t want to think about redirects and don’t need to manage them themselves. To be honest, I’ve never received a request from any content author to be able to create redirects themselves, this is normally an administrator task.

So what happens when you want to do something different with the data which the out-of-the-box actions can’t handle? Let’s say we have an internal legacy system exposing a web service which we need to submit the data into. One way to achieve that would be to create a custom sublayout which statically defines the fields to collect and ties them to the integration to the legacy system. But this will mean any changes required by the content authors will need to be done by a developer. No, we want to leverage WFM so the content author can make those updates themselves.

Like most things in Sitecore, WFM is quite extensible, and we can create our own actions to be used in forms and configured by content authors. To create a custom WFM action:

1. Install the latest WFM module
2. Create a new class implementing the Sitecore.Form.Submit.ISaveAction interface
3. Register the action for use with the WFM module by creating a new item based on the /sitecore/templates/Web Forms for Marketers/Actions/Submit Action template under /sitecore/system/Modules/Web Forms for Marketers/Settings/Actions/Save Actions

So, let’s start with creating an action class which will submit data to that aforementioned legacy web service.

using System.Collections.Specialized; 
using Sitecore; 
using Sitecore.Data; 
using Sitecore.Form.Core.Client.Data.Submit; 
using Sitecore.Form.Core.Controls.Data; 
using Sitecore.Form.Submit;

namespace CustomWFMAction 
{ 
  public class SendToWebService : ISaveAction 
  { 
    public void Execute(ID formid, AdaptedResultList fields,
      params object[] data) 
    {
      // Extract the email field
      var email = fields.GetEntryByName("Email").Value;

      // Get list of additional fields to send
      var submitFields = new NameValueCollection(); 

      foreach(AdaptedControlResult field in fields) 
      {
        if(field.FieldName != "Email")
          submitFields.Add(field.FieldName, field.Value); 
      }

      // Submit data to web service
      var client = new TestService.ServiceSoapClient(); 
      client.SubmitData(email, StringUtil.NameValuesToString(submitFields,
        "&")); 
    }
  } 
} 

Custom actions should implement the Sitecore.Forms.Submit.ISaveAction interface. This interface exposes a single method, the Execute() method which we’ve implemented above. In the above example we first extract the email field which must be sent in a specific parameter to the web service and then we loop through each of the submitted form fields which is passed in the parameter fields, adding each to a NameValueCollection so we can easily format them in the correct format for the web service being submitted to.

Once we’ve written our custom action we need to register it with Sitecore. Create a new “Submit to test service” item based on the /sitecore/templates/Web Forms for Marketers/Actions/Submit Action template under the /sitecore/system/Modules/Web Forms for Marketers/Settings/Actions/Save Actions item to register the action with WFM and have it offer the action as an option in the form designer. Now you can create a test form to use the action on.

Although the above custom action does what it needs to, it’s not an ideal implementation. It’s quite brittle. The action has hard coded the field name containing the email address. If the form author changed the field name the email field wouldn’t be found and the correct data would not be submitted to the web service. It would be better if the action found the email field by ID rather than name so if the name changes the form still works. Also, we may not want to submit all the fields to the web service. It would be good to allow the author to select the fields to submit.

Let’s update the custom action to allow passing the email address field name and fields to send to the web service through the parameters of the action.

using System.Collections.Specialized; 
using System.Linq; 
using Sitecore; 
using Sitecore.Data; 
using Sitecore.Form.Core.Client.Data.Submit; 
using Sitecore.Form.Core.Controls.Data; 
using Sitecore.Form.Submit;

namespace CustomWFMAction 
{ 
  public class SendToWebService : ISaveAction 
  { 
    public string EmailField 
    { 
      get; 
      set; 
    }

    public string FieldsToSend 
    { 
      get; 
      set; 
    }

    public void Execute(ID formid, AdaptedResultList fields,
      params object[] data) 
    {
      // Extract the email field 
      var email = fields.GetEntryByName(EmailField).Value;

      // Get list of additional fields to send 
      var submitFields = new NameValueCollection(); 
      var fieldNamesToSubmit = (FieldsToSend ?? "").Split(',');

      foreach(AdaptedControlResult field in fields) 
      { 
        if (fieldNamesToSubmit.Contains(field.FieldName)) 
          submitFields.Add(field.FieldName, field.Value); 
      }

      // Submit data to web service
      var client = new TestService.ServiceSoapClient(); 
      client.SubmitData(email, StringUtil.NameValuesToString(submitFields,
        "&")); 
    }
  } 
}

We can set the properties of the custom action by setting them in the Parameters field of the action definition item. Each property is set in an XML fragment with the element name matching the property name of the class. WFM will handle setting these properties of the class when it instantiates it.

<EmailField>email</EmailField> 
<FieldsToSend>Category,Query</FieldsToSend>

Now although the above example let’s us set the properties of the custom action class, it sets the properties for all instances of the action and doesn’t allow changing the value for an individual form. It’s also not a good solution for the authors who may not be up to editing XML directly. To allow the authors to set these properties per form, we’ll need to provide an editor for the action.

The custom editor will be written using Sheer UI. Below is the XML layout file used for the editor.

<?xml version="1.0" encoding="utf-8" ?> 
<control xmlns="http://schemas.sitecore.net/Visual-Studio-Intellisense" 
  xmlns:def="Definition" 
  xmlns:asp="http://www.sitecore.net/microsoft/webcontrols"> 
  <SendToWebServiceSettings> 
    <FormDialog ID="Dialog" Icon="Applications/32x32/gear.png"
      Header="Web Service Settings"
      Text="Enter the settings for the web service submission"> 
      <CodeBeside
        Type="CustomWFMAction.SendToWebServiceSettings,CustomWFMAction"/> 
      <GridPanel Class="scfContent" Columns="2"
        Margin="20 15 10 15" Width="100%"> 
        <Literal Text="Email Field:" GridPanel.Align="right"/> 
        <Listbox ID="EmailFieldName" Width="97%"
          GridPanel.Width="80%"/> 
        <Literal Text="Additional fields to submit:"
          GridPanel.Align="right"/> 
        <Checklist ID="Fields" Width="97%"
          GridPanel.Width="80%" /> 
      </GridPanel> 
    </FormDialog> 
  </SendToWebServiceSettings> 
</control>

And we’ll also need the code beside class.

using System; 
using System.Collections.Generic; 
using System.Collections.Specialized; 
using System.Linq; 
using System.Web; 
using Sitecore; 
using Sitecore.Configuration; 
using Sitecore.Form.Core.Utility; 
using Sitecore.Forms.Core.Data; 
using Sitecore.Web.UI.HtmlControls; 
using Sitecore.Web.UI.Pages; 
using Sitecore.Web.UI.Sheer;

namespace CustomWFMAction 
{ 
  public class SendToWebServiceSettings : DialogForm 
  { 
    protected Listbox EmailFieldName; 
    protected Checklist Fields;

    protected override void OnLoad(EventArgs e) 
    { 
      base.OnLoad(e); 
      if (!Context.ClientPage.IsEvent) 
      { 
        // Populate WFM fields into settings form fields 
        PopulateFormFields(); 
      } 
    }

    private void PopulateFormFields() 
    { 
      // Read already configured parameters 
      var parametersKey = Sitecore.Web.WebUtil.GetQueryString("params"); 
      var parameterString = HttpContext.Current.Session[parametersKey] as string; 
      var parameters = ParametersUtil.XmlToNameValueCollection(parameterString);

      // Get the email field 
      var emailField = parameters["EmailField"] ?? string.Empty;

      // Get the additional fields to send 
      var fieldsToSend = new string[0]; 
      if (!string.IsNullOrEmpty(parameters["FieldsToSend"])) 
        fieldsToSend = parameters["FieldsToSend"].Split(',');

      // Populate options from the form definition 
      var db = Factory.GetDatabase(Sitecore.Web.WebUtil.GetQueryString("db")); 
      var formId = Sitecore.Web.WebUtil.GetQueryString("id"); 
      var form = new FormItem(db.GetItem(formId)); 

      if (form != null) 
      { 
        // Iterate WFM form fields 
        foreach (var field in form.Fields) 
        { 
          // Add field to email droplist 
          EmailFieldName.Controls.Add(new ListItem() { 
            Header = field.Name, 
            Selected = field.Name == emailField, 
            ID = Control.GetUniqueID("efn"), 
            Value = field.ID.ToString() 
          });

          // Add field to additional fields to send 
          Fields.Controls.Add(new ChecklistItem 
          { 
            Header = field.Name, 
            Checked = fieldsToSend.Contains(field.ID.ToString()), 
            Value = field.ID.ToString() 
          }); 
        }
      } 
    }

    protected override void OnOK(object sender, EventArgs args) 
    { 
      // Get list of selected additional fields to send 
      var selectedFields = new List<string>();

      foreach (var item in Fields.Items) 
      { 
        if(item.Checked) 
          selectedFields.Add(item.Value); 
      }

      // Get XML fragment of settings to store 
      SheerResponse.SetDialogValue( 
        ParametersUtil.NameValueCollectionToXml(new NameValueCollection() 
          { 
            {"EmailField", EmailFieldName.SelectedItem.Value}, 
            {"FieldsToSend", string.Join(",", selectedFields)} 
          }));

      base.OnOK(sender, args); 
    }
  } 
}

Note in the above code example in the OnOK() method that we’re constructing an XML fragment of the settings. By saving the settings in XML they’re already in the format expected by WFM and it will auto populate these properties on the custom action when it’s instantiated by WFM.

To register this control as the editor for the action, add a reference to this Sheer UI control in the editor field of the action definition item. Remember, in order to refer to a control in Sheer UI we reference the name of the child element of the root control element inside the XML layout file, in this case SendToWebServiceSettings.

With the editor field populated the edit button will now be enabled when the action is selected in the save actions dialog box.

And clicking the edit button will open the custom settings editor.

And now we have a user friendly editor for the settings of our custom action. But it’s not just about presenting a friendly UI, this editor has made the action more robust, allowing authors to change the names of fields in the WFM and then use this UI to map the required data for the action.