I thought it was tricky to read a file from disk and add it to the Sitecore media library untill I actually look into it. Sitecore has introduced 2 classes to help with the creation: The Sitecore.Resources.Media.MediaCreator and the Sitecore.Resources.Media.MediaCreatorOptions. 

The Sitecore.Resources.Media.MediaCreatorOptions class is the real gem here, as it helps you pick the right database to write to, but it also creates the folders where the file must be placed. In other words; don’t worry about creating folder items yourself. Let the MediaCreatorOptions do that for you. Here is an example:

public MediaItem AddFile(string fileName, string sitecorePath, string mediaItemName)
{
  // Create the options
  Sitecore.Resources.Media.MediaCreatorOptions options = new Sitecore.Resources.Media.MediaCreatorOptions();
  // Store the file in the database, not as a file
  options.FileBased = false;
  // Remove file extension from item name
  options.IncludeExtensionInItemName = false;
  // Overwrite any existing file with the same name
  options.KeepExisting = false;
  // Do not make a versioned template
  options.Versioned = false;
  // set the path
  options.Destination = sitecorePath + "/" + mediaItemName; 
  // Set the database
  options.Database = Sitecore.Configuration.Factory.GetDatabase("master");

  // Now create the file
  Sitecore.Resources.Media.MediaCreator creator = new Sitecore.Resources.Media.MediaCreator();
  MediaItem mediaItem = creator.CreateFromFile("c:\\myfile.pdf", options);
  return mediaItem;
}

This exampel inserts the myfile.pdf into the media library and stores it as /pdffolder/uploaded/myfile:

MediaItem myFile = AddFile("c:\\myfile.pdf", "myfile", "/pdffolder/uploaded");

The MediaCreator is also available through the static implementation, Sitecore.Resources.Media.MediaManager.Creator, so if you like statics, you can use that one instead.

The MediaCreator can also create media files from a MemoryStream:

// Remember to insert the appropriate try..catch..finally blocks.
// I have refrained from using them to compress the example.
Sitecore.Resources.Media.MediaCreatorOptions options = new Sitecore.Resources.Media.MediaCreatorOptions();
// Now use the options class as I did in the previous example
// ... insert code here ...
// ...
// Read the file from stream:
FileInfo fi = new System.IO.FileInfo(fileName);
FileStream fs = fi.OpenRead();
MemoryStream ms = new MemoryStream();
ms.SetLength(fs.Length);
fs.Read(ms.GetBuffer(), 0, (int)fs.Length);
ms.Flush();
fs.Close();
// Now create the file in Sitecore. This time I'll use the static implementation of the MediaCreator
Item mediaItem = Sitecore.Resources.Media.MediaManager.Creator.CreateFromStream(ms, fileName, options);
ms.Dispose();

I am developing a Google Maps module for Sitecore, and when I test it in Firefox my Google Javascript won’t load. All I get is: “Waiting for gg.google.com…”.

Waiting for gg.google.com

It seemes to be a problem with certain versions of Firefox and Firebug. If Firebug has Script debugging enabled, the Google Maps script will not load.

Disabling Script debugging in Firebug solves the problem:

Disable Script Debugging in Firebug

But now I cannot debug the Javascript I am creating using Firefox. Well… I’m glad I got Google Chrome.

One of my recent projects has been to run YetAnotherForum (YAF) inside a Sitecore website (read this earlier post). The changed YAF source can be found as an open source project at http://trac.sitecore.net/YAFIntegration.

Now the project has been expanded with a Sitecore package that allows you to control the behaviour of the YAF control from inside Sitecore. The optional package consists of a custom field and a sublayout that allows you to set which board, group or forum that YAF should display.

When placing the custom field on a page, it becomes possible to select which board, group or forum that the sublayout must display:

Displaying boards, groups and forums from YAF

The sublayout uses this data to display whatever is chosen:

This example shows how YAF used the information from the dropdown to display one forum only.

The function gives you the possibility to display one forum on one Sitecore page, and another forum on another page. Or displaying all forums on one page, one group on another page, and one forum on a third page. And so on and so on. 

The feature is part of the optional Sitecore package included in the YAFIntegration project. Read more about the package here: http://trac.sitecore.net/YAFIntegration/wiki/Optional_Package

As I mentioned in the previous post, YetAnotherForum (YAF) cannot run inside Sitecore unless the code base of YAF is changed. So that’s exactly what I did. 

YetAnotherForum running in Sitecore

 You can find the changed YAF codebase in Sitecores trac:

