Creating a GeoIP Lookup Provider for Sitecore using MaxMind’s GeoLiteCity Database

Sitecore ships with a built-in GeoIP lookup provider that is configured to use MaxMind’s lookup service. This service is provided for free with a “number of free lookups for testing and implementation convenience” (Engagement Analytics 6.6 Configuration Reference) This service works great, but what happens when your ‘number of free’ lookups expires?

GeoIP Options

When your free intro period expires, you essentially have two options if you want to continue to perform GeoIP lookups.

1. Migrate to the MaxMind-Sitecore integrated service. (http://www.maxmind.com/en/sitecore) 
2. Write your own, custom lookup provider.

While the MaxMind-Sitecore integrated service is amazingly simple to implement and run, I wanted to see what else could be used.  

The provider is essentially a ‘black box’ to Sitecore.  It doesn’t matter if it uses a web service, a local database or even a local file to return data lookups.  I decided to try to integrate with a local version of the GeoLiteCity database that is available for free download and use from MaxMind. (http://dev.maxmind.com/geoip/legacy/geolite/)

Creating a new Lookup Provider

Creating a new provider is as simple as creating a class that overrides the “GetInformationByIp” method.  

All we need to do is map the path to the database:

string geoLitePath = Settings.GetSetting(ModuleName + ".DatabaseLocation.GeoLiteCity", "~/app_data/GeoLiteCity.dat");

Pass the IP address to the look up service:

var lookUpService = new LookupService(HostingEnvironment.MapPath(geoLitePath), LookupService.GEOIP_STANDARD);

var location = lookUpService.getLocation(ip);

and populate the “WhoIsInformation” object so that Sitecore can use it:

WhoIsInformation information = new WhoIsInformation();
...
if (location != null)
{
    information.Country = location.countryCode ?? string.Empty;
    information.Region = location.regionName ?? string.Empty;
    ...
}

return information;

Update the Config

After you have created your new provider, update the “Sitecore/lookupManager/Providers” node in the web.config to include a reference to it.  It’s best to do this through a patch include file.

      
        geoLite
        
          />
        
      

And that’s it!  Sitecore makes it easy to change your GeoIP provider to anything else you may want to use. 

You can find complete source code and everything necessary to run this solution in the Sitecore Marketplace.

404 Error in ECM When Creating One Time Message

The Problem

Recently, while working on a Sitecore site with ECM 2.1, I ran into an issue in a single environment where I was receiving a 404 error when trying to create a new "One Time Message."

All other environments (DEV, STAGE) were working with no issues.  The page being requested, (/emailcampaign/create/ad hoc messages) was there, just like in the other environments.

The Solution

After troubleshooting for a while, the problem was found in a patch include file for the SitemapXML module.  This module was only being used in Production and that is why the other environments were working.  The module updates the "encodeNameReplacements" node to replace spaces with dashes in an attempt to help with SEO.  This was intercepting the URL request from ECM, modifying it and this prevented Sitecore from finding the requested URL.  To correct this, I simply commented-out the offending configuration:

    <!--<encodeNameReplacements>
      <replace mode="on" find=" " replaceWith="-" />
    </encodeNameReplacements>-->

Watch out, those include files, they will get you.  Use the "admin/showconfig.aspx" page to really be sure what is being included without you realizing it.

System.InvalidOperationException after deleting Sitecore administrator account

I was recently configuring multiple environments for a client and one of the things that I *always* do is remove the "admin" user and replace it with another account that has administrator privileges.  You should *always* change the default password for the admin account, but you might as well take it an additional step and change the administrator account name as well.  You don't want to be the one to have to answer to a client or your senior management as to why the default username and password were left in production.  Even better, follow the security hardening guide when your site goes live.


The process I was taking was:

1. Log into Sitecore using the "admin" account
2. Create a new administrator account
3. Log out
4. Log back in using the 'new' admin account
5. Delete the old "admin" account

I was bouncing between eight difference Sitecore instances and was essentially moving in 'auto-pilot' mode where I had already thought through what I was trying to accomplish and was quickly progressing through the tasks in the multiple environments.

During the course of removing the user on one of the instances, I ran into the following server error:

5924 10:19:59 ERROR Application error.

Exception: System.Web.HttpUnhandledException

Message: Exception of type 'System.Web.HttpUnhandledException' was thrown.

Source: System.Web

   at System.Web.UI.Page.HandleError(Exception e)

   at System.Web.UI.Page.ProcessRequestMain(Boolean includeStagesBeforeAsyncPoint, Boolean includeStagesAfterAsyncPoint)

   at System.Web.UI.Page.ProcessRequest(Boolean includeStagesBeforeAsyncPoint, Boolean includeStagesAfterAsyncPoint)

   at System.Web.UI.Page.ProcessRequest()

   at System.Web.UI.Page.ProcessRequest(HttpContext context)

   at System.Web.HttpApplication.CallHandlerExecutionStep.System.Web.HttpApplication.IExecutionStep.Execute()

   at System.Web.HttpApplication.ExecuteStep(IExecutionStep step, Boolean& completedSynchronously)



Nested Exception



Exception: System.InvalidOperationException

Message: membership user

Source: Sitecore.Kernel

   at Sitecore.Web.Authentication.TicketManager.Relogin(String ticketId, Boolean redirect)

   at Sitecore.DefaultPage.Page_Load(Object sender, EventArgs e)

   at System.Web.UI.Control.LoadRecursive()

   at System.Web.UI.Page.ProcessRequestMain(Boolean includeStagesBeforeAsyncPoint, Boolean includeStagesAfterAsyncPoint)

It took a bit of looking around to figure out what I did: I deleted the "admin" account when I was still logged-in using that account.  Oops.  Since I never logged-out, Sitecore was trying to use my authentication cookie and put me straight back into the Sitecore UI, but since I deleted the user, it threw the above error message instead and would not let me log in.

To convince Sitecore to allow me log in as another user, I cleared my cache and all was good in my Sitecore world again.

Sitecore: MVC Error when Running E-mail Campaign Manager 2.0

I was installing E-mail Campaign Manager 2.0 module (ECM) on a fresh install of Sitecore 6.6 (Update 4) the other day and ran into an issue.  The install process itself is easy: Install the SPEAK 1.0 package and then install the ECM 2.0 package.  Everything appeared to install smoothly.  When I logged into Sitecore and went to the ECM dashboard, I saw that it was actually throwing an error.

Note: The new SPEAK interface looks amazing and is *way* nicer than the ECM 1.3.3 version; Nice work, Sitecore!

If installing the ECM module on a remote computer that has the custom errors turned "On" or "RemoteOnly" in the web.config, you will just see that there is a runtime error:

If you update the web.config on the remote system to turn the custom errors “Off”, or you remote into the machine and browse to your Sitecore site and open up ECM, you will see the details of the error message:

So it appears as though the E-mail Campaign Manager module has an undocumented requirement to have ASP.NET MVC 2 installed on the server.

Go to http://www.microsoft.com/en-us/download/details.aspx?id=22079 and download the “AspNetMVC2_VS2008.exe” executable.  Run the exe on your Sitecore server and the ECM won’t complain any longer.

Alternatively, if you already have MVC 3 installed on your server, you can do a binding redirect to point any references to the 2.0 version to 3.0: https://gist.github.com/dunston/5213369

Happy email campaigning!

Configuration Settings for Developing a Multi-Site Sitecore Instance with Multiple Developers

Confused about which direction to go in with regards to your configuration files in Sitecore? It can be overwhelming to consider all the different options for configuring a solution for a new project. There are many different ways and you have to wade through the options to come up with the best approach.

Over my years of architecting and developing Sitecore websites, I've learned that you should always plan for the possibility of a single-site Sitecore instance to turn into multiple-site Sitecore instance. You should likewise consider the possibility that there will be multiple developers developing these multiple sites. It would be advisable to put in the time now to make sure you aren't accidentally overwriting code later when a looming deadline is approaching and everyone is under the gun.

Basic Solution Architecture

Let’s get a baseline for the types of Visual Studio projects that I have in a basic site Visual Studio solution. Each site is unique in its requirements and there are likely to be exceptions, but for a ‘normal’ site, I will have five basic projects in my solution as follows:

1. A Web project
• This project contains the presentation layer components that are used to build the Sitecore website. This includes Sitecore layouts, sublayouts and renderings. The project also contains my site’s CSS, Javascript and any static images not controlled by Sitecore.
  
  I’ll elaborate on the Web project configuration and the specifics of how to keep multiple sites from stepping on each other’s toes in a future post.
2. A Team Development for Sitecore (TDS) project
• This project contains the references that tie back to the Sitecore items for the website. This includes layouts, sublayouts, renderings, templates and sometimes content. TDS enables Sitecore items to be versioned in source control and can also automatically build and deploy Sitecore packages.
  
  Note: A TDS project can only be tied to a single database. If your project is tied to objects in the Master database and you additionally have changed made to the Core database that you would like to keep in source control, you will have to create a separate project for the Core objects.
  
  
3. A Library Project
• This project will store any common functionality that can be utilized in multiple locations across your solution. Common classes here include Utility and Settings classes. I also store the object glasses generated from the Custom Item Generator Module in this project.
  
  
4. A Configuration Files project
• This project contains configuration files that apply only to specific developers’ machines. These files are used for local builds and will not be included in packages that are used for integration testing in a shared development environment. The files included here might be “ConnectionStrings.config”, “DataFolder.config” a customized “Web.config” or “SiteDefinition.config.” Each developer will have his/her own directory structure in this project.
  
  
5. An Instance Configuration Files project (optional)
• This optional project contains the instance-wide configuration files for Sitecore and can be shared across ‘n’ number of site solutions. The only environment that will include its own folder structure here within this project is the shared development integration environment.
  
  I list this project as optional because there are times where you won’t want to have too many developers’ hands in the configuration files that affect an entire instance. I keep this project separate from my site project solutions in source control.
  
  Note: The files included in this project affect an entire instance. If changes are made to these files and committed to source control, they will be changed on the instance and they can potentially affect every site on the instance.
  
  

With this basic definition of projects for a Sitecore solution, let’s dive deeper into how we can manage the configuration files for multiple sites and multiple developers.

Configuration Files

Configuration files come in three flavors and can be located in three separate locations within your solution architecture:

1. Instance-wide configuration files

• Stored in the ‘Instance Configuration Files’ project. These files are common to all sites and can be changed by any developer with access. Changes affect all sites on the instance.
  
  
2. Project-specific configuration files

• Stored in the ‘Web’ project. These files are common to all developers of the site and can be changed by any developer for the site. Changes affect only the single site.
  
  
3. Developer-specific configuration files



• Stored in the ‘Configuration Files’ project. As long as the developer is changing the configuration files within his/her own directory structure, the changes made to these files only affects a single developer.
  
  

Solution Configuration

To maintain the configuration files and local builds, each developer should additionally have a solution configuration specified for that developer. This enables ‘Developer 1’ to maintain specific build settings in the solution file that builds and publishes the projects in a particular manner and those build settings can be completely different from ‘Developer n.’

Wrap it up

At first glance, it looks like there a lot of places to make configuration changes with this architecture and it can be difficult to know where to go to make the changes. In practice, it quickly becomes second-nature to know where to make your changes as 95% of those changes are going to be in the developer-specific configuration files contained within the ‘Configuration Files’ project.

Okay, so maybe there isn’t just one way to configure your Sitecore solution, but I believe this is a good approach that can scale nicely as additional sites and developers are thrown into the mix.

Regardless of the perceived complexity involved in this architecture, the benefits of being able to manage multiple sites and multiple developers without changing configuration settings each time the latest version is pulled down from source control is immeasurable.