Recently, I had the pleasure of being involved in the launch of a Sitecore 7.5 site for one of Delphic Digital’s clients. From that launch, I gathered a few tips that can be helpful for other sites going to launch on Sitecore 7.5. I don’t think any of the below warrants their own blog posts, but I also think they’re all important enough not to be missed. So, even though they’re not necessarily related in any manner, I’m going to throw them all into this post with the hopes that it will help to save people time in the future.
Aliases for Multisite
The site that we launched on Sitecore 7.5 is a multi-site implementation, meaning that we broke the Content Tree into more than one logical “site”, each with its own set of Page Items. We needed to have a few Alias (Vanity) URL’s created for some of our pages, largely to allow legacy URL’s to resolve to the new destination properly. We initially had some trouble with our Aliases not saving, as the Page Items we were trying to add them to didn’t exist under the Sitecore out-of-the-box “Home” item. In my research, I discovered that the Alias template (/Sitecore/templates/System/Alias) sets its “Linked Item” field source property to the default Sitecore OOTB Item. This means that if you go to an actual Alias item (found under /Sitecore/system/Aliases) and try to link an item to your Alias, you’ll only see items that exist under the default Home. In multi-site implementations, this is most likely going to exclude a fair amount of your Page Items from being able to be selected. My fix for this was to adjust the Source property of the Linked Item field to point to “/Sitecore/content” instead. After that, my entire Content Tree was available for choosing.
One other note about Aliases – Sitecore restricts them to being unique, and only allows an Alias to point to one page item at a time. If you think about what Aliases are doing, this makes perfect sense, unless you want to try and tokenize your Alias. For example, if you have mini-sites within your content tree that all require an Alias that follows a standard format, you’d be able to save lots of time by setting up a tokenized Alias once and having it apply to all of your mini-sites. Unfortunately, this doesn’t work out-of-the-box. I think it’s a great idea for a future module, and one that I’ll consider making if no one else beats me to it. (If you happen to want this functionality and have the time to develop the module yourself, please do!)
The Awesomeness of Branch Templates (& the parts that can suck too…)
Branch Templates have been around in Sitecore for years now, and they definitely have their advantages. For those unaware, the concept of a Branch Template allows for multiple items to be created at once by a Content Author performing a single action. Depending on the situation, Branch Templates can be a huge timesaver for Content Authors, as they create new content. Our site used a Branch Template to allow creation for mini-sites within our overall website structure. Our Branch Templates were loaded up with some default content to reduce the amount of work that a Content Author needs to handle when launching a new mini-site. They actually work great – our Authors are able to spin up mini-sites that have 12 pages of content by simply creating one item, and editing anywhere between 1-3 fields. Without branch templates, the same actions would take the creation of at least 12 items, not to mention filling out fields on each one. Unfortunately, we didn’t realize we had missed some common content that needed to happen on our Branches until after we had already created 200+ mini-sites. This meant that we now had to make our changes in 200+ spots to retrofit, as Branch Templates don’t inherit values from Standard Values the same way that normal Templates do. This task proved to be a chore, so what I found as the best method to quickly fix anything that came up was Sitecore Rocks, a free Visual Studio plugin. With Sitecore Rocks, I could query all the items that I needed to change, and then have a query that updated just those items. This took a task that was very mind-numbing and time consuming, and let me complete it in a matter of minutes. Personally, I don’t use Sitecore Rocks all that much in my day-to-day development, but that’s always been because habits are hard to break, and I initially learned Sitecore without the benefits of Rocks. Even though I’m probably never going to get away from doing my day-to-day work in Sitecore itself, the ability to query multiple Items and make mass changes to them at once makes Sitecore Rocks a must-have for Sitecore developers.
Using SwitchMasterToWeb with Sitecore 7.5
I set up the SwitchMasterToWeb.config file on the Production Environment of our implementation so that I could remove the Master DB completely from that environment, which I consider to be a best practice. I also consider checking the production Sitecore logs after going live to be a best practice, because there can be events logged that are issues even though the website appears to be healthy from a consumer point-of-view. I happened to run into a few of these issues, and it was because there are some configuration files that weren’t patched by SwitchMasterToWeb. In Sitecore.Analytics.Reporting.config, there are two instances of master nodes. These should be switched to have the value “web” instead of master on any environments using SwitchMasterToWeb. The Sitecore.ContentSearch.config also has a node with type “Sitecore.ContentSearch.Tasks.Optimize”. Inside of that node is an
I hope that the above tips help anyone who is launching on Sitecore 7.5 to have a smooth process! If you know of any other 7.5 Launch Tips i’ve missed, please add a comment for the community below.