With the multiple languages and the complexity level of my company’s site, this was not a simple process of just running a couple of SQL update scripts and modifying some lines in the web.config.  This upgrade took at couple of weeks and there were a lot of lessons learned along the way.  Hopefully, my lessons will save you some time if you are going the same route.

By the way, shout out to @alexshyba once again, for pointing me to the right places and saving me hours upon hours of time.

Break Tag Embedding

Even though Sitecore documented this as a resolved bug, I still experienced this issue.  If there are new lines in a rich text or multi-line field, HTML break tags (<br>) get inserted.  While it’s usually hard to notice this, we keep XML schema in multi-line text fields, so any extraneous characters and the schema is broken.

The good news is, I caught this earlier and documented a fix for it here: http://blog.image0.com/sitecore/sitecore-multi-line-removing-br-tags/

Sitecore Query Performance

If v6.1 was forgiving with overly broad queries, v6.5 won’t be.  It’s not out of spite or to teach you a lesson.  I believe there was some security code added to the internal Sitecore query mechanism.  There was a huge performance difference for me between the two versions – we are talking seconds, not milliseconds.

If you are on the same boat, you have 3 choices:

1. Optimize your queries
2. Consider using Fast Query instead of the traditional Sitecore Query mechanism (read my findings on it below before you do)
3. If 1 and/or 2 do not work, I’d look into using Lucene search.

Fast Query

It doesn’t take long to sell Fast Query over the traditional Sitecore Query.  When I was writing a product recommender type app that generated results based on submissions, I was sold immediately by Fast Query.  The caveat with it, of course, is that, in addition to returning unordered list results, it also doesn’t guarantee to return them in the context language.  This means that if you are on a US site and you do a Fast Query, you may get some items from other languages (if they are defined).

I’m not sure if it was luck or otherwise, but on v6.1, I’ve never encountered that.  Results were always from the same language.  When upgraded to v6.5, every other query had mixed results.

There are a couple of different ways to achieve this with the Sitecore API in C#, but you basically want to check for 2 conditions -

1. Make sure the Sitecore Item’s Versions.Count property is greater than 0.
2. On the Sitecore Item’s Language.FirstOrDefault() language, do a Database.GetItem() passing in the Item ID and the context language.

If you check StackOverflow, there is actually a pretty good code block that does both steps here: http://stackoverflow.com/a/8232087

Multi-Server Publishing & EventQueue

The staging module ends up being history in v6.3 and up, which is great news if you have ever had to set it up for more than 1 server – a lot of tedious configuration and painful investigation of logs if something went wrong.  In v6.3 and up, all you have to do is set EnableEventQueues property to “true” in your web.config, and it publishes your items and clears the cache correctly whether you have 1 or n balanced web servers.

Web.config Consolidation

My original web.config was huge in size and had a lot of country and environment specific values.  For example, my UK domain on staging was different from my UK domain on production.  Both had to be specified in the <sites> section of the web.config.  In addition to it being a pain to manage it from a size perspective, there was also the risk of it being overwritten by someone who didn’t know any better.

For Sitecore configuration, your App_Config directory includes an /Includes directory. What a catchy name, right? In here, you can extract your Sitecore configuration from the web.config and then just dump it here.  Just make sure your file has a .config extension for it to get picked up.  The IntoTheCore blog has a really good post on how to do this here: http://intothecore.cassidy.dk/2009/05/working-with-webconfig-include-files-in.html .

There is a neat way of seeing exactly what gets cooked up at runtime, as far as your Sitecore configuration goes.  Try opening up http://[yoursite]/sitecore/admin/showconfig.aspx to get an XML dump of your Sitecore configuration.

Please note that a) this only includes your Sitecore configuration, as opposed to <system.web> or other non-Sitecore related configuration data, and b) you can’t include non-Sitecore configuration in the /Includes folder.  You can extract modules from the web.config if they have an configSource or a similar property – which is what allows your DB strings to live in ConnectionStrings.config as opposed to the web.config file.

Testing/Deployment Strategy

So, you recompiled your code with the new version of Sitecore.Kernel.dll and your site renders.  Great.  I wouldn’t flip the switch so fast.  Keep in mind that for us, the majority of the duration for this upgrade went to testing and fixing issues.

