I recently dealt with a requirement from a client who wanted to start over with their translation effort which had occurred at different rates across large areas of their site. They wanted just the English language version to be served. There are many possible solutions to this – such as putting in top-level redirects for all language variants through IIS  – however the editors wanted to retain the control of when they could re-enable a language for a particular page.

This meant removing all of their existing fallback and replacement languages settings for each and every page and then ensure that English was served as a replacement language for every page on every language variant*

* Obviously there are SEO impacts of serving identical contents on different urls, our solution also included a technical piece that handled this – perhaps I’ll share that next time if anybody is interested.

Under the hood

EPiServer stores language replacement and fallback in the sql server table tblPageLanguageSetting

If no data is found for a page – then the EPiServer code assumes that the fallback/replacement language data is inherited from a parent page. This behaviour is chained all the way up the tree to the site’s start page.

If you add data through the UI then EPiServer will add an entry to the table for each enabled language branch (in the above image I have three site languages enabled). When it does this it adds a null entry for each enabled language that doesn’t have a fallback or replacement language defined.  The presence of this entry is enough for EPiServer to know that the language data isn’t inherited.

So achieving our requirement is actually pretty straightforward. Ensure that the language settings are correct on the homepage and then remove all entries in this table apart from entries with fkPageID equal to the start page ID. (Note this wasn’t an enterprise scenario – you may have to be a little more granular with what you delete in that instance)

Obviously running direct SQL against the EPiServer schema isn’t recommended (or supported by EPiServer) – so BE CAREFUL – with great power comes great responsibility. However this is a huge time-saver over using the UI to achieve the same result.

With the current popularity of the App Store (over 25 billion downloads) it might not seem like it. However the phenomenal success of the native app market presents a number of problems for both users and publishers alike.

The App Store is noisy

There are now over 500,000 apps available on the App Store meaning that finding the latest and greatest is difficult. This can lead to a unhealthy reliance on curated lists and editorially featured content as a means to reliably discover new apps.

As a publisher, this increases the risk that your beautifully created app can sink without trace, no matter how great it really is. This increased competition in the market place also brings out the more nefarious means of grabbing attention. Those user reviews and 5-star ratings are worth real money!

Mobile home screens are overcrowded

Once you’ve found and downloaded the app you want, it has to compete with all of the other apps you’ve downloaded for prime real estate on your device’s home screen. The desktop paradigm that most devices have adopted just doesn’t scale to hundreds of apps. The cost of having to organise, rearrange, update and de-clutter your home screen becomes significant compared to the individual value offered by many of the apps.

Developing for multiple platforms is expensive

Which platforms should you launch your app on? How many versions built on different platforms can your development teams support? Should you try and develop features in parallel across platforms or should you let your feature set diverge and add new features to one platform first? All difficult decisions. It’s pretty clear why there is an imperative to develop with cross-platform mobile frameworks.

Is HTML5 the answer?

No, not in isolation. HTML5 is often misunderstood. It provides an open standards way of marking up data for display as  user interfaces, content and rich media. So the real question is will web apps using HTML5 become the dominant way of delivering mobile functionality? The answer as always lies in the context. If you need to interact with the device hardware then a native app is still the best way to achieve this. If you need to present content, text, images and media then HTML5 and a web app allows you to do this in a cost effective and time-tested way.

There is a third way. Many publishers are now pushing a hybrid approach and realising significant cost savings across mobile channels by building native apps which use HTML5 to deliver user interfaces that are imperceivably different to those offered by native code. Take for example, the latest LinkedIn IPad app which to many commentator’s surprise delivers 95% of it’s views using HTML5 (and of course a hefty dose of JavaScript and server-side data services).

Apps-on-demand

Native apps won’t disappear but clearly there is convergence between the experiences native apps can deliver and those available via a browser.

