Join us this Friday for AI in Action at the Virtual Happy Hour! This free virtual event is open to all—enroll now on Academy and don’t miss out.

 

Linus Ekström
Feb 3, 2014
  19086
(9 votes)

The three rendering modes of EPiServer

When a template is rendered for a content item in EPiServer, items might be rendered a bit different depending of which “mode” the request is done for. The three modes are:

  1. Default (normal site visitor).
  2. Edit (On Page Editing).
  3. Preview (preview within the User Interface).

A common request from partners is to be able to determine if the current request is for an page that is done to enable on page editing. For this reason, the property EPiServer.Editor.PageEditing.PageIsInEditMode was introduced together with the all new On Page Editing in EPiServer 7. Though still property is still available and valid in EPiServer 7.5, it is now possible to determine the exact “mode” for the current request through EPiServer’s routing API and the property EPiServer.Web.Routing.Segments.RequestSegmentContext.CurrentContextMode which returns an instance of the enum EPiServer.Web.ContextMode.

Let’s determine the results for these methods/properties in the different modes with a simple template for the start page of the site:

URL for current content: <strong><%=EPiServer.Web.Routing.UrlResolver.Current.GetUrl(CurrentPage.ContentLink) %></strong><br />
PageEditing.PageIsInEditMode: <strong><%= EPiServer.Editor.PageEditing.PageIsInEditMode %></strong><br />
RequestSegmentContext.CurrentContextMode: <strong><%= EPiServer.Web.Routing.Segments.RequestSegmentContext.CurrentContextMode %></strong>

 

Site view

Default

Editorial view

Edit

Preview in UI

Preview

Getting a URL for a specific mode

As some people have mentioned in the forums, getting a URL for an item will produce different formats when viewing an item on the site and when editing it (as can be viewed in the images above). If you want to always create a URL for a given mode regardless of the current request, this can be done by calling an overload of the GetUrl-method of the UrlResolver:

string language = null;
var iLocalizable = CurrentPage as ILocalizable;
if (iLocalizable != null && iLocalizable.Language != null)
{
    language = iLocalizable.Language.Name;
}
 
var deterministicUrl = UrlResolver.Current.GetUrl(CurrentPage.ContentLink, language, new VirtualPathArguments() { ContextMode = ContextMode.Default });
Feb 03, 2014

Comments

Feb 5, 2014 06:41 PM

Good stuff!

Gayathri Saravanan
Gayathri Saravanan Mar 12, 2014 10:57 PM

Nice :)

Andrew Sanin
Andrew Sanin Jan 14, 2015 11:18 AM

Very helpful!

Please login to comment.
Latest blogs
Best Bets, synonyms and wildcard queries

When using a wildcard in your search query like ‘search.For(query+”*”)’ or when you used the reversed method suggested in the Breaking changes...

Jeroen Stemerdink | Jan 28, 2025 | Syndicated blog

Content statistics Blazor component

Another week and another MudBlazor component to explore. I wanted to test the charts components so I created a small Blazor component that displays...

Per Nergård (MVP) | Jan 28, 2025

Referencing Page Specific Blocks with ISelectionFactory

A content modeling exercise got me thinking about reuse of page-specific content. It turns out that Optimizely has some good tools to handle this...

Nicholas Sideras | Jan 28, 2025 | Syndicated blog

Further Enhancing Production Database Scalability in DXP Cloud Services

About a year ago we announced that we are improving the scalability of SQL databases in DXP Cloud Services , focusing first on non-production...

Anna Pleshakova | Jan 27, 2025