Amy's Sitecore Adventures!

Eventually a component on a page is going to need to pull in some new information and you don't always want to reload the whole page. Making use of Ajax allows you to avoid a full reload but when you use Ajax with Sitecore there are a few important things to keep in mind: Make sure you set up your controller to function with the Ajax call.  Are you sending back some data, the whole rendering, or are you just updating something internally? Be ready to handle whatever is coming into or out of the controller. Note that if the Ajax function is posting data you must add [HttpPost] before the controller method. Regardless of how you get to your controller - there won’t be Sitecore context! Your controller has no idea what the user was doing or where they were on your site when the Ajax call was made. You need to pass all the information in your model to the controller including the data item and anything else relevant for your controller to give context. One way to give context is

Developers often push aside the rich text editor because we would rather of use separate components with data sources. However, sometimes we need to rely on the rich text editor to empower the content editor to edit more directly or to reduce complexity on the page. We can use snippets to reduce complexity or give the editor more options by inserting some predefined HTML into the rich text editor. In this example, we will learn how to get more out of the rich text editor by changing which editor we use, adding new snippets, and styling the added content. First we need to switch from the default basic rich text editor to either one of the other existing editors or to a custom editor. The Rich Text Default view - just the basics: We can change the default editor on a field-by-field basis. Update the Source Property for the Rich Text field so that it references the specific rich text editor we want to use in the core database: On your template, enter the item path for the

Sometimes bad data can sneak into the smallest of things and wreak havoc on a site bringing up a dreaded error page (hopefully captured and prettified). We’re going to cover two examples of sneaky bad data blowing up a component and how we can address the problem. The scenario here revolves around an invalid datasource and a component making use of Glass - this bad data can come about from a publishing issue (such as publishing the page which references a datasource that hasn’t been published or wasn’t in the final workflow step to allow publishing), or some other kind of issue (an invalid item ID, a deleted item still being referenced etc). 1. Getting the Item In the code for our rendering, we want to grab that datasource item to help out our model, so we did the following: This confirms that the Guid is a valid format - but doesn’t confirm that it’s a valid item in the database before we pass it to GetItem to grab and cast to our Item_Type. It wouldn't be unreasonable to

For each of the properties in your template you can set a source for it, this isn’t always used but can improve user experience drastically when done throughout a site. The source field comes in to play whenever you are using any of the following fields: Droplink, Droplist, Droptree, File, Grouped Droplink, Grouped Droplist, Image, Multilist, Treelist, Rich text field and a number of others. There are various ways of setting these up to achieve different results – but in general you are using the source to limit the set of items that can be used, and this requirement can also help you determine what kind of field to use. For example, if you have a Set of items all split down into sub folders and want the content editor to make use of the tree, you could use a TreeList or Drop Tree, but if you just want a set of items without the opportunity to see where those items are – multilists or droplinks are the way to go. For Images you’re generally just specifying where to look for and put th

Breadcrumbs have been covered by just about everyone so there are lots of examples that all seem to do things a Little differently. With that in mind I’m going to keep this short with my example and two other examples I’ve found that might also meet your needs and cover the basics for just about every xslt breadcrumb example you’ll find. The general idea: you’re at item c, in your tree the path is something like:  /sitecore/content/a/b/c and you want to display a pretty html list for a » b » c anywhere on your site.  You’ll always be dealing with the ancestors of your current item so you’ll be making use of $sc_currentitem/ancestor-or-self::… somewhere. You’ll need to go through each ancestor item and display it, probably checking to see if you’re at the last item so you don’t display a ‘»’ after the final item. You also need to make sure to not display unwanted ancestors in your breadcrumb, being /sitecore and /content in our case. So onto the examples! First is the Sitecore bread

Previously I had posted on how to set up items in your content tree to act as external links to other pages (for use with Navigation mainly – for example if you have a blog elsewhere but still want it listed in the main navigation). However, Ivan Buzyka pointed out some issues with the simple implementation so I added creating a better redirect to my ‘to do’ list for the blog. The time has come! Let’s pretend we are modifying an existing site, we don’t want to change the navigation so that won’t be covered here – we just want to update our layout to work a little more universally. Our new items need to be able to link to an internal, external or Media item reliably for display in our navigation. Our template will consist of similar things to last time: Link: General Link Nav Title: Text -> standard values: $name In Navigation: Checkbox ->standard values: checked Create the template, add in standard values for it with the above settings and now we can create our Layout which shou