Sitecore Xperiences » Development

Custom Reset Layout in Content and Experience Editor Modes

Rodrigo Peplau — Fri, 09 Feb 2018 00:04:51 +0000

Recently I had to customize the code that triggers when a Reset Layout is executed. If you ever had to attach any code to it, this post is for you!

You know, that sympathetic prompt:

The first thing you need to know is that Content Editor and Experience Editor does that differently, so let’s go for them:

Round 1 – Content Editor

Content Editor uses a command for that (pagedesigner:reset), which is natively implemented by the class Sitecore.Shell.Applications.Layouts.PageDesigner.Commands.Reset. We first need to create a class that will inherit from the original, so we don’t lose the original behavior, and implement our custom logic on it.

Create a Command class like this:

using System.Web.Mvc;
using Sitecore.Shell.Applications.Dialogs.ResetLayout;
using Sitecore.Web.UI.Sheer;

namespace MyProject.Commands
{
    public class ResetLayoutCommand : Sitecore.Shell.Applications.Layouts.PageDesigner.Commands.Reset
    {
        protected override void Run(ClientPipelineArgs args)
        {
            // Runs the default behaviour
            base.Run(args);

            // Skips if the Reset Layout prompt is not submited or results is undefined
            if (!args.IsPostBack || string.IsNullOrEmpty(args.Result) || args.Result == "undefined")
                return;

            // Takes the item that has been reset
            var itemReset = DeserializeItems(args.Parameters["items"])[0];

            // And here is where your custom logic will be implemented
            // .....
        }
    }
}

Then we override the default command with our class in a config patch like this:

And this is how we run the first leg. But it is not over yet, let’s go for…

Round 2 – Experience Editor

Experience Editor, on the other hand, uses a different approach for that. It has a request node named “ExperienceEditor.ResetLayout.Execute” under that we need to replace. This request node is implemented by the native class Sitecore.ExperienceEditor.Speak.Ribbon.Requests.ResetLayout.Execute, which again we are going to inherit.

So our Request class will be like this:

using System;
using System.Web.Mvc;
using Sitecore.Diagnostics;
using Sitecore.ExperienceEditor.Speak.Attributes;
using Sitecore.ExperienceEditor.Speak.Server.Responses;
using Sitecore.Shell.Applications.Dialogs.ResetLayout;

namespace MyProject.ExperienceEditor
{
    public class ResetLayout : Sitecore.ExperienceEditor.Speak.Ribbon.Requests.ResetLayout.Execute
    {
        [HasItemPermissions(Id = "{BE98D7F0-7404-4F97-8E4C-8FEF4ACA5DA3}", Path = "/sitecore/content/Applications/WebEdit/Ribbons/WebEdit/Advanced/Layout/Reset")]
        public override PipelineProcessorResponseValue ProcessRequest()
        {
            // Instantiates the returning object and 
            var processorResponseValue = new PipelineProcessorResponseValue();

            try
            {
                // Executes the default RESET LAYOUT process
                processorResponseValue = base.ProcessRequest();

                // Takes the item that has been reset
                var itemReset = RequestContext.Item;

                // And here is where your custom logic will be implemented
                // ..... (OF COURSE, DON'T DUPLICATE YOUR LOGIC!)
            }
            catch (Exception e)
            {
                Log.Error(
                    $"[ResetLayout] Cannot execute post Layout Reset operations to item '{RequestContext.Item.Paths.Path}'", e, GetType());
            }
            return processorResponseValue;
        }
    }
}

And finally we patch it again with a config file like this:

And that’s all… You now have your custom code being triggered by both Content Editor and Experience Editor!

Prevent orphan components in Experience Editor when deleting composed components

Rodrigo Peplau — Fri, 29 Sep 2017 22:44:45 +0000

If an editor deletes a component in Experience Editor and that component has inner components, only the outer component will be actually deleted from the page rendering. Inner components will not show anymore (and often Content Editors will be happy), so why would that be a problem?