What I recommend is having a QA team or at least a second set of eyes perform the regression tests side-by-side – run a box with v6.5 and have them compare it to your production environment (which is running v6.1 or something older than v6.4).

I had my load-balanced web servers, so to simplify deployment, I just created new blank databases for v6.5, published the entire site to them, and changed my connection string.  That way, the v6.1 DBs and configuration was still intact on production.

When the testing was completed, all I had to do was clone the webroot on the CD to all its load-balanced brethren and that was it – zero downtime.  Because…

A little planning saves a lot of fan cleaning.

Additional Lessons

- In a perfect world, we’d be able to freeze the environment – both code and content – and be done with this in 1-2 weeks tops.  But, because we don’t live in a perfect world, there were changes that were constantly happening.  For managing the code, we created 2 branches – v6.1 code branch with the assemblies currently on production, in case we needed to fix live bugs, and a v6.5 code branch in case we needed new code development to start that couldn’t wait for us to go live with 6.5.  Branching definitely worked out for us at the end.

- If your database is anything like ours – very big and multilingual, sometimes it’s better to start with a clean v6.5 install and port things over slowly, but confidently.  I tried an in-place upgrade about a year go.  That was only going up 2 versions, from v6.1 to v6.3.  That blew up in my face because of web.config typos.  It’s definitely easier to start clean and go from there.

Conclusion

I truly hope these lessons will help you in your upgrade ventures by preparing you for the “gotchas” that could stand in your way.  At the end of the day, it’s definitely worth it knowing that a) you are not obsolete anymore and running the latest and greatest (for the time being), b) you open yourself up to a full library of shared source modules and new features that weren’t available in the older versions.  My favorite one – Sitecore Azure.  By the way, I blogged about that experience as well, in a series titled “To The Cloud” here: http://blog.image0.com/tag/sitecore-azure-series/

Goal
Clear external image/CDN cache when a media item gets published.

Solution

The PublishProcessor object is located in the Sitecore.Publishing.Pipelines.Publish namespace. We will need to inherit from this object to your own class and override the Process(PublishContext) method with our own custom functionality.

The PublishContext that’s passed in by Sitecore’s publishing processor has a list of items being published.  All we have to do is iterate through the list and use the Sitecore Item’s Path.IsMediaItem property to determine if it’s a media library item or not.  If it is, we just pass it or its full path to a custom method and use whatever API is provided by your CDN of choice to force refresh on it.

This is all being done in a separate Visual Studio project, so when we are done, we get a nice assembly .dll file out of it that we attach to the publish processor in our web.config.

The Code

using Sitecore.Data;
using Sitecore.Data.Engines;
using Sitecore.Data.Managers;
using Sitecore.Diagnostics;
using Sitecore.Publishing.Pipelines.Publish;

namespace Sitecore.Custom
{
	public class CacheClearer : PublishProcessor
	{
		private readonly List _cacheQueue = new List();

		public override void Process(PublishContext context)
		{
			Assert.ArgumentNotNull(context, "context");
			ProcessPublishedItems(context);
		}

		protected virtual void ProcessPublishedItems(PublishContext context)
		{
			if (context == null || context.PublishOptions == null || context.PublishOptions.TargetDatabase == null)
			{
				Log.Error("Context and/or publish settings are null",this);
				return;
			}

			ProcessHistoryStorage(context.PublishOptions.TargetDatabase); //this updates the housekeeping fields

			Log.Debug("There are " + _cacheQueue.Count + " items in the cache queue");

			var mediaUrls = = new List<string>();

			foreach (var id in _cacheQueue)
			{
				if (context.PublishOptions.TargetDatabase.Items.GetItem(id) != null)
				{
					var item = context.PublishOptions.TargetDatabase.Items[id];
					if (item.Paths.IsMediaItem)
						mediaUrls.Add(akamaiPath);

				}

			}

			SomeCustomCDNProcessor.RefreshMediaUrls(mediaUrls);

			Log.Info("*** Processing cache clear for item: " + id, this);
		}

