Jeremy Davis
Sitecore, C# and web development
I was going to stop at three posts on simple patterns for navigation (Parts one,two and three are here) – but earlier this week I realised I'd not covered an important topic in navigation for Sitecore-based websites: How you can navigate between different language versions of your sites and pages. So this week, I'll start looking at language navigation.
There are two common patterns for how you might structure your content in Sitecore if you have a multi-lingual site. Depending on what sort of content you're dealing with, you might choose to:
(Technically, there's also a third option, where you have multiple content trees which may also have multiple languages – but that's just a combination of the two ideas I'll present)
The core navigation controls for these sites work in exactly the same way as the ideas I've presented in previous posts. But if you have multiple languages, then you need some code to display links to let the users swap between languages. And you need slightly different code for these two scenarios. So this week I'll look at the first of these:
I'm very pleased to be able to announce that Sitecore have invited me to be part of their MVP community for 2015.
Continuing the theme of simple approaches to navigation components, this week I want to look at a slightly more complex scenario for the top level navigation in a site. Sometimes you need the mark-up for primary navigation to vary between different items in your navigation. Perhaps you have some pages which need a different style of display because of their purpose on the site. And generally in this sort of scenario you need editors to have some control over which items get these different views.
My son loves the Lego-branded games available via Steam. He's a massive fan of the Lego versions of Batman, Marvel and the recent Lego Movie game. But as much as he loves them, as the owner of the computer he plays on, I've found them frustrating. You buy a game, download it, and it works fine for a while. But at some point all of these games have suffered from a problem where you stop being able to launch them. Having had to figure out solutions via Google to keep my son happy, I'm writing this down so I can remember it next time...
A quick distraction from navigation patterns this week:
A while back I wrote a bit about issues with following the SDN instructions to create a new custom application on your Sitecore "start menu". Recently I responded to a Stack Overflow question about this issue, where after a bit of discussion I discovered that this didn't work quite the same way on Sitecore 7.5. So having investigated why, I figured I should write this up...
Last week I started looking at some simple ideas for the top level navigation for Sitecore websites. This week, I'll continue that theme with some simple examples of the more localised navigation that you might use on content pages.
Most websites need some sort of navigation UI. If you have a site with more than a handful of pages then you're likely to need to create some components for rendering sets of links that show the structure of your site. So continuing my theme of simple patterns for Sitecore code, here is the first of a few posts on some approaches to navigation.
Ok, so it's technically Christmas and I should really be eating too many mince pies and watching repeats of early 80s sitcoms instead of blogging. But somehow I can't stop technology catching my eye.
It's not an uncommon requirement to have a control on your website which displays its data with varying styles in different locations in the site. Here are a few simple patterns for how you can create Sitecore UI components which can have their display style changed by location.
Quite often when you're putting together a website, you find yourself needing to link the current page to some sort of shared page for an action. "Click here to read terms and conditions" is a common example – where all your products need to be able to link to the Ts & Cs page.
A naive implementation might just hard code the path here, but that is inherently fragile. Renaming or moving the page can easily break your code. So what better approaches might you consider for meeting your requirement while allowing editors flexibility? Having talked about these patterns with colleagues a few times recently, I thought I'd write down some of the basics as a reference for future conversations.
