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.
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.
<!-- ANALYTICS FORWARDED REQUEST HTTP HEADER 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)--><settingname="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.
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
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:
I saw a post yesterday by Paul Irish, showing the classy 3D transformations Amazon is doing on some pages. I’ve been playing with some retro game collecting application ideas and was thinking that the effect would be cool for a collection page, so I set up a prototype.
My site uses the Leviathan theme and I wanted to make it responsive. Why? Because the text is too damn small to read on my phone!
The problem with approaching a regular design and trying to make it responsive is that you spend your time squeezing stuff, or trying to take non-essential things away. Luckily for the sake of a simple blog there are basically two columns – one with high-priority primary content and a second or more of lower-priority secondary content.
My approach in this case was to leave the full width desktop version alone. Then between the outermost and second-most outer breakpoints allow the columns to scale percentage-wise. This will squeeze the columns proportionally until I have decided it’s not reasonable to show two squeezed columns side-by-side at which point the secondary-content is pushed below and both columns become full-width. At an even more narrow breakpoint I hide things from the secondary column that were pointless in that view.
This seemed to work well, however there are a few gotchas to remember.
Images – when these are output they normally have a static width and height on them, those should be removed with a max-width applied to images so that they scale with their respective column
Rich Content (Videos/Embeds) – These also have a static width and height. I tried scaling them in CSS with mixed results. If you have rich content you need a better plan, luckily I don’t care that much if it’s janky on small screens so long as the majority of content is fine.
Header height – The header of your site and the margins between the elements can cause visitors to scroll a lot when on smaller screens, adjust accordingly.
Hover – You can’t hover on a touch screen! We have gotten used to doing things on hover, but to support touch screens we need to break that thinking
If you want to do responsive you should plan for it from the beginning with the most essential items available in the smallest layouts, design interactions without hover, etc. For a simple blog like this one it only took 4-6 hours to get it acceptably responsive… but for a major business or association with a complex homepage responsive might not even be the right approach. I still have more to think about as I haven’t done this a whole lot, but for now I’ll leave you with the CSS additions I made to make the Hybrid Leviathan theme responsive.
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.
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.
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.
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.
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.