Perhaps though it’s the app delivery mechanism that will change most of all. Rather than investing time up-front collecting apps from a store (with a vastly improved app discovery mechanism), perhaps apps will be downloaded only if and when you need them. This is the exact model suggested by ex-Apple and Google mobile UX guru Scott Jenson who suggests that future apps will be delivered ‘just-in-time’, installing only the features you need there and then. The underlying technology for such delivery is already available. It’s the web!

Here for the long run

Ultimately, reports on the death of native mobile apps have been greatly exaggerated, but HTML5 shows every sign of becoming the dominant cross-platform technology for serving rich interfaces, media and content.

Every future device of note will have a standards compliant browser, meaning that every device will be capable of consuming content and services delivered in HTML. As a publisher or developer it would be foolish to ignore this. As a user, hopefully you won’t even notice the difference…..

This isn’t mine – in fact I don’t know who the credit should go to. However, it was so great I wanted to put it somewhere relevant where I could see it often.

UPDATE (16th May 2012): It originally came Manu Cornet at Bonkers World. Awesome stuff

Technically – this is a straightforward implementation of a Visitor Group criteria, using some of the native Personalization API to record when the user starts their session. This is then compared to the current DateTime along with the editor selected time period to calculate a match.

The TimeOnSiteCriterion is available as part of Criteria Pack version 1.3, which is available on Codeplex (along with the source code) and of course there is an individual Nuget package on Nuget.episerver.com

An Extended example

One of the clients I’m working with at the minute had a requirement to display a modal pop-up on their site to user’s who had either visited a set number of pages, or had visited for more than a defined duration. Using the Visitor Group functionality sounded like a good match as it allows the editor’s to specify the exact criteria and mix and match with other matching criteria moving forwards.

The TimeOnSite criterion obviously forms part of this requirement, but fully meeting the requirement involves not waiting for a user to request a new page from your site and instead delegating responsibility to the browser to continue the countdown and respond (display the popup) when the criteria is matched. This is a requirement that the Visitor Group API doesn’t handle completely, as a Visitor Group is resolved as either a match or not a match when the page is delivered to the browser. There is no straightforward way of working out how ‘much’ of a match the current request may be.

Never the less, we still have the flexibility to achieve this:

1. We need to link the site to a specific Visitor Group that will provide our criteria for when to display the popup (using a custom property like this will do the job – possibly on a site wide settings page)
2. We need a method of working out how close we are to a match being made – in this case how many seconds are left. This data needs to be delivered to the browser.
3. We need some client side script that will continue the countdown and trigger the popup when the countdown reaches zero.

The following public class is a part of the TimeOnSiteCriterion assembly, and contains the SecondsToMatch method to which can be used to work out how many seconds remain. The method will search a single Visitor Group – which is instantiated by Id (which is why we need a custom property to store this information), to find the first instance of a TimeOnSite model. This model contains the editor selected TimeOnSite criterion – which is then used with the user’s session start variable to calculate how long remains.

using System;
using System.Linq;
using System.Web;
using EPiServer.Personalization.VisitorGroups;

namespace CriteriaPack.TimeOnSiteCriterion
{
    public class TimeOnSiteService
    {
        public TimeOnSiteService()
        {
            Store = new VisitorGroupStore();
        }

        public TimeOnSiteService(IVisitorGroupRepository store)
        {
            Store = store;
        }

        public IVisitorGroupRepository Store { get; set; }

        private double CurrentValueInSeconds(Guid visitorGroupId)
        {
            //load visitor group by providing id
            var group = Store.Load(visitorGroupId);
            if (group == null)
                return 0;

            //return first instance of TimeOnSite Criterion
            var timeOnSiteCriteria = group.Criteria.FirstOrDefault(a => a.TypeName == VisitorGroupCriterionRepository.GetTypeName(typeof(TimeOnSiteCriterion)));
            if (timeOnSiteCriteria == null)
                return 0;

            var model = timeOnSiteCriteria.Model as TimeOnSiteModel;
            if (model == null)
                return 0;

            if (model.DurationUnit == DurationUnit.Minutes)
                return model.TimeOnSite * 60;

            if (model.DurationUnit == DurationUnit.Hours)
                return model.TimeOnSite * 60 * 60;

            return model.TimeOnSite;
        }