The problem

Take for instance this set of renderings of a certain page:

If in Experience Editor someone tries to delete it:

The result will be a “ghost” orphan item, which will not render when the page loads because its placeholder does not exist anymore.

That rendering will continue at the page rendering, being either forgotten forever or re-appearing when someone tries to add a new Carousel to the same Full-Width Container placeholder.

Not just me

I’ve seen more people concerned with that – such as the author of this question at Sitecore Exchange – and some other people suggested possible solutions.

One approach I tried was to follow this blog post by Mike Tschida and implement a pipeline processor to clean-up the Page Rendering, removing orphan components when the page is saved. That would be perfect, however during development or debugging, it is very common to temporarily move a component to an unexistent placeholder to make it vanish from the page. In cases like that, the component would be deleted, which is not desired.

Acting at the other end

So what if, instead of acting later at the server, we stop content editors at the root of the problem: the Experience Editor? At that case, when an editor attempts to delete a component which has inner components, a prompt like this would be displayed. In order to delete the outer component, the editor now needs to delete the inner components first.

Inspired by this simple Stack Overflow post, in which the author was looking for a way to simply ask for a confirmation before deleting a component, I ended up with the solution below.

Nip the evil in the bud

The deletion of a component is handled by javascript code located at \sitecore\shell\Applications\Page Modes\ChromeTypes\RenderingChromeType.js – more specifically at the deleteControl method. Our fix will comment out the original code (I will leave there for future reference in case of an upgrade) and add the following code:

    deleteControl: function () {
        var canDelete = this.canDeleteControl(this.chrome);
        if (canDelete === false) {
            alert("Please delete inner controls before deleting this.");
            return false;
        }
        var placeholder = this.getPlaceholder();
        if (placeholder) {
            placeholder.type.deleteControl(this.chrome);
            return true;
        }
        return false;
    },

Along of course with the new canDeleteControl method, which does the trick of verifying if the component attempted to be deleted has inner components.

    canDeleteControl: function (chrome) {
        var canDelete = true;
        var childChromes = chrome.getChildChromes();
        for (var i = 0; i < childChromes.length; i++) {
            if (childChromes[i].type.key() == "placeholder") {
                canDelete = this.canDeleteControl(childChromes[i]);
                if (canDelete === false)
                    break;
            }
            else if (childChromes[i].type.key() == "rendering") {
                canDelete = false;
                break;
            }
        }
        return canDelete;
    },

And that’s all we need! Replace this file in all instances, clean up your browser caches and don’t worry about orphan components anymore!

Language specific MediaProvider breaking icons at Media Library

Rodrigo Peplau — Tue, 14 Feb 2017 15:00:30 +0000

UPDATE: Kamruz Jaman has contributed with a comment for a simpler, less intrusive and more generalist solution: Inside the GetMediaUrl method of your custom MediaProvider, check for the “Thumbnail” property of your MediaUrlOptions parameter. If it is true, make your code fall back to the base, such as:

if (mediaOptions.Thumbnail)
return base.GetMediaUrl(mediaItem, mediaOptions);

During an upgrade from Sitecore 6.5 to Sitecore 8.1 one issue were noticed at the Media Library: when a Media Item is uploaded, the icon appears broken.

A custom MediaProvider is used at this build to modify the way Sitecore generates Media Item urls. All it does is to add the language at beginning of the media URL so we can have language-specific media items. This is important to allow the same Media Item (etc: an image or PDF) to be served in multiple languages.

Root cause

When a media item is uploaded to the Media Library, Sitecore will fill the “Icon” field with the URL of the media item itself. Because of the custom MediaProvider, language is being added to the beginning of the generated URL. Apparently that was not a problem in Sitecore 6.5, but things seems to have changed at Sitecore 8.

Technical explanation by Sitecore

A Support Ticket #476256 were created to allow further investigation from Sitecore on this issue. According to the technical team:

