Run Multiple Solr Instances for Sitecore

At Arke, we have recently made the switch to recommending Solr as the 'default' indexing solution for Sitecore rather than Lucene.  If you're wondering which to use on your project, please see Sitecore's document on when to use Solr over Lucene.

Switching to Solr

There was a little pain involved in switching from Lucene to Solr for an active project, but luckily, my co-worker, Patrick Perrone had already been down the path of getting Solr running on his Windows machine and provided an excellent step-by-step guide on how to make it work.  If you haven't already, see his 3-part series on Making Sitecore 8 and Solr Work Together.

Thanks to Patrick, getting Solr running was a breeze.  This worked great for my active project, but now I'm starting up new projects where Solr will be the indexing mechanism from day 1.  How will I separate client Solr cores from one another?

Installing Multiple Instances of Solr on your (Windows) Machine

Patrick's install guide works great when you're only going to be running a single instance of Solr, but in order to get a second instance of Solr running on my machine, I had to make some minor modifications.

Note: These steps assume you already have a solr instance up and running with the proper Sitecore-generated schemas.  If you haven't followed all the steps to get Solr running with Sitecore, please do those first to save a bit of configuration time on your cores later.

1. Stop your Tomcat service.
   
   
2. I installed my Solr directory at C:\Solr and all my standard Sitecore and custom cores were then in directories under there.  In order to clean things up, I created a new folder named ClientName1 that would now contain the cores for that client.  Go ahead and create a folder named ClientName2 while you're here for the project you are starting up.
   
   
3. Once created, pull all the content from the root of C:\Solr into this new ClientName1 folder.
   
   
4. Since the original cores were already configured to work with Sitecore, it's a simple matter of copy/pasting all the cores into a second client folder.  Copy all the files from the root of ClientName1 and paste them into ClientName2.  At this time, you should remove any custom cores that were defined specifically for client 1.  You can leave all the Sitecore cores as we're going to rebuild them as a final step anyways to get client 2 data into them.  Your Solr root should now just have client folders in it, nice and clean-like.
   
   
5. Go into your 'Monitor Tomcat' tool and remove the Java Options you set as part of the initial configuration of Solr.  In my case, I removed Dsolr.solr.home=C:\Solr  This option tells Tomcat where the home Solr directory is, but it assumes there is only one instance running.  Our next steps will define the multiple home directories.
   
   
6. Move the solr.war file out of the root of your ...\Tomcat 8.0\webapps\ directory.  In my case, I moved the solr.war file up one directory from C:\Program Files\Apache Software Foundation\Tomcat 8.0\webapps to C:\Program Files\Apache Software Foundation\Tomcat 8.0\  Having the war file in the webapps directory is another indicator to Tomcat that it's only running a single instance and it will ignore the configuration files we are going to set in the next step.
   
   
7. Go to your \Tomcat 8.0\conf\Catalina\localhost directory and create new XML config files for each client.  I named mine solr-<clientNameX>.xml  Note that this filename will be how you access your Solr cores in the browser.  In this case, I'll access my two clients by http://tomcat:8081/solr-clientName1 and http://tomcat:8081/solr-clientName2.  You can name them whatever you like, but the contents should look like this:
   
   

   <Context docBase="C:\Program Files\Apache Software Foundation\Tomcat 8.0\solr.war" debug="0" crossContext="true" >
       <Environment name="solr/home" type="java.lang.String" value="C:\solr\ClientName1" override="true" />
   </Context>
   

   
   Here, you are referencing the path to the solr.war file that we moved and are setting the Solr home directory to where all your cores are for this client.


8. Copy the XML file you just created and paste it to create the XML file for ClientName2. Edit the file and change the path to from the C:\solr\ClientName1 directory to the ClientName2 directory.
   
   
9. Start your Tomcat service back up.
   
   
10. Navigate to http://tomcat:8081/solr-clientname1 and http://tomcat:8081/solr-clientname2 and verify that both instances are running. (using the port number used when configuring Solr and the file names for the XML configs you defined)
    
    
11. Edit your ContentSearch.Solr.ServiceBaseAddress setting in the Sitecore.ContentSearch.Solr.DefaultIndexConfiguration.config file to point to the correct new instance of Solr.
    
    
12. Once running, go back to your Sitecore instances and rebuild your indexes!

You can now safely run Solr on multiple projects and have confidence that each client's cores will not be mixed up with one another.

Sitecore 8 Bug: Link Sets Anchor Target to Active Browser