		private void ProcessHistoryStorage(Database database)
        {
            _cacheQueue.Clear();

            var utcNow = DateTime.UtcNow;

            // accessing the date of last operation
            var from = LastUpdateTime(database);

            //Log.Debug("Last Update Time: " + from);
            //Log.Debug("Database: " + database.Name);
            // get the history collection for the specified dates:
            var entrys = HistoryManager.GetHistory(database, from, utcNow);
            //Log.Debug("entry count: " +entrys.Count);
            if (entrys.Count > 0)
            {
                foreach (var entry in
                    entrys.Where(entry => !_cacheQueue.Contains(entry.ItemId) && entry.Category == HistoryCategory.Item))
                {
                    _cacheQueue.Add(entry.ItemId);
                    database.Properties[LastUpdate] = DateUtil.ToIsoDate(entry.Created, true);
                }
            }

            // writing back the date flag of our last operation
            database.Properties[LastUpdate] = DateUtil.ToIsoDate(utcNow, true);
        }

        protected DateTime LastUpdateTime(Database database)
        {
            var lastUpdate = database.Properties[LastUpdate];

            if (lastUpdate.Length > 0)
            {
                return DateUtil.ParseDateTime(lastUpdate, DateTime.MinValue);
            }

            return DateTime.MinValue;
        }

 }
}

The web.config changes are as follows:

<publish help="Processors should derive from Sitecore.Publishing.Pipelines.Publish.PublishProcessor">
        <processor type="Sitecore.Publishing.Pipelines.Publish.AddLanguagesToQueue, Sitecore.Kernel" />
        <processor type="Sitecore.Publishing.Pipelines.Publish.AddItemsToQueue, Sitecore.Kernel" />
        <processor type="Sitecore.Publishing.Pipelines.Publish.ProcessQueue, Sitecore.Kernel" />
        <processor type="Sitecore.Custom.CacheClearer,CustomCacheClearer" />
 </publish>

“hitting the green arrow to deploy content delivery environment in #Sitecore #Azure and actually seeing it work – brings a tear to my eye.”

You, too, can weep tears of joy after seeing exactly how magical this process is.  I did bang my head against the wall a couple of times, but the wonderful support staff @ Sitecore, including Jesper Ravnsgaard, Product Manager for Sitecore, did help me reach the finish line.

First thing is first – you have to make sure you have met all the prerequisites and read the known issues from my previous post.  The second thing you want to do is download the Windows Azure SDK from here.  The third thing is download the latest version of Sitecore Azure from here, which is currently at version 1.0.4.  If you read my previous post, you should have already sent out a request for and received a Sitecore Azure environment file.  You cannot proceed without it.  So don’t try.  Seriously. Don’t.

Install The Certificate

You know the “10% inspiration/90% perspiration” shpiel? Getting the certificate to work correctly was the 90% perspiration part me.  You have to follow each step verbatim, otherwise you will lose valuable time going through logs and emailing support.  If you get stuck and this post does not help you, the latest version of the Troubleshooting Guide should help you pass this hurdle; otherwise, there is always Sitecore Support.  My problem during this is that I was working on Sitecore Azure v1.0.4, while my guide was v1.0.3.  Small detail that cost me 2 days.  No biggie.

To install the certificate, there are a couple of steps:

1. Make sure you are on v1.0.4.  You will have to generate the certificate as Administrator.  The most full-proof way is via command prompt.
2. Open command prompt up as Administrator
3. cd to {your sitecore install directory}/sitecore/shell/Applications/azure.  I know that the documentation states to do it from /sitecore/admin/azure, but I was getting System.IO.FileNotFound exceptions until Sitecore Support pointed out that for v1.0.4 you need to be doing this from the former directory.
4. Type MakeCert.bat to generate and install the certificate.
5. The certificate will need read rights by the account under which the App Pool is running.  In IIS7, there is a user group called IIS_IUSRS. Make sure to grant it, along with NETWORK SERVICE read rights.  You would do this in the Certificates Snap-In under mmc.exe.  Screenshots and directions are located on page 5 of the Troubleshooting Guide.

Know Your Rights

The way Sitecore Azure deploys your files is by copying the all your web files from the website root ({sitecore install path}\{website path}) to a WebRole directory under the $data folder of your installation.  Therefore, you will need to grant read access to the NETWORK SERVICE user and IIS_IUSRS user group to the entire website root directory and its subdirectory.  In some cases, you may see that both will need write access to your web.config.  You can skip that if you are reluctant to do that, but your log files will immediately tell you if there is a problem with updating the web.config.

“To The Cloud”

