It happens all the time, someone deleted an item by mistake. Whether it’s your content author, your customer, or yourself, you’ll need to undelete or recover a deleted item. Here’s how it’s done. If you’re a Sitecore 6 or 7 user, scroll down to that section.

Sitecore 8

Sitecore 8’s Launchpad provides a new way to access the Recycle Bin. From the launchpad just click the Recycle Bin app to access it.


If instead you’re already in the Desktop mode or are used to that, hit the Sitecore menu and click the Recycle Bin app from the right hand side.


Once you’ve launched the Sitecore Recycle Bin, navigate to your item, select it, and choose “Restore” from the top.


Still on Sitecore 6 or 7?

When logging in select the Desktop view.


From the Sitecore menu select the recycle bin from the right side.


Navigate to the item you wish to recover, select it, and hit “Recover” at the top of the app. Your item is now recovered.


Sitecore provides all the tools necessary to easily personalize based on GeoLocation using their partner MaxMind’s webservices. Not only can content authors easily set up personalization based on available GeoLocation data using the rules engine, the development team will be able to leverage the same data in any custom business logic. That being said, content authors, testers and developers need to be able to verify their work for different IP addresses and locations. This approach does not require special .Net code, custom pipeline processors or anything else that could complicate your solution.

Configuration Change

Change the “Analytics.ForwardedRequestHttpHeader” value to “X-Forwarded-For” and you’re all set. This will tell Sitecore to look at that header for IP address information instead of the IP that made the request.

      Specifies the name of an HTTP header variable containing the IP address of the webclient.
      For use only behind load-balancers that mask web client IP addresses from webservers.
      IMPORTANT: If used improperly, this setting allows IP address spoofing.
      Typical values are "X-Forwarded-For" and "X-Real-IP".
      Default value: "" (disabled)
<setting name="Analytics.ForwardedRequestHttpHeader" value="X-Forwarded-For" />

Setting your header

To make this easy I use the “Change HTTP Request Header” plugin for Chrome. Setting this up is pretty easy after you have it installed. First add a new header for “X-Forwarded-For”, then add any presets that line up with your test cases – see the screen shots below. Once everything is setup you hit the handy dropdown in the plugin to select a preset or to input one on the fly.

Download the Change HTTP Request Header at the Chrome Store

So, that’s it! Have fun testing your GeoLocation aware apps in Sitecore.

It’s funny how almost all the controls we end up building are a list of something. In Sitecore that means lists of Items! If you are doing WebForms you have become familiar with the <asp:Repeater /> control, and might have some solutions for binding FieldRenderer or <sc:Text /> controls. I’ve found that a custom Repeater control that binds child FieldControls (sc:Text, sc:Image, sc:Date, etc.) automatically has reduced my code and time spent slogging through all the controls necessary to build out a site.

Take for example the following usage assuming an IEnumerable<Item> or IQueryable<Item> was bound to the Repeater

<asp:Repeater runat="server" id="myRepeater">
        <h3><sc:Text runat="server" field="Title" Item="<%# (Sitecore.Data.Items.Item)Container.DataItem %>" /></h3>
        <div class="item-content">
            <sc:Text runat="server" field="Description" Item="<%# (Sitecore.Data.Items.Item)Container.DataItem %>" />

That is a simple example of how I often see FieldControls binded. An even more extreme case would be to not use FieldControls at all, to set the content for the HtmlGenericControls in the ItemDataBound event.

When it’s time to output my data I don’t want anything getting in my way, so I chose the following approach: Set up a simple ItemRepeater class that extends Repeater and autobinds child FieldControls without an Item set for you. Check out the example usage:

<custom:ItemRepeater runat="server" id="myRepeater">
        <h3><sc:Text runat="server" field="Title" /></h3>
        <div class="item-content">
            <sc:Text runat="server" field="Description" />

Just set the DataSource and you’re done, that’s how I like it. Check out the class below that takes care of the lifting.

Recently there was a question on StackOverflow asking about improving the performance of their Sitecore implementation.

Here are some things you can consider without changing overall architecture of your deployment

CDN to offload media and static asset requests

This leaves your content delivery server available to handle important content queries and display logic.


Configure and use Sitecore’s built-in caching

This is from the guide:

Investigation and configuration of the Sitecore Caches is broken down into multiple tasks. This way each task is more focused and simplified. The focus is on configuration and tuning of the Sitecore Database Caches (prefetch, data, and item caches.)

For configuration of the output rendering caching properties, the customer should be made aware of both the Sitecore Cache Configuration Reference and the Sitecore Presentation Component Reference as to how properly enable and the properties to expire these caches.

Check out the Sitecore Tuning Guide

Find Slow Queries or Controls

It sounds like your application follows Sitecore best practices, but I leave this note in for anyone that might find this answer. Use Sitecore’s built-in Debug mode to identify the slowest running controls and sublayouts. Additionally, if you have Analytics set up there is a “Slow Pages” report that might give you some information on where your application is slowing down.

Those things being said, if you’re prepared to provision additional servers and set up a load-balanced environment then read on.

  1. Separate Content Delivery and Content Management
    To me the first logical step before load-balancing content delivery servers is to separate the content management from the equation. This is pretty easy and the Scaling Guide walks you through getting the HistoryEngine set up to keep those Lucene indexes up to date.
  2. Set up Load Balancer with 2 or more Content Delivery servers
    Once you’ve done the first step this can be as easy as cloning your content delivery server and adding it to your load balancer “pool”. There are a couple of things to consider here like: Does your web application allow users to log in? So you’ll need to worry about sticky sessions or machine keys. Does your web application use file media instead of blob media? I haven’t had to deal with this, but I understand that’s another consideration.
  3. Scale your SQL solution
    I’ve seen applications with up to four load balanced content delivery servers and the SQL Server did not have a problem – I think this will be unique to each case depending on a lot of factors: horsepower and tuning of SQL Server, content model of your application, complexity of your queries, caching configuration on content delivery servers, etc. Again, the Scaling Guide covers SQL Mirroring and Failover, so that is going to be your first stop on getting that going.

These options are really just the starting point for getting this set up. There are a number of great resources out there, check out John West’s blog posts on this topic and you’ll find a wealth of information.

Sometimes we don’t have the password to the sitecore\admin account and need to get in. You can reset the admin password to the default just don’t forget the change it afterwards to something secure. Since I had to do this again today and Emile had the excellent idea of putting it somewhere I wouldn’t forget I decided to post it here. Just change “Sitecore_core” to the name of your Core database. Oh yeah, and don’t forget to back up the database first otherwise you will be thrown into the abyss.