“The behavior you reported is expected as tree node icons are rendered by Sitecore.Shell.Applications.ContentManager.Sidebars.Tree.RenderIcon(Item item) method which does not use language definition, embedded to URL, to resolve item language. So when the Icon field contains URL with language definition embedded, it breaks the method functionality and leads to incorrect resolution of the item’s icon.

When you have versioned media item, the icon is rendered for specific language automatically even when language is not specified deliberately. For instance, if you have media item with two language versions and different images for each language, and use -/media/ItemGUID.ashx?h=16&thn=1&w=16 string in the Icon field, language specific icon will be rendered when you switch the language in the Content Editor.”

This explains the causes but doesn’t fix the issue: how can we skip or bypass the custom MediaProvider, avoiding the language to be added to the URL when the “Icon” field is filled?

Solution

In order to fix that we will need to extend and override the Sitecore.Resources.Media.Media class, responsible for the upload and update of metadata when a Media Item is uploaded to the Media Library, then modify all Media Types to use your class instead of the original.

Step 1 – Extend the Media class

This is going to be responsible for removing the language from the URL when a Media Item is uploaded. In bold you see the code responsible for that, rest is basically native code to ensure compliance with default Sitecore behavior.

using Sitecore;
using Sitecore.Configuration;
using Sitecore.Data.Items;
using Sitecore.Data.Proxies;
using Sitecore.Diagnostics;
using Sitecore.Resources.Media;
using Sitecore.SecurityModel;

namespace CustomMediaProvider
{
  public class Media : Sitecore.Resources.Media.Media
  {
    public override Sitecore.Resources.Media.Media Clone()
    {
      return new Media();
    }

    public override void UpdateMetaData(MediaStream mediaStream)
    {
      Assert.ArgumentNotNull(mediaStream, "mediaStream");
      var innerItem = MediaData.MediaItem.InnerItem;
      if (!innerItem.Paths.IsMediaItem) return;
      using (new EditContext(innerItem, SecurityCheck.Disable))
      {
        innerItem["extension"] = mediaStream.Extension;
        innerItem["mime type"] = mediaStream.MimeType;
        innerItem["size"] = mediaStream.Length.ToString();
        if (Settings.Media.AutoSetAlt)
        {
          innerItem["Alt"] = innerItem.Name;
        }
        var shellOptions = MediaUrlOptions.GetShellOptions();
        shellOptions.Thumbnail = true;
        shellOptions.Height = 0x10;
        shellOptions.Width = 0x10;
        var realItem = ProxyManager.GetRealItem(innerItem, true);
        // CODE ADDED TO REMOVE LANGUAGE FROM URL WHILE UPLOADING
        var iconUrl = MediaManager.GetMediaUrl(realItem, shellOptions);
        var prefix = "/" + Context.Language.Name + "/";
        if (iconUrl.StartsWith(prefix)) iconUrl = iconUrl.Replace(prefix, "");
        innerItem.Appearance.Icon = iconUrl;
      }
    }
  }
}

Step 2 – Register the Media class to all Media Types

This is the painful part: we will need to register our class to every Media Type we want to cover. There is no easy way for that other than adding a node for each Media Type, paying attention to the correct way for patching that specific node (some nodes may have a Media class already defined and thus needs correct patching, others don’t).


 
 
 
 
 CustomMediaProvider.MediaProvider,CustomMediaProvider

Slowness with Custom Properties on .NET Security Provider

Rodrigo Peplau — Mon, 22 Aug 2016 00:49:52 +0000

If you ever used the standard .NET Security Provider with Sitecore, you may love how easy it is to create and use Custom Profile Properties, where data can be easily saved at user profiles. But a huge issue can emerge if you attempt to retrieve users at your database by one of these custom properties.

The Problem

Let’s say you have a custom property called Document ID, and you wish for some reason to retrieve the user that has a certain number on it – for instance, if your users can login to your website both using their Logins or Document IDs – then you may have something like this at your code:

var userFound = UserManager.GetUsers().FirstOrDefault(f => f.Profile["Document ID"] == inputDocumentId);

This simple code can bring you a big headache, because of the way .NET Security Provider builds the SQL Query responsible for executing your LINQ expression. Since all Custom Properties are stored as meta data, it is simply not directly queriable. Then what Security Provider does is one SELECT query for each user at your database, deserializing the Custom Properties on memory so it can be compared to the user input.

If you have few users at your database, which is usually the case when you are in development phase, you’ll probably not notice any issue. But after your go-live, as your user base starts growing, it will gradually get slower and slower. At the project that inspired this blog post, we had a sudden data load of more than 20k users, and as a consequence the system got impracticably slow overnight.

The Solution

One of the possible technical solutions, the one we used at the project in question, was to extend the table aspnet_Users at our Core database. That is the main table used by .NET Security Provider to store users. What we do is to create a new column Document ID, where this data will be stored in a clean format:

After that, we need to attach some code to both “user:created” and “user:updated” pipelines. This code will be responsible for updating the Document ID column when users are created or updated.

Then your code will probably look like the following. The class CustomProfileIndexManager, responsible for doing the actual Update and Select at the database is not there, but you can easily guess how to build yours.

namespace MyProject.Pipelines 
{
 public class UpdateUserProfileCache
 {
   public void OnUserCreatedUpdated(object sender, EventArgs args)
   {
     var scArgs = (SitecoreEventArgs)args;
     if (!scArgs.Parameters.Any())
       return;

     var user = (System.Web.Security.MembershipUser)scArgs.Parameters.First();

     // Will only act for "extranet" users
     var username = user.UserName;
     if (!username.StartsWith("extranet"))
       return;

     var scUser = Sitecore.Security.Accounts.User.FromName(username,false);

     // Following method is responsible for saving "Document ID" 
     // into the respective column at the database
     CustomProfileIndexManager.SaveUserToCache(scUser);
   }
 }
}

So your problematic code would be replaced by something like this:

// Will do a simple "SELECT * FROM aspnet_Users WHERE Document ID = 'xxxx'" 
var userFound = CustomProfileIndexManager.GetUserByDocumentId(inputDocumentId);

What about the existent base of users?