        private DateTime SessionStart(HttpContextBase httpContext)
        {
            return Convert.ToDateTime(httpContext.Session[TimeOnSiteCriterion.SessionStartTimeKey]);
        }

        /// <summary>
        /// Returns the number of seconds remaining until a match.
        /// </summary>
        /// <param name="httpContext">The HTTP context.</param>
        /// <param name="visitorGroupId">The visitor group id.</param>
        /// <returns></returns>
        public double SecondsToMatch(HttpContextBase httpContext, Guid visitorGroupId)
        {
            var matchTime = SessionStart(httpContext);
            matchTime = matchTime.AddSeconds(CurrentValueInSeconds(visitorGroupId));

            double timeToMatch = (matchTime - DateTime.Now).TotalSeconds;
            return timeToMatch < 0
                ? 0
                : timeToMatch;
        }
    }
}

The final part is to use this in a page:

   protected void Page_Load(object sender, EventArgs e)
   {
      var service = new TimeOnSiteService();

      //retrieve this from a page / sitewide property - allowing match from the page to the time tracking visitor group
      var visitorGroupId = new Guid("4c3bb8b2-4e8e-4fbc-bc24-5018e8c935af");

      //use the TimeOnSiteService to return the number of seconds to match
      double timeToLive = service.SecondsToMatch(new HttpContextWrapper(HttpContext.Current), visitorGroupId);
      //convert to milliseconds and write to the page
      TimeToLive.Text = (timeToLive *1000).ToString();
   }

and then write some javascript to handle this (also perhaps write it slightly better than below. Hey I’m no javascript developer – yet!)

  <script type="text/javascript">

        function setAlertTimeOut() {
          var timeToLive = '<asp:Literal id="TimeToLive" runat="server" />';
          if (timeToLive > 0) {
              setTimeout('AlertMe()', timeToLive);
          }
        }

        function AlertMe() {
            alert("Time is Up");
        }

    </script>

and also don’t forget to call the method setAlertTimeOut() when the browser loads your page. I’d also imagine that your front end will need to do something a little more fancy than pop up an alert……….

When it comes to enterprise level security requirements,  governance is the key. This means not just having the ability to define your  security policy (through an admin panel for example) but also having a current and clear overview of your security setup.

Whilst EPiServer provides this for the creating page functionality (Set Access Rights page and the page-tree), it doesn’t offer this for Page Types. Certainly this is something we can improve upon so I’ve put together a simple Admin Plugin (built using MVC – why would you use anything else these days?)

The plugin lists each Page Type, whether it is available in edit mode, the users and roles who can create pages of that page type and also the allowable child page types for that page type.

A Nuget package (FortuneCookie.PageTypeSecurityOverview) built against EPiServer 6R2 is available from the EPiServer Nuget feed. The source code is available on GitHub – https://github.com/markeverard/FortuneCookie.PageTypeSecurityOverview

The changes in Version 2.0 are:

1. It’s now absolutely dependent on PTB2 – you’ll see why below.
2. PropertySecurity attributes can now be applied to PropertyGroups – this is why we need PTB2. You can now add a class level definition to a PropertyGroup definition
3. PropertySecurity Attributes can now be applied to Tab class definitions – providing a shortcut to more granular management of property security.
4. The ApplyToDefaultProperties functionality has been removed – this created some problems with the required validation settings – meaning it was possible to publish phantom pages with incomplete information.

The following hierarchical rules apply to attributes:

• A property level [Authorize] attribute in a PropertyGroup will override any other setting
• A property level [Authorize] attribute not on a PropertyGroup in a TypedPageData class  will tabs or class level settings
• An [Authorize] attribute on a tab will be honoured next and take preference over a class level setting
• A class level [Authorize] attribute on a tab will take preference only if the above aren’t matched

