Sitecore fixes and improvements

Sitecore keeps getting better - Sitecore 9 has brought us quite a few new things like SIF, xConnect, integrated Forms or configuration layers. There has also been a lot of attention to bug fixing, building upon the progress already made in 8.2.

Some of the issues I have discused in other posts of this blog have now been fixed, so I thought it would be fair to write about these improvements as some of them may have quietly gone under the radar.

Search UI improved

A while ago I wrote a whole article about Searching in Sitecore and how I disliked a few things, for example how the results would open.
With the default configuration, when you click in a search result in the Content Editor, it opens in a separate tab. Previously you would get a hideous double ribbon effect; since 8.2 update 1 this has now disappeared and a single ribbon is shown throughout.
If you open multiple search results, each will open in its own tab, and the effect of the ribbon commands will apply to that single item.

Single ribbon multiple tabs

You can also right click on the tab and use the close all, close all but this or close tabs to the right to manage the open tabs.

Tab contextual menu

As a side note, another nice little touch added in this same update is a small notification in the tab title when there are changes that have not been saved yet.

Pending changes

If you prefer to have a modal window instead, you can still change the setting in the Show Search Results In field in the /sitecore/system/Settings/Buckets/Item Buckets Settings item. Previously when opening the modal dialog the tree would be shown in the pop up. Since 8.2 update 3, this is now fixed too and the tree remains hidden.

Editing Rendering Parameters fixed in 8.2 update 4

On another blog post I discussed how the dialog for editing Rendering Parameters was not ideal. It would show information about caching, placeholder, parameters, etc. This information could be hidden using field restrictions (though not easily on older versions which were affected by a bug).

Since Sitecore 8.2 update 4 this is all much easier to accomplish. When you create a new Rendering Parameters Template, you no longer need to inherit from the Standard Rendering Parameters. By breaking that inheritance none of the standard fields (caching, placeholder, etc.) are shown any more. The dialog only shows those fields you created in your own custom rendering parameters template.

Rendering Parameters

I still dislike though how users acccess this dialog from the Experience Editor.
contextual rendering menu

The contextual toolbar shown when selecting a component keeps the component properties under the More submenu. It also shows there an option to change the Experience Editor Options (information in the component definition item), which I really don't think should be shown to the users.

I would prefer to move the properties button to the main area of the toolbar and remove that More menu altogether. Like this:

modified contextual rendering menu

This is quite easy to accomplish. You musth change security for the /sitecore/content/Applications/WebEdit/Default Rendering Buttons/Options item, so regular users don't have read access to it (remember to deny inheritance, avoid explicit denies). Then change the Type field of the /sitecore/content/Applications/WebEdit/Default Rendering Buttons/Properties item to Sticky.

Experience Editor

The Experience Editor has received a welcome performance boost in Sitecoe 9. The number of HTTP requests has been massively reduced and the load times are much better.

There is also a minor, but useful fix. Nowadays regular users must take a lock on an item when editing it in the Experience Editor (just like they have had to do in the Content Editor for many years). Since the Experience Editor can show information from multiple items at once (for example, because the use of datasources) locking and unlocking gets a bit more challenging.
Sitecore will force users to lock the item representing the page before making any changes. Other items are not locked. However, if fields from any other items are modified, Sitecore will attempt to lock them before saving the changes. If the item can't be locked (because it is already locked by somebody else), it will show a message:

locked item message

The main difference comes next. When the user clicks unlock in previous versions, Sitecore only unlocks the context item; in Sitecore 9 it will also unlock the datasource items. This will help users avoid leaving items locked by mistake. Of course they could use the My Items dialog to unlock other items in bulk.

Notice that this will not unlock other items that have been modified but are not datasources of components; for example, items you are retrieving in code and adding as a parameter to a Field extension method.

As an alternative, you could set items to be unlocked automatically when they are saved. In this case Sitecore would take a lock for saving the changes and then release the lock as soon as the save operation completes. This setting can be set up on a per user basis. This is done through a policy. Policies are items in the core database; having read access to them, or not, dictate whether the policy applies to a certain user. If you want items to get unlocked on save, deny read to /sitecore/system/Settings/Security/Policies/Page Editor/Keep Lock After Save.