Note: An updated version of this blog for StoreFront 2.0 is available here.

StoreFront 1.2 has been released recently which contains a new version of Receiver for Web. I think it is time for me to provide a follow-up for my first blog on Customizing Receiver for Web. This is to show how to update the original customization to work with the new release and to describe the extra customization support provided by the new release.

Updating Customization from StoreFront 1.1

If you have followed my original blog to customize your Receiver for Web in StoreFront 1.1, you will find that the majority of the customization examples still work with StoreFront 1.2. The ones that stop working require little tweaking. We will look into them one by one here.

Example 1: Rebranding the Logon Screen works without any change.

In Example 2: Customizing the Home Screen, we added the following CSS definitions to change the font color for the user name and Log Off link.

#resources-header #header-userinfo {
  color: lightgreen;
}
#resources-header #header-logofflink {
  color: lightgreen;
}

The user name and the Log Off link elements are combined in the new release.  The first CSS definition hence needs to be modified to:

#resources-header #header-userinfo a {
  color: lightgreen;
}

The second CSS definition is now redundant and should be removed. The resultant Home Screen looks like:

In Example 3: Adding a Hyperlink to the Footer Area, we used the following CSS definitions to prettify the hyperlink in the footer area:

#resources-footer div {
  padding-top: 58px;
}
#resources-footer a {
  color: lightgreen;
}
#resources-footer a:hover {
  color: silver;
  text-decoration: underline;
}

Since the new release of Receiver for Web introduces the Apps and Desktops switcher in the footer area, the first CSS definition is no longer suitable and hence should be removed. This would make the UI looks like:

You can further fine-tune the CSS styles to prettify the footer area to your satisfaction.

Due to the footer change, Example 4: Loading Extra UI Files also needs some modifications. Originally we used the following line of JavaScript to load the HTML fragment to the resources-footer element because there was no other elements in the footer area:

$('#resources-footer').load('contrib/footer.htm');

This needs to be changed to:

$('#resources-footer').load('contrib/footer.htm').appendTo($('#resources-footer'));

We append the HTML fragment to the footer area rather than replacing the whole area.

In Example 5: Customizing Texts in the Header Area, changing “Welcome” to “Signed in as” is no longer applicable.

Adding Pre-Login and Post-Login Messages

Receiver for Web in StoreFront 1.2 provides hooks for you to add custom pre-login and/or post-login messages if you wish. To add a pre-login message, insert the following JavaScript code to custom.script.js:

$(document).ready(function() {
  var markup = '<div id="prelogin-message">' +
    '<h3>Disclaimer</h3>' +
    '<p>This site is for the employees of World Co only!</p>' +
    '<a href="#">Continue...</a>' +
    '</div>';
  CTXS.Application.preLoginHook = function () {
    $('#prelogin-pane').append($(markup)).ctxsDisplayPane().find('a').click(function () {
      CTXS.Events.publish(CTXS.Events.preLogin.done);
      return false;
    });
  };
}

If you have already got $(document).ready(function() {}) defined in custom.script.js, you should merge them together. The function CTXS.Application.preLoginHook is invoked by the Receiver for Web at runtime before the user logs in. It appends the sample HTML fragment to a <div> element and calls ctxsDisplayPane to display the message. A click handler is registered on the “Continue…” link, which signals that Receiver for Web should switch to the next screen when it is clicked.

You should also add CSS definitions to custom.style.css to format the message. Here are the sample CSS definitions:

.custom-pane {
  text-align: center;
  color: white;
}
.custom-pane h3 {
  margin-top: 80px;
  font-size: 30px;
}
.custom-pane p {
  margin: 40px 0;
  font-size: 18px;
}
.custom-pane a, .custom-pane a:active, .custom-pane a:visited {
  font-size: 24px;
  color: tan;
}
.custom-pane a:hover {
  text-decoration: underline;
}

The pre-login message looks like:

A custom post-login message can also be displayed after the user logs in, just before displaying the user’s applications and desktops. The code is very similar to adding the pre-login message. Here is an example:

$(document).ready(function() {
  var postLoginMarkup =   '<div id="postlogin-message">' +
    '<h3>Announcement</h3>' +
    '<p>This site is scheduled for maintenance between 6:00pm and 10:00pm next Saturday.</p>' +
    '<a href="#">Continue...</a>' +   '</div>';

  CTXS.Application.postLoginHook = function () {
    $('#postlogin-pane').append($(postLoginMarkup)).ctxsDisplayPane().find('a').click(function () {
      CTXS.Events.publish(CTXS.Events.postLogin.done);
      return false;
    });
  };
}

This is the resultant post-login message:

Supporting a New Language

You can add support for a new language to Receiver for Web. This involves adding a language pack to Receiver for Web and adding relevant language resources to the Authentication Service.

Adding a language pack to Receiver for Web

New language packs are comprised of a culture definition script file and a string bundle script file for each language.

Culture definition

The format of the culture definition script file is:

(function ($) {
  $.globalization.availableCulture("<lang-code>", {
    name: "<lang-code>",
    englishName: "<language name in English>",
    nativeName: "<language name in native language>",
    stringBundle: "<path to the string bundle>"
  });
})(jQuery);

For example, a culture file for Polish looks like:

(function ($) {
  $.globalization.availableCulture("pl", {
    name: "pl",
    englishName: "Polish",
    nativeName: "polski",
    stringBundle: "contrib/wrstrings.pl.js"
  });
})(jQuery);

This should be saved as culture.pl.js.

String bundle

The string bundle script file defines a set of name-value pairs. You can copy an existing string bundle file from scripts/<lang-code>/ctxs.wrstrings.js, e.g. the English one from scripts/en/ctxs.wrstrings.js to wrstrings.pl.js. Then replace the language code ‘en’ to ‘pl’ and replace all string values with the translated ones.

Loading the language pack

After you create the language pack, you can add the following code to custom.script.js:

$(document).ready(function () {
CTXS.Localization.getScript("contrib/culture.pl.js");
});

This code loads the culture definition and string bundle script files.

Adding language resources to Authentication Service

The user interface for the logon form is provided by the StoreFront Authentication Service. Localizing these strings requires creating 3 additional resource files. Continuing with using Polish (language code ‘pl’) as an example:

In Windows Explorer, open the folder C:\inetpub\wwwroot\Citrix\Authentication\App_Data\resources.

  • Copy ExplicitAuth.resx to ExplicitAuth.pl.resx
  • Copy ExplicitCore.resx to ExplicitCore.pl.resx
  • Copy ExplicitFormsCommon.resx to ExplicitFormsCommon.pl.resx

In all the newly copied files, locate each <data> element and translate the string in the corresponding <value> element. Save each file using UTF-8 encoding.

Run the command `iisreset’ on the Storefront to restart IIS.

Adjusting UI elements for the new language

On a Polish system, loading the Receiver for Web site in a browser should now display the UI with all strings appearing in Polish. If any translated strings are longer in Polish than the built-in languages and are not correctly positioned, it is worth noting that the language code (‘pl’ in this case) appears as a class name on the <body> tag, and this can be used to create CSS definitions to adjust elements as necessary.  For example, the following CSS definition would make the logon box slightly larger when using Polish, to accommodate longer strings:

.pl #logonbox-logonform {
  width: 320px;
}

Limitations

As noted previously, the User Interface of Receiver for Web is evolving. Page elements may be added, removed or renamed in future releases. Hence there is no guarantee that customization for a particular release will work on different releases.