An updated Nuget package (FortuneCookie.PropertySecurity) built against .Net 4.0 / EPiServer 6R2 and PTB 2.0 is available EPiServer Nuget feed. The source code is available on GitHub – https://github.com/markeverard/FortuneCookie.PropertySecurity

• Specify edit / admin rights for each page – this allows you to define parts of the page tree that editors have permissions over. These permissions allow you to use the to specify one of the following access levels for each page (Read / Create / Change/ Delete / Publish / Administer) which dictates an editor’s ability to create / view and publish a page.
• Specify access levels required to view each edit mode tab – this allows you to group particular page properties onto particular tabs and show or hide those based on the access levels defined above.

However – what is missing here is a more granular approach for individual properties on each page. For example allowing users in a ‘MetaEditor’ role to update page meta data without being able to edit anything else.

EPiServer exposes an EditPanel.LoadedPage event which allows you to modify the loaded PageData object and modify it accordingly. One of the code properties available on an EPiServer property is DisplayEditUI which dictates whether the property is shown on the edit panel. Using the EditPanel.LoadedPage event to set property visibility in this way isn’t new.  However now we have strongly typed PageType classes (thanks to PageTypeBuilder) we can revisit this and treat it as a true application cross cutting concern.

What I wanted to be able to achieve was a true attribute based security system, that worked with the standard ASP.Net Membership model allowing developers to set which roles and users would be able to view and modify each property by setting an code based attribute in the TypedPageData class.

The solution relies on the following pieces:

• An EPiServer Initialization module that hooks up a method to the EditPanel.LoadedPage event.
• An Authorize attribute that you can place on PageTypeBuilder TypedPageData classes and properties.
• A locator which will scan your current page type for each property and modify the DisplayEditUI property based on the attributes values.

The following rules apply:

• A property level [Authorize] attribute will override any setting from a class level [Authorize] attribute
• [Authorize] attributes can set either usernames or roles which will be honoured – see the example below.
• The [Authorize] attribute allows you to specify whether you wish to apply the security rules to the built in-EPiServer properties as well as any you have defined through code.

Here is an example usage:

using System;
using FortuneCookie.PropertySecurity;
using PageTypeBuilder;
using EPiServer.Templates.AlloyTech.PageTypes.Tabs;

namespace EPiServer.Templates.AlloyTech.PageTypes.AlloyTech
{
   [PageType("74f6ef3e-407b-4132-8108-7fa831910197",
   Name = "[AlloyTech] Standard page",
   Filename = "/Templates/AlloyTech/Pages/Page.aspx",
   DefaultChildSortOrder = EPiServer.Filters.FilterSortOrder.None,
   Description = "The standard page is the most commonly used page on the web site.",
   DefaultVisibleInMenu = true,
   AvailablePageTypes = new Type[] {  })]
   [Authorize(Principals = "StandardPageEditorRole,mark.everard", ApplyToDefaultProperties = false)]
   public class StandardpagePageType : TypedPageData
   {
      [PageTypeProperty(EditCaption = "Main body",
      HelpText = "The main body will be shown in the main content area of the page",
      Tab = typeof(InformationTab),
      Type = typeof(EPiServer.SpecializedProperties.PropertyXhtmlString))]
      [Authorize(Principals = "MainBodyEditorRole")]
      public virtual string MainBody { get; set; }

      [PageTypeProperty(EditCaption = "Secondary body",
      HelpText = "The contents of this property will be shown in the right column of the page, you can use both text and images for layout.",
      Tab = typeof(InformationTab),
      Type = typeof(EPiServer.SpecializedProperties.PropertyXhtmlString))]
      public virtual string SecondaryBody { get; set; }
   }
}

