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

Datasources on Sitecore Renderings are the basis for content authors to combine a variety of components to form a page, without the need for all the fields to exist in the context item. They also form the underpinnings of switching out content based on personalization rules.

To make life easier for content authors there are two properties which should always be set; Datasource Template and Datasource Location.

Datasource Template

The datasource template field is fairly straightforward to understand. It specifies what type of template is compatible with a rendering.

If the content editor try's to select an incorrect template they will see an error message like this and the ok button will be disabled:

The template reference can point to either the final template that an instance of which will be created, or a template that had been inherited. So if you structure your templates using base template like I describe in my article on How I structure Sitecore Templates then you can reference the base template and anything including it will become available.

However there is a fundamental flaw in linking to a base template. As well as restricting the template that can be selected, specifying the template type also enables the ability to create new content, which will create it as the form of the template specified. So only link to the templates you want your editors to create.

Datasource Location

The datasource location property (as the name suggest) enables you to restrict where in the content tree items can be selected from (or new content created).

Simply specify the folder the content should be placed in and the rest of the content tree will now be hidden from content authors.

Multi-site solutions

If your solution contains more than one website this may cause a problem as you likely want to be able to restrict certain content to certain sites and may additionally have a global content folder.

The first solution to this is to add multiple path's separated by a pipe.

This will enable multiple folders to be shown to the user, but it wont enable any sort of restriction.

The second option is to add an xpath query find the relevant folder. This can also be used in conjunction with the static path by being pipe separated as in the last example.

A query like this:

Will produce the desired output like this:

Here you can see the shared hero banners folder is available as is the specific hero banner folder for the current site, but not the hero banner folder from the other site.