Of course that will only cover users that are new or updated. If you already have a certain base of users, you can build a simple script to “touch” all your users, such as this:

 var startProcess = DateTime.Now;
 Response.Write("Loading users...");
 Response.Flush();

 // Get all users
 var users = DomainManager.GetDomain("extranet").GetUsers();
 Response.Write(string.Format("OK! ({0}ms)", DateTime.Now.Subtract(startProcess).TotalMilliseconds));
 Response.Flush();

 // Loop into all users
 var counter = 0;
 foreach (var user in users)
 {
   var startUserProcess = DateTime.Now;

   counter++;
   if ((counter % 10) == 0)
   {
     Response.Write(string.Format("--- Total time: {0} minutes
", DateTime.Now.Subtract(startProcess).TotalMinutes));
     Response.Flush();
   }
   Response.Write(string.Format("User #{0} - Email: {1} - Processing...", counter, user.Profile.Email));

   // Following method is responsible for saving "Document ID" 
   // into the respective column at the database
   CustomProfileIndexManager.SaveUserToCache(user);

   Response.Write(string.Format(" OK! ({0}ms)
", DateTime.Now.Subtract(startUserProcess).TotalMilliseconds));
 }
 Response.Write(string.Format("TOTAL TIME: {0} minutes", DateTime.Now.Subtract(startProcess).TotalMinutes));
 Response.Flush();
 Response.End();

Faster Sitecore for Development - All in a single include

Rodrigo Peplau — Thu, 14 Jul 2016 21:42:48 +0000

Since Sitecore 8, load times after builds are getting slower due to the high usage of Speak at the new UI. There is a great post by Kam Figy that summarizes reasons and how to improve this performance.

Tired of having to get back to his article repeating the steps for all my project, I decided to isolate everything in a single Include. There are three options to improve speed, and the patch authomatically covers 2 of them:

Disable SPEAK Precompilation – Covered!
Optimize Compilation – Requires manual change at the Web.config (Check the patch file for instructions)
Disable the SPEAK Experience Editor – Covered!

Please make sure you read the whole article and you’re aware of the impacts.

Download here the include file Sitecore.XFaster (zipped)

When you unzip this file will see the patch is inside a folder “XFaster”. Place this folder, and not the include alone, inside the Include folder. It has to be there due to a conflicting setting at “/Include/ContentTesting/Sitecore.ContentTesting.config” that would overwrite our settings.

SPEAK: ItemTreeView with multiple Roots

Rodrigo Peplau — Fri, 22 Apr 2016 17:52:17 +0000

I’ve being studying SPEAK recently for a module I’m building, and it’s being a lot of fun so far. Of course, when learning anything that imposes a different paradigm, it’s common to get stuck with “simple” things that, in another programming realities, are easy to accomplish.

And then it happened to me: the ItemTreeView component offers exactly the UI experience I want to provide. It lists Sitecore items in a Tree, just like the Content Editor, but also offers a way for the user to select items with checkboxes. That is perfect, but there’s one problem: you can only have one single Root for each ItemTreeView component.

This limitation simply made impossible one requirement I have, which is to list a certain Template and all their fields and Standard Values (Ok) along with all their Base Templates (impossible). Since we can’t predict how many Base Templates (if any) a certain template has, we can’t simply add one or two ItemTreeViews to the SPEAK page and expect they will cover all your needs. Instead, we need to be able to dynamically add multiple Roots to an ItemTreeView. But how?

First Try – Google

As a good boy I first asked Google, but looks like SPEAK components are not yet very widely being subjects of debates in forums and communities worldwide. Most of the documentation are introductory step-by-steps, along with the official documentation which is well descriptive, but not very detailed in terms of what you can do with a certain SPEAK component. Nothing really targeting the ItemTreeView component in general, or my need of having multiple Roots in specific.

Second try – Sitecore Community

For those who don’t know yet, the new Sitecore Community website, built on top of Zimbra/Telligent Community, is the main resource for trading Sitecore experiences. After a quick search, I also see no entries discussing what I needed, and then decided to start up my own question topic: “ItemTreeView with SPEAK : Having multiple RootsItems? Dynamically adding a new one? (with C#)”

Again nothing came out from that topic, so I started to think this may be a good thing to contribute, and at the same time to achieve what I’m trying to have in my component. This post brings the whole solution, along with a Sitecore package with the final code and items that you can download and use.

Ok, nevermind, I’ll build my own

The ItemTreeView component does not support multiple roots out-of-the-box, so I ended up solving this issue by creating a new version of the ItemTreeView component that does it.

Looking the original ItemTreeView component (core:/sitecore/client/Business Component Library/version 1/Layouts/Renderings/Lists and Grids/ItemTreeView) brought me to its View file (\sitecore\shell\client\Business Component Library\Layouts\Renderings\ListsAndGrids\TreeViews\ItemTreeView.cshtml).

These are the important parts we want to pay a special attention:

Line 17 – It’s where the rootId configured by the user is taken:
```
var rootItemId = userControl.GetString("RootItem");
```

Lines 56 to 65 – RootId is used to retrieve the real Sitecore item:

Item rootItem = null;
if (!string.IsNullOrEmpty(rootItemId))
{
    rootItem = database.GetItem(rootItemId, Language.Parse(contentLanguage));
}
if (rootItem == null)
{
    rootItem = database.GetRootItem();
}

Lines 67 to 69 – The TreeView component is setup with the Root Item configured

var rootItemIcon = Images.GetThemedImageSource(!string.IsNullOrEmpty(rootItem.Appearance.Icon) ? rootItem.Appearance.Icon : "Applications/16x16/documents.png", ImageDimension.id16x16);
userControl.SetAttribute("data-sc-rootitem", rootItem.DisplayName + "," + rootItem.Database.Name + "," + rootItem.ID + "," + rootItemIcon);
userControl.SetAttribute("data-sc-rootitempath", rootItem.Paths.Path);

Lines 86 to 88 – The div container is output with its configurations

My first experience were to duplicate the div markup, so I had it twice:

This ended up showing two identical roots – and the “twin” root worked perfectly. That was the confirmation I needed to create an improved version of the ItemTreeView component that can spit multiple roots. With the goal of simplicity, my component will act the same as the original ItemTreeView, but its “RootItem” property now will accept not just one, but multiple IDs (in a pipe-delimited string).

Here are the steps I take:

STEP 1 – Create the new component

Duplicated the original component and gave it the name “ItemTreeView2″
At the duplicated item, deleted the children “ItemTreeView Parameters” (we are going to use the original parameters template)
“Parameters Template” field – it should stay poiting to the original (Client/Business Component Library/version 1/Layouts/Renderings/Lists and Grids/ItemTreeView/ItemTreeView Parameters)
At the “Path” field I made it point to my new View file: /sitecore/shell/client/Business Component Library/Layouts/Renderings/ListsAndGrids/TreeViews/ItemTreeView2.cshtml

STEP 2 – Make it accept multiple Roots

Comment the original line:

//var rootItemId = userControl.GetString("RootItem");

Add our new logic:

var rootItemIds = userControl.GetString("RootItem").Split('|');
var rootItemId = rootItemIds.FirstOrDefault();

Most of the original component will stay as is, and the first Root will be handled exactly how it is natively done.

STEP 3 – Make it spit the other Roots

At the very bottom of the View, we are going to create a new list of HtmlAttributes, which is here used to represent the Tree setup:

@{
    var lstAttributes = new List();
    for (var i = 1; i < rootItemIds.Length; i++)
    {
        rootItem = null;
        if (!string.IsNullOrEmpty(rootItemId))
        {
            rootItem = database.GetItem(rootItemIds[i], Language.Parse(contentLanguage));
        }
        if (rootItem == null)
        {
            rootItem = database.GetRootItem();
        }

        rootItemIcon = Images.GetThemedImageSource(!string.IsNullOrEmpty(rootItem.Appearance.Icon) ? rootItem.Appearance.Icon : "Applications/16x16/documents.png", ImageDimension.id16x16);
        userControl.SetAttribute("data-sc-rootitem", rootItem.DisplayName + "," + rootItem.Database.Name + "," + rootItem.ID + "," + rootItemIcon);
        userControl.SetAttribute("data-sc-rootitempath", rootItem.Paths.Path);
        lstAttributes.Add(userControl.HtmlAttributes); 
    } 
}

And then have the loop for the HTML container:

@foreach (var htmlAttr in lstAttributes)
{
    
    
    
}

And that’s all!

Now I can add a pipe-delimited list of IDs, either by adding it tothe rendering setup or by using my PageCode file:

TreeDsBaseTemplates.Parameters["RootItem"] = String.Join("|",
ComponentItem.DatasourceTemplate.BaseTemplates.Select(p => p.ID.ToString()).ToArray());
TreeDsBaseTemplates.Parameters["Database"] = ComponentItem.DatasourceTemplate.Database.Name;

This way my module now has two ItemTreeViews: first is a normal (native) one, the other is my extended control with roots being dynamically added:

The package

Here is the resulting package of the new ItemTreeView2 SPEAK component. Fell free to download and use it!

ItemTreeView2-1.0.zip

Enjoy!

Using Rules to replace spaces by dashes in Sitecore 7.5 in 3 simple steps

Rodrigo Peplau — Tue, 28 Apr 2015 22:30:19 +0000

In this article I show how to use rules to rename items so, every time an item is saved, spaces gets replaced by dashes. Advantage of using rules is that you can visually setup different kind of conditions, without having to hardcode them at your code.

1) Create the Action that triggers the item renaming

In your master database, add your new Action using the template /sitecore/templates/System/Rules/Action. In this case I’m using the path /sitecore/system/Settings/Rules/Definitions/Elements/Script because the Script Element Folder is already referenced by the Item Saved rules.

The Type field must point to your class that handles the item renaming (use the format “Namespace.ClassName, Assembly“)

2) Create the class that executes the item renaming

This is where your code for checking and renaming the item gets executed (parameter “ruleContext.Item” brings the item being saved).

using Sitecore.Diagnostics;
using Sitecore.Rules;
using Sitecore.Rules.Actions;

namespace BusinessLayer.Rules.Actions
{
    public class AddHyphensToItemName : RuleAction where T : RuleContext
    {
        public override void Apply(T ruleContext)
        {
            Assert.ArgumentNotNull(ruleContext, "ruleContext");
            var obj1 = ruleContext.Item;
            if (obj1 == null)
                return;

            // Scape if no space is at the Name
            var itemName = obj1.Name;
            if (!itemName.Contains(" "))
                return;

            // Rename the item
            itemName = itemName.Replace(" ", "-");
            obj1.Editing.BeginEdit();
            obj1.Name = itemName;
            obj1.Editing.EndEdit();
        }
    }
}

3) Create the Rule to execute the Action above

Add your new Rule using the template /sitecore/templates/System/Rules/Rule, then edit your rules.

In this case what I’m doing is:

Including everything under “/sitecore/content/Site/Home” – because I just want to apply this rule to the items under my Homepage;
Skipping items that doesn’t have a layout – We don’t mind if items without renderings has spaces;
Calling the action “Add Hyphens To Item Name” for the matching Items.

Visual Studio Solution at Sitecore Projects - Avoiding IIS restarts with Robocopy in a Post Build event

Rodrigo Peplau — Sat, 11 Apr 2015 00:47:22 +0000

As very well described by Sean Kearney at this great post, there are two ways to setup a Sitecore solution on Visual Studio for development:

1) Your solution, and code, is fully immersed in the Sitecore web site;
2) Your solution, and code, is outside of Sitecore’s web site and you use some post build process to deploy.

