It's been a long time

It's been far too long since I last wrote something here and sorry to disappoint but this is not going to be of much interest to most of you.

Over the last few months now I have been travelling through the USA and have arrived in London, looking for work and a place to live. I've been having a great time with my partner Anna, and have uploaded a few pics of our travels to my Picassa web album.

Anyway, as I said I'm looking for work in London, hint, hint. So if you know of any work around at the moment, contract or permanent I would greatly appreciate any leads. Also, if anyone in London wants to catch up over a beer then that would be great! Just flick me an email at episervernz at gmail dot com or my regular email if you happen to know it. [Update: I have a job now, thanks]

Take care and more to come soon no doubt as EPiServer CMS comes out!

Off to Australia

Well I'm finishing at my current job at Intergen at the end of this week and I'm off on my OE!

Before I get started though I'm going to be working in Australia for a few weeks, providing consulting and development in Melbourne. If your working with EPiServer in Melbourne and want to have a chat sometime then send me an email at episervernz@gmail.com.

After Australia I will be back in NZ for a while, then heading off on my OE. I'll be visiting the coasts of the USA and ending up in London sometime in May. Watch this space for more information later!

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"

I want to share, I really do

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 as a Wiki

Lately I have been doing some research into Wiki tools and am finding lots of great tools that have strengths in some areas, but always seem to lack other important features, one of which is WYSIWYG editing!

We use a Wiki tool at my work that is okay, but is really quite slow (file based storage), has a rubbish search and with most tools, has a text editor. So I'm on the hunt for a better tool with the following functionality:

1. C# .NET 2.0 with source code
2. SQL Server database storage
3. Windows authentication
4. WYSIWYG editing
5. Version history
6. Search

I found this great tool last week called ScrewTurn which supports most of these requirements, but as with most Wiki's, still lacks the WYSIWYG editing (it is listed in the product roadmap though). Another thing it lacks is Windows authentication, but I think this could easily be developed using the new plugin framework they provide in version 2 (still in beta).

So this has got me thinking, how easy would it be to implement a Wiki using EPiServer? EPiServer supports all of these functions (minus the source code but not a big deal considering the ODA), but is not really designed for Wiki type functionality.

I would be keen to hear from anyone who has tried to implement EPiServer as a Wiki or has thought about doing this themselves. What difficulties did you have? What sort of user experience did you try to provide (editing in edit mode, or editing on page)? Any other thoughts or ideas would be appreciated. Also, are there any other tools you have used that I might have missed?

Leave a comment or email me at jerms55 [at] gmail [dot] com.

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.