http://trac.sitecore.net/YAFIntegration

So what does the code do? It allows you to run YAF in a Sitecore layout, on any Sitecore page you wish, using Sitecore extranet (or any other domain) users.

But let’s begin with the beginning. In order to run YAF inside a Sitecore web site at all, major changes are required in the web.config of your website. Basically it requires you to merge the YAF config files with the Sitecore config files. I have provided a sample web.config where I have merged the 2 config files together, as well as a complete description of all changes required.

After you have merged the web.configs, you will need to build the code and apply the code and binaries to the Sitecore solution. The documentation will help you with this.

What code changes have been made then? Since Sitecore and YAF both uses standard .net security providers, changes are relatively small (although widespread). YAF is capable of digesting Sitecore members and roles (users and groups) directly. But since the .net platform only allows one profile provider, the YAF profile provider need to inherit from Sitecore’s profile.

Another change are also implemented: The standard .net security model expects all users to have access to all parts of the website. Sitecore cannot live with that, as some users can access the client, and other can access the extranet. Sitecore deals with this issue in a brilliant, simple way, by prefixing users with the Sitecore domain name. So when Sitecore returns the Anonymous user, the username is extranet\Anonymous. To avoid displaying user names prefixed with the current domain name in YAF, the code wraps the MembershipUser class to ensure that only users from the current domain (usually extranet) can log into YAF, and that the domain name is not displayed in the username.

Users from the current Sitecore domain is displayed in YAF.

Since YAF is licensed under the GNU public license, so is this code. This means that you can use, change and share the code and any changes you make, as you wish.

YetAnotherForum (or YAF for short) is an open source discussion forum written in C# and .NET. Sitecore and YAF cannot run in the same IIS application (they can, if you change the YAF source code, which I will show in a later post), but with a little piece of open source code you are able to use the Sitecore users in YAF.

The open source code is available at:

http://trac.sitecore.net/YAFSingleSignon

The idea is to have Sitecore and YAF running in the same second-level domains: For example let your Sitecore website run at www.mysite.com and YAF in forum.mysite.com.
When users log into the Sitecore extranet, the user information is stored in a cookie which is then digested by YAF.

First you will need to download the code from http://trac.sitecore.net/YAFSingleSignon and build it yourself.

Copy the YAFLogin.dll to your Sitecore /bin/ folder. Then copy the YAFLogin.dll and SitecoreLogin.dll to the YAF /bin/ folder. Also copy the /sitecorelogin/default.aspx page to YAF.

In order to save the extranet credentials, you must apply the following 2 lines of code to your Sitecore extranet login dialog:

// Create a SitecoreUser by logging into the Sitecore extranet
// and retrieve the user information
SitecoreUser user = SitecoreUser.Login(eUserName.Text, ePassword.Text, chkRememberMe.Checked);
// Store the SitecoreUser as a cookie. This cookie can be retrieved by YAF.
user.Store();

That’s it. The user information is persisted in a cookie which can be digested by YAF, as cookies can be shared across second-level domains. There are 2 methods of digesting the Sitecore extranet user. The first method is to call the /sitecorelogin/default.aspx page which will create the user in YAF (if not already existing) do a login a redirect to the default YAF page. The second method is to extend the default.aspx page of YAF with the following code:

protected void Page_Load(object sender, EventArgs e)
{
  try
  {
    // Restore the sitecore user from the persistant storage (the cookie)
    YAF.Sitecore.PersistenceManager manager = new YAF.Sitecore.PersistenceManager();
    YAF.Sitecore.SitecoreUser user = manager.Restore();
    if (user != null)
    {
      // Instantiate the login manager and log the Sitecore user into YAF
      YAF.Sitecore.LoginManager loginManager = new YAF.Sitecore.LoginManager();
      loginManager.Login(user);
      // The SitecoreUser is now logged in, and the cookie can be removed
      manager.Delete();
      // Load same page to let YAF read the session
      Response.Redirect(Request.RawUrl,false);
    }
  }
  catch (Exception ex)
  {
    Response.Write("Failed to login Sitecore Extranet user: " + ex.Message);
  }
}

This code does the same as the /sitecorelogin/default.aspx but will be executed by every page in YAF you call.

You can read more about the source code at http://trac.sitecore.net/YAFSingleSignon/browser/Trunk/Sitecore.YAF.docx

Usually we assume that every user have cookies enabled. I cannot find any stats on the number of users who have disabled cookies, but 94% of all browsers have Javascript enabled, so lets assume that en equal number have cookies enabled (I know that the remaining 6% could easily be web crawlers).