Before we can proceed, part of deploying to the cloud is creating the core and web databases in your Azure account.  It won’t be able to do so until you have allowed it access via firewall rules.  You will need add to the external IP of the server you are deploying this from into the firewall rules.  You can do that by navigating to the “Databases” section of your Azure portal, selecting your database, and clicking Firewall Rules.

At this point, your certificate is installed and your permissions are set up, and your SQL Azurefirewall rules are set.  You are ready for flight takeoff.  You can now click the Sitecore “start” button and navigate to Azure.  If this is your first time running it, it will ask you to upload the environment file you received from Sitecore.  Next, if it doesn’t hang or give you any certificate errors, congratulations.  You are quite good at following directions.  If not, try again from the top.

Clicking the green button will start the process that will copy your website files to the data folder and deploy them to the cloud.  This process will typically take 2-5 minutes.  If you are at this point, you can breathe easy.  The rest is a piece of cake.  After the transitioning is complete, you will get a long URL where your app is hosted (something.cloudapp.net).  If you are like me, you will probably click it before you even finish reading this sentence and find nothing.  Why is this the case, you ask?

Your files are deployed, but your databases are blank.  Luckily, it’s an easy step – we just publish the entire site to the azure target.

Note: I ran into some issues here.  For some reason, when clicking “publish,” I got an error that the connection string for the azure target was missing.  I contacted Sitecore Support and they said it may have been a fluke, but in case this happens to you, just insert it manually into your /App_Config/ConnectionStrings.config file.  The exact connecting string can be found in Sitecore’s Content Manager under /System/Azure if you navigate down to the database.

After it publishes, you can click on the hostname in the top Windows Azure icon which will end with cloudapp.net.

That’s it.  Quite an easy process if you follow the directions step by step.  It gets a little more complicated if you have additional databases, which you will have to create through SQL Azure, but other than that, this is a very straight-forward approach.

Do not hesitate to reach out to me with any questions or comments about this.

This post will cover the prerequisites and getting out the gate with Sitecore Azure.  If you haven’t yet received your Azure account credentials, check my previous post.

Also, there are two things to bear in mind.

1) Sitecore Azure is its beginning developmental stages, so while it may work in most common scenarios, it will not work in all (see known issues below).

2)  I am also new to Azure development, especially Sitecore Azure, so this is as much a learning experience for me as it is for you.  If I stumble on anything contradictory in future posts, I will be sure to update any incorrect details.

Known Issues

Before you continue, it’s important to see if there are any deal-breakers.  The following are some important considerations from the Sitecore Azure Troubleshooting Guide.

• Sitecore Azure does not support file media.  An example of this would be an app that lets a user upload a picture to the file system.
• Cherry-picked file deployments to the content delivery environment are currently not doable.  If you want to deploy even something as small as a CSS or a javascript, you will have to deploy the entire solution.
• There is an update button.  It looks for files that are different from the files deployed in the cloud and copies the delta.  On the one hand, it doesn’t overwrite the entire solution, but on the other hand, it copies the entire delta, so if you wanted to deploy a newer CSS file, but not the newer javascript file, you would have to 1) backup the files you don’t want deployed, 2) restore them to the stable versions on production, 3) click the update button, and 4) restore your changed files.
• For emergency file patching, you have RDP access to the instances.

The last prerequisite before the install is getting your Sitecore Azure Environment File.  I am going to request mine as soon as this post is published.  To get your environment file, email azure.accounts@sitecore.net with the following information:

• The location, hostname, login and password for the Microsoft Azure DBServer(s).
• Your Certificate file: /sitecore/admin/azure/certificate.cer file from Sitecore Azure installation.
• Your Sitecore license file

I have yet to request and receive mine, but when I do, I’ll be sure to post the installation details with some screenshots and walk you through the installation.  In the meantime, please refer to the following Sitecore documents for detailed information:

• Documentation
• Troubleshooting Guide
• Release Notes

I don’t think my workload will free up anytime soon, but I’m going to commit to another Sitecore series of blogs called Sitecore Azure: To The Cloud. It might take some extra spare time, but I plan on documenting everything in detail in multiple posts, even if it takes a while.

Without further ado, the first step is going to be getting an account. You can get a trial account at http://windowsazurepass.com with this promotion code – TBBLIF . If you are reading this after the code expires, try searching for another one unless the program has been discontinued, at which point you will have to provide a credit card.

