Tips for the UnifiedFileSystem

Over the years I've come to learn a few things about the EPiServer UnifiedFileSystem (UFS from now on), some the easy way, but most the hard way. The following is a list of my recommendations for when setting up the UFS in a new site.

1. Always create a "System" share
A System share is a secure folder mapping in the UFS. It can allow read access to specific files as required, but should only allow website administrators access to create, modify and delete.

What I tend to use this type of share for is to store system files like XML source documents used in property drop-down lists and other system related files that may need to be edited at some time.

To set this sort of share up you will need to add something like the following to your web.config file:

<handler pageDirectory="False" virtualName="System" virtualShare="True" type="EPiServer.FileSystem.Handler.NativeFileSystem, EPiServer">
<customSettings PhysicalPath="D:\Websites\EPiSample\WebSystemFiles" />
</handler>

2. Secure the special "Pages" folder
Now I know doing this will cause extra load on the server as it has to check permissions on files etc, but not securing this location can cause a few security headaches down the track.

A few times now clients have come to me saying they have found some documents in their site using Google that should not be there. What had happened is Google had indexed the site and documents, then a page had expired, but the documents were still available by a direct link.

The solution to this is easy, secure the "Pages" folder. Doing this will ensure that files uploaded to a page folder will get the same permissions applied to them as the page. So if the page expires, then so do the files! To configure a secure pages folder you will need to add something like the following to your web.config file:

<handler pageDirectory="True" virtualName="pages" virtualShare="True" type="EPiServer.FileSystem.Handler.NativeFileSystem, EPiServer">
<customSettings PhysicalPath="D:\Websites\EPiSample\Pages" />
</handler>

3. Create an MS Indexing Service cataglog for your site
To make the search work correctly in the File Manager you really need to configure a catalog for your site. Even if you are using a different search tool for your public site, it's important to configure MS Indexing Server for your user's when using the File Manager search.

You will only need to create one catalog, as long as it indexes all your files, as EPiServer will automatically set the search scope when searching in File Manager. To configure a catalog for the UFS you will need to add something like the following to your handlers in the web.config (except for any versioned file shares as they have their own search capabilities):

<handler pageDirectory="True" virtualName="pages" virtualShare="True" type="EPiServer.FileSystem.Handler.NativeFileSystem,EPiServer">
<customSettings IndexCatalog="EPiSampleCatalog" PhysicalPath="D:\Websites\EPiSample\Pages" />
</handler>

All this information and a lot more can be found in the technical note "Unified File System"

EPiServer 4.61 Hotfix

Just a quick note that I received a hotfix from EPiServer the other day for version 4.61. I don't think the hotfix has officially been released yet, but if you need it then I suggest you contact the support team [Knowledge Center login required] for a copy.

Here is what the hotfix addresses:

• #45503 Simple Address always adds a epslanguage parameter when rewriting url
• #45530 GetPostedData method on XFormData ignores "start date" and "end date" for public overloads of the method
• #45554 Filenames are not encoded in the file manager
• #45545 Login cookies does not work with sliding expiration
• #45579 Copy pages corrupts tblTree
• #45401 Attaching to the MovingPage event and setting CancelAction to true gives strange GUI behaviour
• #45635 Users and groups are not sorted by name by default when listing from database
• #45591 Faulty path to CSS and JS files in Admin/Workflow.aspx
• #45671 Calls WindowsPrincipal.IsInRole() makes 4.61 sites slow
• #45562 FieldOrder set to 0 when adding a new property
• #45436 Fetch data does not work with mirroring
• #45468 FileManager in ActionWindow is very slow when tblUnifiedPath contains many rows
• #45804 Add ability to handle negative SIDs
• #45815 Error message " PropertyData object with name "" already exists" in Edit mode
• #45816 Export should export the name of the SID for compatibility with EPServer 5.x
• #45817 Publishing a page in a large site is slow due to tblWorkProperty lacking proper index
• #45572 Mirrored EPiFields not working (Requires the EPiServer Fields 4.61 HotFix 1 to work)
• #45575 Custom query strings are lost when making a post back for a page with a friendly url
• #45858 Added InternalPageDataHelper class
• #45565 Possible race condition in license handling for multiple sites with the same database

MS-SQL only:

• #45528 SQL timeout problems after upgrading to 4.61
• #45821 Deadlocks can occur during simultaneous page publishing
• #45818 Searching on properties is slow due to poorly optimized sprocs

Custom validation for core properties

Last week a colleague of mine asked a question:

Is it possible to limit the amount of data that can be entered into EPiServer text properties?

