So your going that extra mile and fully supporting the experience editor in your Sitecore solution, but how do you support a WYSIWYG editor when a field isn't actually visible, or you need to provide the ability to edit a complex field type such as a drop-down or a multi-list?

The solution is to use either Edit Frames or Custom Experience Buttons, both of which will display a dialog containing the fields to edit. The difference between them comes down to where the toolbar containing a button will appear.

Edit Frames require extra code to be added to your view and are designed to surround a section(s) of your view. Custom Experience buttons however appear on the existing tool bar that's shown when you select a component in the experience editor.

Edit Frame

With an edit frame you can surround a section of html within your view with a clickable target, that will display a toolbar with a button to launch the dialogue.

To set up an edit frame:

• In the core database navigate to /sitecore/content/Applications/WebEdit/Edit Frame Buttons and create a new item based on Edit Frame Button Folder. This folder will be referenced in your view for the collection of buttons to be displayed.
• Under the new folder create a new item based on Field Editor Button and give it the name of your button.
• On your button item make sure you set an icon and the list of fields the button should allow the content editor to edit. These should be pipe separated.

• In Visual Studio open the view for your rendering
• Add a reference to Sitecore.Mvc.Extensions
• Surround the section to show the button with a using block as follows:

• You will now see a toolbar appear in the experience editor

• Clicking the icon will load a dialogue to edit the listed fields

Custom Experience Buttons

Custom experience buttons differ to edit frames in that you do not need to add any code to your views. Rather than having 1 or more clickable areas in your view the button will appear on the toolbar for the entire component. This makes them beneficial when the field doesn't directly relate to a section in the view. e.g. for editing a background video that may span the entire components background.

To set up a custom experience button:

• In the core database navigate to /sitecore/content/Applications/WebEdit/Custom Experience Buttons and create a new item based on Field Editor Button.
• On your button item make sure you set an icon and the list of fields the button should allow the content editor to edit. These should be pipe separated.
• Switch to the master DB and navigate to the rendering item for your component
• In the field for Experience Editor Buttons select the new button

• Selection the component will now show the additional button on the toolbar

• Clicking the icon will load a dialogue to edit the listed fields

I recently needed to run a script on a block of Sitecore content in invert the selection of a checklist and multilist. As I couldn't find any example of how to do this at the time, I thought I'd share what I wrote.

Get-ChildItem -r -Path "master:\content\Home" -Language * | ForEach-Object {

This line is getting the child items from the home node in the master db. The -r specified that it should be recursive and the -Language * specifies to include all languages. The results are then piped to a for each loop.

if ($_.PSobject.Properties.name -match "Tier") {

The field I needed to update was called Tier, as this was included in multiple templates I checked that the object included a field called Tier, rather than checking the template types.

[String[]]$tiers = $_.Tier -split "\|"

List fields in Sitecore get stored as a pipe separated list of the item Id's for the selected items. In order to do a comparison in Powershell I needed to turn the string back into an array using the split command. Notice the backslash that is needed before the pipe.

$_.Editing.BeginEdit()

To edit an item you need to begin an edit

$newtiers = Get-ChildItem 'master:\content\Components\Lookups\Tiers\' | Where-Object { $tiers -notcontains $_.Id }

This is where we get the new list of tiers to set as the selected ones for the item. The Get-ChildItem command is retrieving the original options that could be selected and the where-object statement is then excluding the ones that are in the $tiers array we just made.

$_.Tier = $newtiers.Id -join "|"

To save the new list we need to convert the results of the query into a pipe separated list using a join.

$_.Editing.EndEdit() } }

End the editing to save and close the the if and loop statements.

Sitecore 9 is out and with it comes cool new whizzy stuff. Here's my top features from the new version of the platform.

#1 - New Forms module

I think everyone would agree that Web Forms for Marketers was starting to show it's age and the UI was getting a bit dated compared to the rest of Sitecore.

The new Forms module, which is just called forms is completely new from the ground up. It has a new drag and drop UI with long awaited support for multiple page forms.

Like WFFM, the module is extendable through custom save actions and comes with a number of useful default ones out of the box.

There is no upgrade option for moving a WFFM form to the new module but WFFM will continue to work on Sitecore 9 and is being dropped in Sitecore 9.1.

I think more than anything the UX improvements will make a real difference for users by being much simpler to understand and will drive to much more use.

#2 - Marketing Automation

In Sitecore 9 Engagement Plans are being replaced with Marketing Automation. Like the forms module, this is completely new from the group up rather than an UI update to the existing Engagement Plans.

The new Marketing Automation module has a really easy to use drag and drop ui which is a vast improvement over the old Silverlight implementation engagement plans had. It's also directly accessible from the dashboard rather than being hidden in the Marketing Control Centre.

One of the biggest changes (aside from the UI) is there is now no need to enrol users in a plan at a specific state either by code or a wffm save action. I found this one of the most confusing aspects to end users who were expecting creating states with a trigger to automatically add people once they had triggered a goal, so this is great to see fixed.

Plans now have very clear start and end points with a number of options on the start node (goals, events), which can be combined to trigger who should be added to the plan.

Overall for the moment you try creating a plan just to see what it can do, the whole process is so much simpler that I think this will have a significant aspect on users. Engagement Plans were something that needed to be learn 't in order to get anything out of them, and wernt intuitive enough leading to frustration. With Marketing Automation I think a lot of people that were put off before will now benefit from this module.

#3 - xConnect

xConnect is a new service layer that sits between xDB and the client. That could be the CMS, a device or some other custom server side process that needs to read or write xDB data.

With xConnect as the service layer this means that no system has direct access to the collection database or search indexes. Any system wanting to access this data will go through xConnect which also helps with support for things like GDPR.

xConnect is installed separately from Sitecore itself and does not have any dependencies on the Sitecore kernel. When you install Sitecore locally you will see two IIS entries, one for Sitecore and one for xConnect. Communication with xConnect is done via a set of RESTful API's over HTTPS, making integrating with it extremely simple to do.

What xConnect really brings to the table is the ability to scale an combine many more systems rather than just the CMS. e.g. Phone Apps.

#4 - Sitecore Installation Framework (SIF)

Installing Sitecore 9 is very different to previous versions (see my Sitecore 9 installation tips here), gone are the days of copying a web-root and restoring some db's. The entire installation is now done with a new framework based on PowerShell scripts.

While this is going to create a pain point in the amount of time it takes to get started. It will almost certainly vastly improve DevOps tasks as it opens up numerous options to put the installation scripts in deployment pipelines.