Account activation will take 2-3 business days. I’ve just submitted mine. We’ll see what happens…

[UPDATE] Found my account activated this morning.  Stay tuned…

To implement, you will need 3 things:

1. Your own CustomCache class
2. A CacheManager class
3. The code that will be using the cache

Your own Custom Cache class

Because Sitecore.Caching.CustomCache is an abstract class, you cannot directly instantiate it, but you can inherit from it.

namespace Sitecore.Custom
{
    public class MyCustomCache : Caching.CustomCache
    {
        public MyCustomCache(string name, long maxSize) : base(name, maxSize)
        {

        }

        new public void SetString(string key, string value)
        {
            base.SetString(key, value);
        }

        new public string GetString(string key)
        {
            return base.GetString(key);
        }
    }
}

Cache Manager

You will need a static Cache Manager to “manage” your CustomCache. This manager will instantiate the CustomCache object in the constructor. This is where you will give it the name and the size – both of which will show up in under /sitecore/admin/cache.aspx which you will be able to clear.

namespace Sitecore.Custom
{
    public static class CacheManager
    {
        private static readonly MyCustomCache Cache;

        static CacheManager()
        {
            Cache = new MyCustomCache("MyCustomCache",
                     StringUtil.ParseSizeString("10KB"));
        }

        public static string GetCache(string key)
        {
            return Cache.GetString(key);
        }

        public static void SetCache(string key,string value)
        {
            Cache.SetString(key, value);
        }
    }
}

Your code that calls it

You can use the code below to set and get your cached values.

CacheManager.SetCache("myData","myDataValue");
string myData = CacheManager.GetCache("myData");

So why use this as opposed to the .NET cache out of the box? For me, it’s the simple convenience of having it clear anytime I do a Sitecore publish operation.

That’s all there is to it.

Project Framework

For our framework, we chose SCRUM. In a 4-person web team, all sitting within reach of each other, we have found that over the years, this works best for us. The designers know what the developers are doing and vice versa. Like SCRUM, we are fast and efficient. In fact, I am very proud of my team. As a 4-person standalone web design shop, I think we’d do rather well, assuming we wouldn’t have to pay for our own healthcare.

In the role of ScrumMaster, the first thing I did was set up a storyboard in scrumy.com (pronounced scruh-mee, not screw-me, which is a completely different NSFW site). If you haven’t used this tool before, give it a try. Its drag-and-drop interface lets you create stories, associate tasks with a user, and drag-and-drop them from column to column (to-do, in progress, verify, complete). Maintaining a storyboard like this, not only puts your project manager at ease, who may be in a remote location, but also keeps the team sane when you need to get out of the coding zone and get a perspective on the project progress.

Design Strategy

If you only get one takeaway from this, it’s that no matter how small the project, proper design and planning will always serve a benefit.

Since we adopted Sitecore as the official CMS tool, our design was already partially established. With this being a small product informational site, our Sitecore template design was not unlike the Sitecore demo project. The difference between our solution and the demo project is the level of OOP design.

What I have seen with novice Sitecore developers is as soon as they start developing a site, they completely abandon n-tier architecture and OOP best practices. Sitecore does not and should not replace a good OOP design.

Take the Product entity as an example. A Product may have a name, image, link, and a description. In a 3-tier (DAL/BLL/UI) architecture, you would create a class for it in the Business Logic Layer. In our case, we display products in a category page and in a product page. If you care about your code, there should be an alarm that goes off that detects duplicate functionality and tells you to extract it to one common place; hence, the need for our BLL assembly.

If you are still not seeing the benefit, consider the readability and general elegance of binding an asp:repeater to a List of products with dot notation and intellisense, as opposed the ugly DataBinder.Eval() function.

<asp:Repeater ID="rptProducts" runat="server">
	<ItemTemplate>
		<a href="<%#((Product)Container.DataItem).Link)" %>
			<%#((Product)Container.DataItem).Image) %><br/>
			<%#((Product)Container.DataItem).Name) %>
		</a>
	</ItemTemplate>
</asp:Repeater>

As another best practice, you will want a Core assembly to keep track of static constants and variables. In our case, it holds the URL to our CDN which is different from environment to environment.

Team Development Environment