Now this can be achieved in a number of ways. First, if the property is one you have added, then you can just create a custom property and add whatever type of validation you like, pretty standard stuff. However, if the property is a core property such as "PageName", then you have capture the "EditPageValidators" event in the EPiServer.Global class.

Here is an example I have used for a few clients now to validate the "PageName" to set a maximum number of characters. This same implementation can be used to perform any custom validation against core properties in EPiServer.

In the global.asax, hook the following up in the Application_Start method:

Global.EditPageValidators += new PageValidateEventHandler(Validators.ValidatePageNameLength);

The implementation for ValidatePageNameLength is the following:

public static void ValidatePageNameLength(object sender, PageValidateEventArgs e)
{
int length = (int)Global.EPConfig["EPnMaxPageNameLength"];
if( e.Page.PageName.Length > length && length > 0 )
{
e.IsValid = false;
e.ErrorMessage = String.Format( "\"Name\" must not exceed {0} characters", length );
}
}

This then requires a web.config key of “EPnMaxPageNameLength” to configure the number of characters in the PageName property.

Workflow admin pages not displaying correctly

I came across this bug the other day and it has been confirmed by EPiServer as a bug which will be fixed in the next version of EPiServer (0045591: Faulty path to CSS and JS files in Admin/Workflow.aspx).

Issue Description
When working in any of the workflow admin or edit screens, styles sheets, JavaScript files and images are broken.

Reproducing the Issue
The issue occurs when you install the edit and admin modes in a sub-directory in the site. E.g. installing edit mode to "/secure/edit" and admin to "/secure/admin".

With EPiServer Manager 1.3 [login required] you are forced to install edit and admin modes to a directory other than the default. If you choose a structure where edit and admin are not in the website root, referenced resources break.

Fixing the Issue
There are two solutions to this problem:

1. Move the edit and admin modes back to the website root. Move the edit and admin directories from the current location to the website root, or create virtual directory mappings, then update the web.config to reflect the new locations (EPsAdminDir and EPsEditDir). Make sure you also update the authentication sections to reflect the new paths also.
   
2. If you must have the modes in a sub-directory then you can also edit the aspx and ascx html directly (Note that these changes will probably be overwritten with an EPiServer upgrade). Update the relative paths in the html to reflect your site setup. Some of the items you will need to edit are (there may be others):
   • admin\Workflow.aspx
   • admin\WorkflowItem.aspx
   • Util\plugins\WorkflowLogView.ascx
   • Util\plugins\StartWorkflow.ascx
   • Util\plugins\ApprovalTask.ascx

In my language please

One thing I find EPiServer does really well is their multi-lingual interface. Basically all text used in the UI is stored in a number of XML files inside the website, each identified with a language code. With a standard installation you get a number of languages out of the box, one of which is English.

Today at work a colleague of mine was finding that the system dates being displayed were in American format and was wondering how to display them in our local format. He had selected "English" as his system default, but this didn't seem to make a difference.

With the default English selection, American formats will be used. Adding a local English option is not only easy but important for a number of reasons. Some of the functions in EPiServer depend on the system language selection. One is the display of regional options such as dates, and another is the language dictionary used for the spell checker.

The language selection list is built dynamically from the list of available languages found in the "lang" installation folder. This makes it quite easy to add your own languages to the list, simply by adding new language files.

For example, to add a New Zealand language option you could do the following:

1. Make a copy of "languageEN.xml" and call it "languageEN-NZ.xml"
2. Open the new xml file and edit the name and id attributes on the language node.
3. Set the name to "English NZ" and the id to "EN-NZ" (the id needs to match an official language code).
4. Set your system default language in admin mode or user preferred language in edit mode.
5. Optionally update the language files to your local spelling ;)
6. One last thing is to check any other language files in the "lang" folder, in case you need to add a language code to them too. One standard file is the "workflow.xml" which will require you to create a set of translations with your new language code.

This is one of the many reasons I really like working with the EPiServer product. Because of features like this you can give your end users a much better experience, without spending a lot of your own time customising.

How to crash Googlebot (and fix it)

If you have recently implemented an EPiServer 4.60 or 4.61 site and have found that Google is no longer indexing your site, then the problem may be with the friendly URLs and an underlying Microsoft.Net 2.0 issue.

A colleague of mine, Nick Urry recently came across this issue with a site he developed. He has written a great post on how to diagnose, reproduce, and most importantly, fix the issue. Nick's article can be found here.

Sorry if you thought this was some instructions on how to crash Googlebot, even though you can, why would you want to?