His post supports second option, which indeed has advantages over the first, however a huge drawback (specially for those without SSD) makes our life harder: due to the post build deployment, IIS is constantly forced to restart on every build you make.

In order to handle that issue I’ve invested some time looking for a better way to deploy. What if I copy only the modified changes instead of everything? Perhaps I could often skip the files that causes restarts, such as DLLs and config files…

Robocopy

My solution lied on robocopy, for advanced file copying. At your website project on Visual Studio, put this command at the Post-build event command line box:

robocopy “$(ProjectDir).” “C:\inetpub\wwwroot\YourProject\Website” /E /FFT /XO
exit 0

Parameters:
- /E – Copies subdirectories;
- /XO – Excludes older files – this is the trick, skipping old files;
- /FFT – Assumes FAT file times (two-second precision) – this somehow interferes on how robocopy defines what is “older” to be copied;
- exit 0 – If we don’t add this to the end of the script, our Continuos Integration server breaks because robocopy returns a code different than “0” as success.

In my experience, even when you re-compile the solution without changing anything at the code, your IIS will not restart.

Best way to setup Active Directory Module in a Sitecore Solution

Rodrigo Peplau — Mon, 23 Mar 2015 22:37:40 +0000

Connecting Sitecore with an LDAP Server is pretty easy with Sitecore’s Active Directory Module. Setting up the module is not hard, but if you follow the official documentation you’ll end up updating a lot of your Web.config file, which may be a problem for several reasons:

You can easily lose track on your customizations;
Upgrading Sitecore for a newer version may become harder;
During development you may be forced to turn your LDAP module off, basically undoing the setup of your providers, which is not straight-forward.

After facing these issues a couple times I decided to look for a better approach.

Using Includes

Biggest limitation is by far the need to update your Web.config, as the changes are not in the Sitecore portion and thus cannot be automatically patched by files in your /App_Config/Include folder. Best you can do is to create patches with the configurations, then include them at the Web.config.

Step by step

Add the LDAP connection settings to your ConnectionStrings.config:
At your Web.config, find your section and comment out your , and nodes – these will be all replaced by includes;
At the same level you commented out, add a node as covered at the official documentation:
Still at this level let’s add three includes for Membership, RoleManager and Profile providers:
As well as the three includes for disabling the module. We let it commented for now, which makes the module enabled:

–>
You have also to add your mapped domain(s) to App_Config\Security\Domains.config:
Now create a folder called “AD” at App_Config and drop the six config files that are zipped at this link:
– AD-configs – Don’t forget to review all files (except the “_Disabled.config” that stores the native Sitecore configurations) to make sure you username, password and domains are corretly set!

Now when you want to turn the module off you just have to comment out the lines from #4 and uncomment #5 – pretty easy.

How would you do it: 2 levels menu

