Sitecore Overload

In one of my previous blog post I wrote an example on how to add Glass Mapper to Helix . I will in this blog post provide some code examples on how to map different fields with Glass Mapper. I will also provide some examples on how you could benefit more from Glass Mapper by using interfaces instead of models. Why use interfaces instead of models Interfaces can be inherited multiple times, this works well with inherited templates in Sitecore. We create the common fields in the Helix Foundation layer, and use the mappings in multiple feature projects. The mapping is created in separate interfaces. The model(interface) that should use the fields only needs to inherit from these interfaces. For example a simple component with Title and Rich Text would only need to inherit from the GlassBase, Title and Rich Text interface IMyComponent   :   IGlassBase ,   ITitle ,   IRichText Inside Sitecore the MyComponent would need the Title and RichText field The view then has access

Sitecore workflows are great for publishers and editors. However, as administrator or developer, we usually have to make changes to published items without triggering a new workflow. These changes are usually technical changes/bug fixes that needs to go live as soon as possible and does not really need to go through all the workflow steps. Create a Publish Command to skip workflow steps To achieve this I created a new workflow command. Publish . This command basically skips the submit and approve steps and goes directly to auto publish. The steps: Create an new Command Publish under the Draft state Set next state to the Approved State Set this command to suppress comments Update the Auto Publish action to include related items Per default the parameter for Auto publish is set to : deep=1&smart=1 I recommend setting it to: deep=1&smart=1&related=1 so related items like images are published with the same action. Setting restrictions(security) to rol

It seems like commands are not available unless the user locks the item. There are some exceptions, if you are an administrator they are always available. When an editor edits an item and you have set AutomaticUnlockOnSaved to true, they would have to lock the item again before they can send it for approval. A similar problem happens to the publishers. If they would want to approve or reject a workflow they would have to lock the item. This might not seem like a big problem, but I received several complaints from editors about this, and asked Sitecore support if this is expected behaviour. Sitecore support told me that this is expected, and they provided me with a possible solution. Create an assembly that contains a copy of ‘Sitecore.Shell.Applications.ContentManager.Panels.WorkflowPanel’ class; Override the ‘Render’ method with your definition (you can use the "ILSpy" tool for this purpose). Built and add the assembly to ‘Bin’ folder; Follow to ‘/sitecore/conte

In many Sitecore solutions, there are different areas, where different editors and publishers maintains content in their respective areas. Sometimes these areas overlap. In this blog post I will give an example of how to send workflow notifications to the different publishers and editors without being restricted to where in the structure the item is created/edited. Creating a connection to roles and the Sitecore item I created a droplink field on the Sitecore items which use workflows so we can connect this item to the corresponding roles. The droplink is populated based on a data folder with items that has the Roles specified. In this example, I have a Publisher Role and an Editor Role, where access rights to workflow commands and other Sitecore roles has been added. The owner roles (owner publisher and owner editor) will inherit from these roles. the owner roles are primarily used to control which users should get notifications in this example, I also use, the owner set

Months after finishing a project I have had clients saying: We need to make a copy of the site you created and put some other content on it Most clients need to put this new site into the same solution because of restrictions in their Sitecore license. To convert old projects there was usually a lot of content restructuring and code changes needed. I have done this exercise multiple times. I try to have this in mind when creating new solutions so we don`t end up with too much effort when adding support for multi sites at a later stage. Even with great structure and code we still face some problems. In a multi-site solution you want to reuse components, but the sites should not always share the data locations and image folders. Most sites have different editors, they should not see the components and images from the other sites, we then need to place content in different folders and set the appropriate security on those. I recently got a request to duplicate an existing site,

How to add Glass Mapper to Sitecore Helix solution There are probably different ways to set this up in a Helix solution. I have done this setup in 4 of our projects, and it has become the "template" for our new Helix solutions. We create one foundation project, which has all the glass nuget packages installed, we also choose to add a glass base in the foundation layer. All new features will have access to this glass base interface through a project reference.  I have had a lot of discussions with my co workers on where to add common fields that would be used in several feature projects. If it should be in the Glass Mapper foundation project or in a new foundation project. On "small" projects we choose to add it in the Glass Mapper foundation project, on larger projects we created a separate foundation project to add these fields and their interfaces with Glass Mapper mapping. 1. Create the Visual studio project From the Package Manager Console run