After the design is knocked out, I have to make sure everyone’s development environment is properly set up and wired up to TFS. I’ve seen developers skip this step until the project is complete, but I cannot stress this enough – these shortcuts will only make your life more difficult. Set up TFS before you start development and don’t forget to check in changes to avoid having other developers overwrite your changes or hearing the never-old “well… it works on my machine” phrase.

The Sitecore templates were done during the design phase in a true Agile environment – in a locked conference room with the entire team, so at this point, it was safe for everyone’s environment to be pointed at the same Sitecore database environment since the templates weren’t really changing.  I created the solution with by including the Sitecore files and assemblies, created BLL/Core projects, and checked everything into TFS, after which everyone did a GLV (get latest version).

Sitecore Deployment

We build this site using Sitecore v6.4. With this version, there is no staging module that you have install like with v6.1, so I thought that after I take care of the checklist in Sitecore’s Configuring Production Environments handbook, I’d be home free, but not so. If you want the cache to automagically clear after publish, you will have to set the EnableEventQueues property to “true” in your web.config

Takeaways

A little planning and preparation before will save you a lot of fan cleaning later. No matter how small the project, if you are in a real world environment, chances are it will at some point grow or will probably need maintenance. Following best practices in the beginning, you will avoid cursing yourself and/or your team when it’s time to do that maintenance or expansion.

• Remember to use a project framework that will fit your team and organization, whether it’s SCRUM or something else. If it’s something else, you will still find scrumy.com to be useful for simple task management.
• Use TFS, or something else if you don’t have TFS, for source control early on before development kicks off.
• Do not disregard a good n-tier design just because you are working in a CMS.

Check out @kaidez’s cross-blog on this topic here: www.kaidez.com.

using System;
using Sitecore.Diagnostics;
using Sitecore.Pipelines.RenderField;

namespace Sitecore.Support.Pipelines.RenderField
{
    public class SetParameters
    {
        // Methods
        private static void MoveParameterToRender(RenderFieldArgs args, string name)
        {
            if (args.Parameters.ContainsKey(name))
            {
                args.RenderParameters[name] = args.Parameters[name];
                args.Parameters.Remove(name);
            }
        }

        public void Process(RenderFieldArgs args)
        {
            Assert.ArgumentNotNull(args, "args");
            if (args.FieldTypeKey == "multi-line text" || args.FieldTypeKey == "memo")
                args.RenderParameters["linebreaks"] = "\n";// specify linebreaks characther here

            args.DisableWebEdit = string.Compare(args.Parameters["disable-web-editing"], "true", StringComparison.InvariantCultureIgnoreCase) == 0;
            MoveParameterToRender(args, "show-title-when-blank");
            MoveParameterToRender(args, "linebreaks");
            MoveParameterToRender(args, "default-text");
        }
    }
}

In web.config, you will replace the first processor under the <renderField> node with the following:

<renderField>
        <processor type="Sitecore.Support.Pipelines.RenderField.SetParameters, SetParameters" />
         ...
</renderField>

This was tested on Sitecore v6.1, so please perform ample testing when working with other versions.

Default Web.config Sites Section

<sites>
   <site name="shell" ... />
    <site name="login" ... />
    <site name="testing"... />
    <site name="admin" ... />
    <site name="service" ... />
    <site name="modules_shell" ... />
    <site name="modules_website" ... />
    <site name="website" ... />
    <site name="scheduler" ... />
    <site name="system" ... />
    <site name="publisher" ... />
</sites>

Your new site entry will go above <site name=”website”>. I didn’t think the order mattered, but according to a Sitecore engineer who helped me debug my issues, it does. It’s a bug in v6.1, which may or may not have been fixed in newer versions.

The Modification – <sites>

<site name="website-uk" targetHostName="www.yoursite.co.uk" hostName="www.yoursite.co.uk" language="en-gb" ... />
      <site name="website" targetHostName="www.yoursite.com" hostName="www.yoursite.com" language="en" ... />

You should also clone the entry for cache sizes.

<cacheSizes>
      <sites>
        <website>
          <html>10MB</html>
          <registry>0</registry>
          <viewState>0</viewState>
          <xsl>5MB</xsl>
        </website>
        <website-uk>
          <html>10MB</html>
          <registry>0</registry>
          <viewState>0</viewState>
          <xsl>5MB</xsl>
        </website-uk>
      </sites>
    </cacheSizes>