We recently ran into an issue while trying to render links set in Sitecore 8 (Update 3, to be specific).  When using the "General Link" field to insert a link, we discovered that the "target" options for the link were incorrect.  The options provided out of the box were "Active Browser", "Custom" and "New Browser":

One would assume that "Active Browser" would set the target of the anchor tag to "_self" or "_top" so that it opens in the same window.  Unfortunately, what happens is that Sitecore literally puts "Active Browser" in the target attribute, which is not valid and ends up actually opening a new window/tab.

Workaround/Fix

I opened a support ticket with Sitecore and they acknowledged this as a bug and it should be fixed in a future release.

In the meantime, you can adjust the settings of the "Link Details" box to display new target options as follows:

1. In the "Core" database, navigate to the "/sitecore/client/Applications/Dialogs/InsertLinkViaTreeDialog/PageSettings/TargetsSearchPanelConfig" item.
2. In the "Root" field of the "Filters" section, specify the "sitecore/client/Business Component Library/System/Texts/Targets" item. (default is "sitecore/client/Applications/Dialogs/InsertLinkViaTreeDialog/PageSettings/Targets")

Now, when you insert a link, you see target options that will work when rendered in the browser: "_blank", "_parent" and "_top":

Note: If you already had links set to "Active Browser", leaving the default of "SelectTarget" will still render the target as "Active Browser."  You need to open the "Insert Link" option, select "Insert" and then save the item for it to use the proper value.

Map a Drive to your Solution Folder to Avoid the File Name Length Error in TDS

I recently came across an article that was posted on Twitter about overcoming the dreaded 'File Name Length Error' in Team Development for Sitecore (TDS).

The article makes users aware of a built-in feature of TDS that allows you to use name aliases to overcome length issues.  In my experience, this generally works, but there are always times down the road where no amount of short aliases help due to the nested structure of your Sitecore solution combined with where you save your Visual Studio solution files on your dev machine.

What I like to do is map a drive to my solution files.  This takes my path from "C:\Users\ctaylor\Documents\Visual Studio 2013\Projects" to "Z:\".

I haven't seen the error in a while, but should I encounter it in the future, I can additionally utilize the alias feature of TDS.

Restore Access to an Administrator Account

For additional security, one of the first things I do when beginning work on a new Sitecore site is to remove the 'standard' "admin\b" account and instead create a new admin account with a different name (and password, of course!).  After doing this recently, we ran into a problem when the password for the new account was . . . lost.

Existing Functionality

There are some Sitecore tools designed to help manage accounts and access when the administrator user is unable to log in.  Unfortunately, the tools both assume that the user you are using is the 'standard' "admin" account and also that you haven't lost the password, but instead have been locked out of the account.  See John West's post regarding some common ways to get back in.

As John mentions, when the administrator password has been lost, you can simply log in with another account with administrator access in order to reset the password of the first account.  In our case, we only had one administrator account and had no way to get in otherwise.

The solution is to modify an existing tool.

Modify the "unlock_admin.aspx" Page

The "unlock_admin.aspx" page can be found at "/sitecore/admin/unlock_admin.aspx"  Unsurprisingly, the purpose of this page is to unlock the "sitecore\admin" account.  What we need to do is use this page to grab our admin user and reset the password.  The existing code only unlocks the locked admin account:

Membership.GetUser("sitecore\\admin").UnlockUser();

You can instead replace this with code that will set a password on any account in Sitecore:

MembershipUser mu = Membership.GetUser("sitecore\\[Your Administrator Account]");
mu.ChangePassword(mu.ResetPassword(), "[Your New Password]");

This code takes advantage of the .NET membership provider in order to change the password of the account specified.  Enable the button, view the page in the browser, click the button and you're done!  The password is changed and you can now log back in!

Just try not to lose the password this time.

Note: As John mentions in his post, always remember to go back and disable the 'unlock' button.  Also, while I have provided a solution that resets an administrator account password, please don't deploy this file.  It should only be used temporarily to get back into Sitecore.

Cascading Renderings in Sitecore 8

I have a client that has a need to have managed content within their navigational menu.  We were able to dynamically insert placeholders and control the datasources for the renderings inserted.  When we went to another page in the site, we realized that the renderings we inserted were only associated with the original page instead of the entire site as we intended.  We needed to cascade the renderings down to all the subpages.

It's been done before

There are already some great starting points out there from Alex Shyba and Pavel Veller.  Alex originally wrote about it and Pavel updated the code to work with MVC.  Thanks guys!

