I have a scheduled job traversing all pages of our site to modify some information. It's working fine except for one thing.
My request returns only french pages.
How to get the english pages as well?
IContentRepository _repLoad = ServiceLocator.Current.GetInstance();
IEnumerable children = _repLoad.GetChildren(PageReference.RootPage);
You'll need to work with the language branches of each child page.
Something like this:
var children = _repLoad.GetChildren<BasePageData>(PageReference.RootPage);
foreach (var child in children)
var languageBranches = _repLoad.GetLanguageBranches<BasePageData>(child.ContentLink);
foreach (var languageBranch in languageBranches)
// Do your stuff on each languageBranch. (languagebranches includes the french version).
// Don't forget to create writeable clones of the ones you need to modify.
IContentRepository (or rather, IContentLoader) .GetChildren has another overload which takes CultureInfo, so you can do
var culture = CultureInfo.GetCultureInfo("en");
var children = contentLoader.GetChildren(parentLink, culture);
Jafet Your answer is working but I have one more problem.
I need to obtain a link to the page.
I'm using the following property. page is a BasePageData.
I don't get a seperate link for French and a link for English. It's always redirecting me to the French page. Also page.Language.DisplayName has a value French and an empty value. Should I assume that the empty value is English?
you can use `UrlResolver.GetUrl(page.ContentLink, culture);` to get the link to language branch page.
There is no way to load a content in all languages in one go. So your best bet is two have several iterations to call GetChildren on each language.
UrlResolver is an abstract class and GetUrl isn't a static method. How can I call it?
You are best off using dependency injection to get the UrlResolver, something like you see here.
If you must, you can use the ServiceLocator (but be aware that it's an anti-pattern), which would look like this:
var urlResolver = ServiceLocator.Current.GetInstance<UrlResolver>();
var url = urlResolver.GetUrl(contentLink);
There is also the option to do:
var url = UrlResolver.Current.GetUrl(contentLink);
If possible, the first option is preferred.
@Jake, SL is anti-pattern. try to avoid it.
@Martin, if your code is happening at Mvc controller (for example), demand "UrlResolver" within your controller constructor (it's called constructor injection):
public class MyController : Controller
private readonly IUrlResolver _resovler;
public MyController(IUrlResolver resolver)
_resolver = resolver;
public ActionResult Index()
Also note, that I'm using interface instead of contrete type.
@Valdis: That's why I explicitly mentioned that the ServiceLocator is an anti-pattern and linked out to an example of constructor injection—stating it was the preferred choice 😉
It's used in a ScheduleJobBase class. How can I do constructor injection in that case? Also, why it's an anti-pattern to use the service locator diretcly?
@Martin: There is a good overview here.
Actually, and somewhat unfortunately, scheduled jobs are one of the relatively few places you have to use the service locator (or Injected<T>). As Valdis also noted, its better to use the interface (which I didn't do in my earlier example).
http://blog.ploeh.dk/2010/02/03/ServiceLocatorisanAnti-Pattern/ from the guy usually considered "DI master"
For MVC you might need to set the resolver https://world.episerver.com/documentation/Items/Developers-Guide/Episerver-CMS/9/Initialization/dependency-injection/
Jobs support dependency injection via constructor.