In this case – any editor will be able to see the default EPiServer page properties (PageName, PageCategories etc). Editors in the StandardPageEditorRoles and me (user with username mark.everard) will be able to view / edit the SecondaryBody property, and only editors in the MainBodyEditorRole will be able to modify the MainBody property.

At present,  I’m not too happy with the blanket approach to the default properties that the current version has. I’d be interested to hear any better ideas for dealing with this – or better yet send me a pull request to the project on GitHub.

A Nuget package (FortuneCookie.PropertySecurity) built against .Net 4.0 / EPiServer 6R2 and PTB 2.0 has been uploaded for review to the EPiServer Nuget feed (and so should be available soon). The source code is available on GitHub – https://github.com/markeverard/FortuneCookie.PropertySecurity

Coming to talk to us this time will be:

• Meridium – who will be telling us all about the latest version of ImageVault – which is image and digital asset management module for EPiServer.
• Joel Abrahamsson – who should need little introduction. Joel has been instrumental in helping to improve the EPiServer development experience – through his open source projects such as PageTypeBuilder and EPiAbstractions (amongst others). Tonight though Joel will be wearing a different hat as he’ll be talking about his latest project. Truffler.Net – an advanced search engine and C# API
• Plus – some other (to be confirmed) talks from our community members

We will start presentations promptly at 7pm so please aim to get there for 6:30pm

There will be some food and drinks (kindly provided by EPiServer UK) and plenty of opportunity to network and talk tech.

Full details are on the Meetup page where you can sign up and RSVP to confirm attendance.

I hope you’ll agree that its a great program and also I think we’re incredibly lucky to have both Meridium and Joel flying over from Sweden to come and talk to us. Please show your support.

See you all on the 23rd.

Mark

This function allows an editor to create a Composer area that will display a unique list of other Composer functions; depending on which visitor group a user is matched to in your site. This means that editors can personalise more than just page content, and can also adjust the page layout and functionality offered to each visitor, by dragging different Composer functions into each Personalized ‘slide’ within the Personalization Container function.

Upgrading a site to 6 R2

After upgrading a few sites from CMS6 to CMS6R2, if you don’t check the option to import PageTypes during the upgrade process (which if you’re using PageTypeBuilder you might think you can skip) then  the Personalization container isn’t created, and you’ll be missing this piece of functionality.

The easiest way to re-create this function is to export the composer PageType information from a ‘fresh’ install of the Composer / R2 Alloy Tech site, and then import this into your site.

To save you the hassle of setting up a fresh demo site. I’ve included an exported Composer Personalization function as a download below (.xml format).

PersonalizationContainer.zip – Import using EPiServer Composer Import / Export page.

You just need to import this using the Composer import feature in EPiServer Admin mode, and hey presto!

Technically, this is normally achieved by adding a querystring key to the campaign link url and then tracking requests that use this key. So for example, a Google Adwords campaign linking to your /products page would also include a querystring parameter of cid=marketingcampaign (example: http://yoursite.com/products?cid=marketingcampaign)

This querystring parameter can be picked up by your analytics implementation and used to track various aspects of the campaign.

On an EPiServer CMS6 R2 site, editors can use the Personalization/Visitor Group framework to provide a unique page experience per visitor, meaning that its possible to provide personalized content for each external marketing campaign on any page on your site.

Out-of-the-box, EPiServer provides a criterion which checks the incoming request Url or the page referrer, but not one that checks the querystring of the incoming request.

Creating a Visitor group criterion is straight forward – the only issue I’ve ever had trouble with; is when working on a .NET 4.0 project – which was solved by Ted Nyberg.

I’ve created a simple QueryString Criterion which will provide a match based on the following:

1. Whether the current request contains a user specified querystring key
2. and / or whether the current request contains a matching querystring key which also has the user specified value.

The source code is available as part of the Criteria Pack on Codeplex and of course there is a Nuget package on Nuget.episerver.com – (as soon as its been approved!)