What should we do with the remaining 6% then? If the website uses cookies as a shopping basket, it would be a good service to let the user know that he is not able to shop without enabling cookies.

When first investigatig this, I assumed that a server-side solution existed. So I implemented the following code in c#:

if (Request.Browser.Cookies) 
  Response.Write("Your browser supports cookies. You may shop");
else
  Response.Write("The Browser does not support Cookies. Shopping is not possible.");

Unfortunately this tells me if the browser as such supports cookies, not that cookies are enabled by the user. When using IE7, the code always returns true, since IE7 supports cookies in general. Disabling cookies in IE7 changes nothing.

I used Google to search for the answer, and unfortunately you need to use Javascript to check if the user have enabled cookies in his browser. This website contains the Javascript to use.

I rewrote the Javascript so it writes some text if cookies are enabled, and another text if not:

function CookieSetText(yesText, noText)
{
  var cookieEnabled=(navigator.cookieEnabled)? true : false
  //if not IE4+ nor NS6+
  if (typeof navigator.cookieEnabled=="undefined" && !cookieEnabled)
  {
    document.cookie="testcookie"
    cookieEnabled=(document.cookie.indexOf("testcookie")!=-1)? true : false
  }
  if (cookieEnabled)
    document.write(yesText);
  else
    document.write(noText);
}

 When adding a reference to the script in my HTML header, I can use it from my Sitecore XSLT’s:

<script type="text/javascript">
  CookieSetText('<sc:text field="CookiesEnabled"/>', '<sc:text field="CookiesDisabled"/>');
</script>

Th example above writes the text for the current item’s “CookiesEnabled” field if cookies are enabled, or writes from the “CookiesDisabled” field when cookies are disabled.

This is one of my oldest tricks in my book. The tree-like left menu is used for almost any website I do, and will work like on this site (example site is not developed by me nor by Pentia). This image is from a website using the menu:

Sample Menu

The XSLT renders a multilevel left menu, usually placed on pages on websites utilizing a sectional top menu. The menu will fold out any subitems below the current page, and will display the entire tree structure from the current page and upwards to the sectional page that the left menu is placed under.

In this simplified example I use pages with the menu title placed in the field Menu_Title, and I use a checkbox called Show_In_Menu to hide items that is not to be shown in the left menu.

The left menu is initialized with the current section page that will act as the root item for the menu. If you use the home page as your section item it will render the complete web site.

<xsl:template match="*" mode="main">
  <!-- Get the root item -->
  <xsl:variable name="section" select="ancestor-or-self::item[@id = $home/item/@id]"/>
  <!-- Render the menu from the root item and downwards -->
  <xsl:call-template name="renderMenu">
    <xsl:with-param name="root" select="$section"/>
    <xsl:with-param name="level" select="0"/>
    <xsl:with-param name="items" select="$section/item[sc:fld('Show_In_Menu',.) = '1']"/>
  </xsl:call-template>
</xsl:template>

Parameter root identifies the root item of the menu. Level is used for styling the menu (if you use different styles for the different levels). Items is a list of all items below the root item the must be rendered in the menu. In this example this includes all items where the field Show_In_Menu is checked.

The menu is rendered recursively by letting the renderMenu template call itself for each level it has to render.

<xsl:template name="renderMenu">
  <xsl:param name="root"/>
  <xsl:param name="level"/>
  <xsl:param name="items"/>

  <xsl:if test="$items">
