Wasn’t entirely obvious how to go about this, but the scenario was that rich text content needed to be both expanded to convert links in the style ~/links.aspx?id=123456 into proper paths AND also include the server hostname rather than just root relative links.
UrlBuilderOptions urlOptions = new Sitecore.Links.UrlBuilders.DefaultItemUrlBuilderOptions();
urlOptions.AlwaysIncludeServerUrl = true;
var expander = new Sitecore.Links.ItemLinkExpander();
expander.Expand(ref richText, urlOptions);
Update Dec 2010: See this post for details of important changes since this post for first published.
Continue reading
While poking around in the shared source RSS module for Sitecore, I found that several aspects of the “static feeds” feature loose language context during publishing. This only effects static feeds whereby the rss.xml file(s) are written to disk and linked-too directly. The processes is kicked-off my hooking into the publishing-end event.
While the similar method Context.Database.GetItem retrieves an item in the same language as the context item, it appears that SelectItems(selector, predicate) does not. So if you are in a language other than ‘en’ English, you will probably retrieve the ‘en’ version of your non-‘en’ language items, resulting in large areas of missing data.
I’m not sure if this only effects SelectItems() when run outside of the context of a web request, or if it happens all the time, but the work-around is to explicitly change your context.language before calling SelectItems().
ContextItem.Database.SelectItems(selector, predicate); …..will return ‘en’ language items regardless.
Instead you must use:
Sitecore.Globalization.Language.Current = ContextItem.Language;
ContextItem.Database.SelectItems(selector, predicate);
….which then retrieves items in the same language of contextItem.