The <linkManager> manager section also has some modifications. I have changed languageEmbedding to “never,” as it’s not necessary with multiple domains and is also better for SEO not to duplicate your content with multiple access via www.yourdomain.com/mypage.aspx and www.yourdomain.com/en/mypage.aspx going to the same place. I have also changed alwaysIncludeServerUrl to false, as it was causing some incorrect linking in some places.

<add name="sitecore" type="Sitecore.Links.LinkProvider, Sitecore.Kernel" addAspxExtension="true" alwaysIncludeServerUrl="false" encodeNames="true" languageEmbedding="never" languageLocation="filePath" shortenUrls="true" useDisplayName="false" />

Finally, I’ve had to set Rendering.SiteResolving to false as it was also causing issues with links on www.mysite.com showing up as www.mysite.co.uk

<setting name="Rendering.SiteResolving" value="false" />

That’s really it. It took many days and a lot of trial-and-error testing, but I’m happy to say my sites are up and working without a hitch. Hopefully, you will find this useful as well. But please remember – test everything.

If you have made any modifications to your Sitecore templates, chances are those modifications affected both languages.  Therefore, simply clicking “Publish Site” and copying the binaries and other files won’t really work.  It will, but deploying an enterprise-sized site blindly without a smoke-test for a public company and not running into any issues is about as probable as winning the lottery.  If you do not agree, see the definition of Murphy’s Law here.

Server Setup

This is the setup that is recommended by the engineers at Sitecore.  There are three identical web servers that are the delivery servers.  There are also four databases  - Core, Master, Web (staging preview), and LIVE which is the main production database server.

You will want a complete backup of the LIVE database as the initial step.  Don’t even open the web interface until you do that.

Web Server Preparation

If you have a load-balanced web server environment, you will want to take one server out of the load balancer pool.  This will be your smoke test box.  If you are deploying on a different domain (read my previous post on that strategy if you are unsure), you will need to modify your hosts file, usually located in c:\windows\system32\drivers\etc directory, to direct traffic to your site.  There is actually a benefit to doing this – testing out your SSL certificate to make sure you don’t get any certificate warnings.

If you do not have a load-balanced environment, you can simply clone the web directory and create an additional IIS site pointed there.

Database Preparation

By now, you should have already a complete backup of your live production data.  Note the path down somewhere and hopefully you won’t need to use it.  Next, create an additional complete backup of your database and restore it as a new database with a different name (e.g. Sitecore_LIVE_Temp).  This will be your temporary stand-by database that your live website will be running on, while you smoke-test your environment.

After you have verified that the database restored successfully, you can now go into your ConnectionStrings.config file and switch over the database in the “web” value to this new one you have just created.

Publishing

Now that you have set yourself up with a copy of the live site and the main database, which is going to be your live database after the testing concludes, you can go refill that cup of coffee, take a breather, and slowly begin the publishing process.  You could press “Publish Site,” but I prefer to publish section by section, just in case someone activated an unpublished item that should have stayed unpublished –  “Trust, but verify,” as Lenin used to say.   I do templates, layouts, media library, and then content, followed by copying over any binaries and other files to the web server.  In the web preparation section, you should have also already created a DNS record in the hosts file for your site – one for the main site, and if deploying to multiple domains, one for the new language.

Smoke-Test

By now, you have published all the languages, copied over the binaries and files which are now running on the LIVE database, and your hosts file has been modified.  At this point, start your testing.  Concentrate on user registration, if you have this component, which probably talks to a different, non-Sitecore database.  It also uses an SSL encryption, which lets you test your certificate situation.  Assuming you did your heavy-duty system, integration, and regression testing on your staging environment before you started this process, do a general walkthrough of the site, making sure all the content loads correctly.

Make The Switch

If all was good in the smoke-test, congratulations! You are pretty much in front of the finish line.  The final step is to copy the entire site you have been testing to your live web environment.  If you are deploying to a different domain, the other additional step will be to turn on the site in IIS, if applicable.

Since that site already has the correct database in its ConnectionStrings.config, your current production sites will automatically redirect traffic to them, as soon as they restart.  You can do a quick iisreset just in case, but the new overwritten assemblies in your bin folder should probably kick off an application restart.