In a multi-lingual build we’d given the user a new toolbar button to create a copy of the given item in a given language. The logic behind the scenes would create a version of the new item in the destination language, scan the original item and copy all the field values to the destination. It would also then reset things like workflow on the destination item.

As part of this logic we’d call:

but would sometimes find itemTo would be null.

With the help of support, they pointed us towards the <sites> configuration and the following attribute:
filterItems: If true, the site will always show the current version of an item (without publishing) and advised this could be causing the issue. This setting can be manipulated programatically via setting:

So your final code would then be:

Enjoy your new versions!

We recently had an odd scenario where Sitecore EditFrame buttons would seemingly disappear randomly. Our edit frame made use of a mixture of Field Editor Buttons (‘/sitecore/templates/System/WebEdit/Field Editor Button’) and Edit Frame Small Buttons (‘/sitecore/templates/System/WebEdit/Edit Frame Small Button’).

We never had problems with the field editor buttons just the edit frame small buttons. On these buttons the clicks are bound to Sitecore commands. Behind the scenes these commands evaluate their querystate to check if they should be visible, disabled or active:

The buttons had a mixture of commands, some custom and some out the box. Examples of the out the box commands were:

Note, to find the code that runs for these commands, have a look in /App_Config/commands.config and search for the specific command name.

After debugging into our custom commands vs the out the box commands we found things like item:movedown has the following checks:

The check that was catching us out was the if (Command.IsLockedByOther(item)) clause.

I’d never have thought to check an item locks as being the cause of EditFrame buttons not showing!!! The more I think about it I can see why the check is there – things like sort order are stored as fields against an item so if they are locked, you shouldn’t be able to edit them. From a UI perspective, it appears edit frame buttons don’t distinguish between CommandState.Disabled and CommandState.Hidden.

We recently setup some ribbon functionality to add custom popups into buttons in the Sitecore content editor ribbon. The code to launch the popup was via a custom command:

In the popup window we wanted to be diligent and check that only certain users could see the form. This was done via:

The problem we found was sporadically the ‘SitecoreContext.User.IsAdministrator’ check would fail and the popup would be blank.

After a lot of debugging we found the cookies in the HttpRequest object would sometimes be different hence causing the differences in the users attributes. When Sitecore invokes preview mode, it sets the user to be ‘sitecore\anonymous’ via ‘PreviewManager.StoreShellUser(true);’. This is what was catching us out. If the user had been using the cms and then visited preview the popup window would inherit the anonymous user.

Once we found the solution it was a very easy change to integrate (the WebEdit command -> Run(ClientPipelineArgs args) gave us the answer).

During our command before we open the popup we simply needed to add:

If you want to change the behavior of when you past content into the Sitecore Rich Text Editor, you can change the settings used by the Telerik control.

This is embedded into the application via:

/sitecore/shell/Controls/Rich Text Editor/EditorPage.aspx

Then the attribute that causes the change in behavior is:

<telerik:RadEditor ID=”Editor” Runat=”server”
…
StripFormattingOnPaste=”All,ConvertWordLists”

…

To see all options for the enumeration, have a look at http://demos.telerik.com/aspnet-ajax/editor/examples/cleaningwordformatting/defaultcs.aspx