Rodrigo Peplau — Mon, 09 Feb 2015 20:24:17 +0000

One of our clients has a development team that will take over the project as soon as we finish our part. They have great developers with no Sitecore experience, and some of their questions are pretty valuable for those starting in the Sitecore world. My answer that follows has a consultancy approach, providing explanations and advises at a higher level.

Here is the question:

In Sitecore, how would you organize architecture and static files – mainly CSS and javascript files – during development of the following two levels menu?

The first level shows an Image and a Title and starts closed:

When the user hovers a block at Level 1, a second part is displayed showing items on Level 2:

Answer

Your static CSS and Javascript files, like in any other web application, must be loaded somehow. At the project we are working, we have a bundle and minification process in place, responsible for loading, minify’ing and caching the files so everything loads faster.

But you can load files the old way:

The implementation itself can be split into two different challenges:

Front-end development
We clearly have a good front-end work here, some dynamic behavior when user hovers around level 1, the look and feel and everything. Basically all HTML markup, javascript and css stylesheets can be prepared without having Sitecore specifically in mind;
Back end development
All necessary to enable the content edition of menu items, and make it work dynamically at a page, including:
- Step 1 - Upload your javascript and CSS files somewhere at your site filesystem (Eg: “/assets/js” and “/assets/css“), then load them somehow (traditional, bundle, etc);
- Step 2 - Define your data structure (templates and fields) to support the content management. It all depends on your requirements – let’s have the following two possible scenarios:
  - Scenario 1 - You may want to feed the menu with pages and subpages you already have in your content tree. In this case you would just use your existing data:
  - Scenario 2 - Or you may be asked to create a dedicated data structure, not pages themselves but pointing to real pages. This data structure would have the following format:
    Menu Item Level 1
    Menu Item Level 2
    And you would keep the item somewhere outside your page’s content tree:
- Step 3 - Create the component/sublayout that implements the menu feature. Following the same two scenarios above:
  - Scenario 1 - In this case you would use the Sitecore API to pragmatically get the Home item, using Children items to render menu’s level 1, and their grandchildren rendering level 2:
```
var homeItem = Sitecore.Context.Database.GetItem("/sitecore/content/Home");
var levelOne = homeItem.Children.ToList();
foreach (var itemLevelOne in levelOne) {
   // This item represents a Level 1 menu block
   var title = itemLevelOne.Fields["Title"].Value;
   var image = itemLevelOne.Fields["Image"].Value;
   var levelTwo = itemLevelOne.Children.ToList();
   // ... do whatever you need with Level 1
   foreach (var itemLevelTwo in levelTwo) {
      // Here you work your Level 2 item
      var titleLevelTwo = itemLevelTwo.Fields["Title"].Value;
   }
}
```
  - Scenario 2 - This implementation would be very similar to the first scenario, except that you would have to start at your repository folder (Eg: /sitecore/content/Lists/Menu) instead of the Home item.