One small change

With Sitecore 8 comes the idea of Versioned Layouts.  Since we can now have a shared and final layout, the code should be updated to check the "FinalLayoutField" so that we have access to any renderings added using the Experience Editor.

Field layoutField = parent.Fields[FieldIDs.LayoutField];

needs to be changed to:

Field layoutField = parent.Fields[FieldIDs.FinalLayoutField];

Create a Custom Condition in Sitecore 7.1+

A while back, I wrote a blog post on Creating an HTTP Referrer Condition in Sitecore 6.6.  I actually referenced that same post recently when attempting to create a custom condition in Sitecore 8.  To my surprise, things have changed a bit.  I had to backtrack a bit, but discovered that the process for implementing custom conditions that show under a custom section title in the personalization interface actually changed in 7.1.

The process for creating the custom condition in code has remained the same, but the way in which you insert that condition into Sitecore has been updated.  Let's walk through how to create and use a custom condition in Sitecore 7.1 through at least Sitecore 8.

Why Create a Custom Condition?

There are a number of built-in conditions that can be used in order to personalize Sitecore components.  Sometimes however, you run across a client that has needs that extend beyond those of the pre-canned conditions.

Create a new Tag

Create a new Tag item at "\sitecore\system\Settings\Rules\Definitions\Tags".

We will later be associating this tag with our custom Element Folder.  For our purposes, I named the tag "Client Name".

Add Your Tag to the Conditional Renderings

Once your tag is created, you want to associate it with the conditional renderings.  This ultimately allows your custom conditions to be displayed when attempting to peronalize a component.

Add the new tag to the "Default" Tag Definition item at \sitecore\System\Settings\Rules\Conditional Renderings\Tags\Default." Specifically, you want to include your tag in the "Tags" field of the "Taxonomy" section of the "Default" Tag Definition item.

Create a New Element Folder

The name of your Element Folder will be the name of the grouping of conditions that you create.  You can break out your conditions based on the type of condition but I find it more beneficial for clients to just create an Element Folder that is named after the name of the client.  This allows the client easy access to all their custom conditions.

After creating your Element Folder, associate the Tag created earlier so that our folder will show when attempting to personalize a component.

Create your Condition

Once you have your Element Folder, you need to create your custom condition.  As mentioned, this part remains the same as in previous versions where you write custom code to perform some action that returns a boolean value that Sitecore can test against.

Instead of duplicating this code, I'm going to create a test condition under my "Client Name" Element Folder in order to demonstrate the functionality.

Note: You would ordinarily have some more complex text that would allow users to select different operators to test conditions.  You would also specify the type of your custom condition.

Personalize!

We've done all the configuration work and now we just want to take advantage of the custom condition.  Open the Experience/Page Editor and choose a component to personalize.  After choosing "Create/edit the personalization options for this component" button, click "New Condition".  Give your condition a name and select "Edit" to find the condition you created.

And there you have it.  We created a custom condition and configured Sitecore to be able to show it under a custom Element Folder so that content author have easy access to it.

Sitecore Tip: Set a Custom Desktop Background

When I work on a new project, oftentimes one of the first things I'll do after getting Sitecore running is to create custom desktop backgrounds for each environment.  This really comes in handy as I switch between environments and lose track of where I am. (dev, stage, prod, etc)

It's very simple to change the desktop background and based on the feedback I've received from other developers, it's something that is often overlooked.

Create a New Background Image

The easiest way to create a new image is to take an existing Sitecore background from "/sitecore/shell/Themes/Backgrounds" and edit it to include whatever text or identifiers will help you differentiate it from the other environments.  In my case, I just borrowed the "Blue.jpg" image and added my text.

Save the Image

A bit of a spoiler from the 'create' section above as to where to save the image, but save it to the 'backgrounds' directory at "/sitecore/shell/Themes/Backgrounds."

Change the Background Image

There are actually two ways to change the desktop background image.

1. Log into Sitecore using the "Desktop" interface, right-click on the desktop, choose "Properties" and then select your new image.
2. Log into Sitecore using the "Desktop" interface, click the "Sitecore" button, choose "Control Panel", choose "Preferences", click "Change Your Desktop Background" and then select your new image.

Note that changing the background only changes it for the current user.  All your other users are free to use whichever background suits them.

So as you can see, it's a super-simple way of giving you an additional cue to which environment you are about to install that potentially unstable package to . . .