<ul class="level{$level}">
      <xsl:for-each select="$items">
        <xsl:variable name="subItems" select="item[sc:fld('Show_In_Menu',.) = '1']"/>
	<li>
          <!-- Apply CSS to the link -->
          <xsl:variable name="selectedClass">
            <!-- Item has children -->
            <xsl:if test="$subItems">children</xsl:if>
            <!-- Item is open (one of it's children is the current page -->
            <xsl:if test="$subItems and @id = $selectedItem/ancestor-or-self::item/@id"> open</xsl:if>
            <!-- Item is the current page -->
            <xsl:if test="@id = $selectedItem/@id"> selected</xsl:if>
          </xsl:variable>

          <!-- Write link including generated CSS tag -->
          <a href="{sc:path(.)}" class="{$selectedClass}">
            <sc:text field="Menu_Title"/>           
          </a>

          <!-- Go further down the tree and render children -->
          <xsl:if test="@id = $selectedItem/ancestor-or-self::item/@id">
            <xsl:call-template name="renderMenu">
              <xsl:with-param name="root" select="."/>
              <xsl:with-param name="level" select="$level+1"/>
              <xsl:with-param name="items" select="$subItems"/>
            </xsl:call-template>
          </xsl:if>
       </li>
      </xsl:for-each></ul>
  </xsl:if>
</xsl:template>

The template renders all items of the first level, but second, third and later levesl are only rendered if the current page is found in that branch. This gives the menu its fold-out like behaviour.
Please note how I style the menu link. The variable selectedClass is set with different content depending of the properties of the link to render. The example uses the three most commonly used styles applied: When the link has children, when the link has children, and the current page is one of these children and when the link is the current page.
Yes, it’s that simple to do an advanced left menu in Sitecore. I have also done the same menu for Umbraco, but that’s a different matter.

The Forms data viewer is one example of a webform in Sitecore

Writing XAML applications for use in the Sitecore shell can be very tricky. And I admit that I often decide to use a webform instead. Especially if I need to write a minor application that does not use Sitecore data as such, but still needs to be a part of the Sitecore desktop.

One of the solutions is to implement my own Generic Identity and use declarative security in my webform. And it’s quite easy too. This code can be expanded, but I have kept it simple to demonstrate the principals. Implementing yout own security context requires a generic identity (a user) and a generic principal (a list of groups). The generic identity looks like this:

using System.Security.Permissions;
using System.Collections.Generic;
using System.Threading;
using System.Security.Principal;

/// <summary>
/// Class imlementing a generic identity
/// which equals one Sitecore user
/// </summary>
public class SitecoreIdentity : IIdentity
{
  private Sitecore.Security.Accounts.User _user;

  public SitecoreIdentity()
  {
    _user = Sitecore.Context.User; 
  }

  #region IIdentity Members

  public string AuthenticationType
  {
    // I cheat a little bit. Sitecore returns an empty AuthenticationType
    // so I use the domain name as authenticationtype instead
    get { return Sitecore.Context.Domain.Name; }
  }

  public bool IsAuthenticated
  {
    get { return _user.Identity.IsAuthenticated; }
  }

  public string Name
  {
    get { return _user.Name; }
  }

  #endregion
}

An identity is accompanied by a principal, which equals the roles that the identity (user) belongs to:

/// <summary>
/// Class implementing a generic principal
/// which equals the groups one sitecore user
/// belongs to
/// </summary>
public class SitecorePrincipal : IPrincipal
{
  private List<string> _roles = new List<string>();
  private IIdentity _identity;
  private Sitecore.Security.Accounts.User _user;

  public SitecorePrincipal(IIdentity identity)
  {
    _identity = identity;
    _user = Sitecore.Context.User; 
    // I add the administrator as a role to my principal so I can query it
    // when using declarative security
    if (Sitecore.Context.User.IsAdministrator)
      _roles.Add("Administrator");
    // Add all role names from the current user to my principal
    foreach (Sitecore.Security.Accounts.Role userRole in _user.Roles)
    {
      _roles.Add(userRole.Name);
    }
  }

  #region IPrincipal Members
  public IIdentity Identity { get { return _identity; } }
  public bool IsInRole(string role) { return _roles.Contains(role); }
  #endregion
}

I can now assign the current thread’s principal of the current webform to my own principal:

void Page_Load(object sender, System.EventArgs e)
{
  // Create new user
  SitecoreIdentity user = new SitecoreIdentity();
  // Assign the roles to that user
  SitecorePrincipal roles = new SitecorePrincipal(user);
  // Assign the roles to the current thread
  Thread.CurrentPrincipal = roles;
}

My webform is now runing under the security context of my Sitecore user, and I can now use declarative security to allow or disallow execution of code. The following function will only execute if a Sitecore user is authenticated:

[PrincipalPermission(SecurityAction.Demand, Authenticated=true)]
private void WriteText()
{
  Response.Write("Authentication: " + Thread.CurrentPrincipal.Identity.AuthenticationType);
  Response.Write("Is authenticated: " + Thread.CurrentPrincipal.Identity.IsAuthenticated);
  Response.Write("Name: " + Thread.CurrentPrincipal.Identity.Name);
}

It is the PrincipalPermission attribute that sets the security on my function. If the current Sitecore user is not logged in, .net will throw an exception.

Here is another example. This will allow access if the user is a Sitecore administrator, and block everyone else:

[PrincipalPermission(SecurityAction.Demand, Role="Administrator")]
private void WriteText()
{
  // ... your code here
}

The Javascript decodeURIComponent()  function decodes a string that was URI encoded with the encodeURIComponent() Javascript function. If you wish to encode a string in C# that can be decoded with decodeURIComponent you have to use the EscapeDataString function:

System.Uri.EscapeDataString("This is my text");

The escaping an unescaping of strings can for example be used to add HTML strings to a Javascript array from C#. Adding HTML strings to an array using the ClientScript.RegisterArrayDeclaration() function will produce an error when the page is executed. But if you encode/decode the strings, the function will succeed:

protected void Page_Load(object sender, EventArgs e)
{
  StringBuilder sb = new StringBuilder();
  sb.AppendFormat("\"{0}\"", Uri.EscapeDataString("
<h1>This is my first heading</h1>
"));
  sb.AppendFormat("\"{0}\"", Uri.EscapeDataString("
<h2>This is my second heading</h2>
"));
  sb.AppendFormat("\"{0}\"", Uri.EscapeDataString("
<h3>This is my third heading</h3>
"));
  Page.ClientScript.RegisterArrayDeclaration("myArray", sb.ToString());
}

This function appends 3 HTML strings to an array and adds the array to the page. The strings are now accessible from Javascript. This pseudo function will take an ID of a DIV tag and the index of the array and output the text from the above created array in the DIV tag:

<script language="javascript" type="text/javascript">
  function ShowDescription(divID, index)
  {
    var divTag = document.getElementById(divID);
    divTag.innerHTML = decodeURIComponent( myArray[index] );
  }
</script>

Cookies are text strings that is used within the browser memory. In reality, cookies can store anything, as long as you follow these limitations:

• Do not store more than 20 cookies per domain.
• Do not store more than 4096 bytes per cookie.

Microsoft states that their browser can store at least 20 cookies per domain and at least 4096 bytes per cookies,  but the official max size is 4k, so you should stick to this.

With this in mind, my proposal to stream objects into a cookie is probably not such a good idea. There is some overhead when streaming classes in C#, as the class definitions are also stored. However, if you observe the limits as described above, you should be fine. The following piece of code saved me a lot of time, that’s for sure.

The first function will store a made-up class (called MyClass) into a cookie:

using System;
using System.IO;
using System.Runtime.Serialization;
using System.Runtime.Serialization.Formatters.Binary;
using System.Web;

public void Store(MyClass myClass)
{
  HttpCookie cookie = new HttpCookie("myCookie")
  {
    // Set the expiry date of the cookie to 15 years
    Expires = DateTime.Now.AddYears(15)
  };
  Stream myStream = new MemoryStream();
  try
  {
    // Create a binary formatter and serialize the
    // myClass into the memorystream
    IFormatter formatter = new BinaryFormatter();
    formatter.Serialize(myStream, myClass);
    // Go to the beginning of the stream and
    // fill a byte array with the contents of the
    // memory stream
    myStream.Seek(0, SeekOrigin.Begin);
    byte[] buffer = new byte[myStream.Length];
    myStream.Read(buffer, 0, (int)myStream.Length);
    // Store the buffer as a base64 string in the cookie
    cookie.Value = Convert.ToBase64String(buffer);
    // Add the cookie to the current http context
    HttpContext.Current.Response.Cookies.Add(cookie);
  }
  finally
  {
    // ... and remember to close the stream
    myStream.Close();
  }
}

One thing to remember is that cookies store strings, not binary data. That’s why I have to convert the stream to a byte array, and convert the byte array to a base 64 string. This conversion introduces another overhead as base64 strings converts 3 bytes into 4 ASCII chars.

Now lets restore my object from the cookie:

public MyClass Restore()
{
  // Always remember to check that the cookie is not empty
  HttpCookie cookie = HttpContext.Current.Request.Cookies["myCookie"];
  if (cookie != null)
  {
    // Convert the base64 string into a byte array
    byte[] buffer = Convert.FromBase64String(cookie.Value);
    // Create a memory stream from the byte array
    Stream myStream = new MemoryStream(buffer);
    try
    {
      // Create a binary formatter and deserialize the
      // contents of the memory stream into MyClass
      IFormatter formatter = new BinaryFormatter();
      MyClass streamedClass = (MyClass)formatter.Deserialize(myStream);
      return streamedClass;
    }
    finally
    {
      // ... and as always, close the stream
      myStream.Close();
    }
  }
  return null;
}

If you replace the MyClass with an interface or a base class, you will have the flexibility to store any class either implementing the interface or inheriting from the base class.

And if you need help on how to remove cookies, you can read this article on how to add and remove cookies.