Tuesday, September 26, 2006

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

Monday, September 25, 2006

Group notifications in workflow

So you've setup EPiServer workflow and it's all working well, except you can't get email notifications working when using groups in your workflow, why? Well, it's because EPiServer workflow doesn't send notifications to groups, and I'm not sure why not.

This is a feature I have wanted for quite a while now, in fact since my first EPiServer installation. I sent the usual request to EPiServer and it's on the feature request list, but I can't see them implementing this feature as they are moving to Windows WF sometime soon.

Anyway, I have created an HttpModule that enables this functionality. It doesn't require any changes to your workflow, and basically enables the email notifications for groups in a workflow. The module hooks up to the task changed event so when a new group task is created in a workflow, my module then sends the email notification to ALL users in the group (the same email that individuals get). It then stores a flag in the task state to stop it sending the email multiple times.

It currently only works for EPiServer groups, but I imagine it could be extended to work with LDAP and Local groups also (I'll be looking into this myself soon).

If your interested then leave a comment. If I get enough interest I'll see if my employer will let me release this code and I'll post again where it can be obtained from.

Thursday, September 21, 2006

EditX - Get it while it's hot!

A new version of EditX was released today by the EPiServer Research guys. If you haven't heard of EditX before, it is a new cross-browser edit mode for EPiServer that works in FireFox and IE.

The latest update includes the ability to preview before save, add internal links to pages in the editor (FCKeditor) and has a new tab for editing dynamic properties in the page edit screen.

Some of the features I like the best so far are usability enhancements more than anything. For example when you hover over the create new page option in the menu, a list of templates drops out for you to select, rather than having to load a new page listing the templates.

One big improvement is the implementation of the FCKeditor control. While it is not fully integrated into EPiServer, it now allows the selection of internal pages when inserting links and files. The standard editor in EPiServer is good, but just lacks the polish of the FCKeditor and has a number of issues to do with the HTML generated.

The module is not feature complete, but is at a stage where it is quite usable. Hopefully some of the stuff in this module will end up in a future version of the product. Here's a couple of screenshots, IE 7 vs FireFox.

EditX in IE 7
[EditX in IE 7]
EditX in FireFox
[EditX in FireFox 1.5]

So what are you waiting for? Why are you still reading this, go download it and have a play!

Wednesday, September 20, 2006

MondoSearch Integration Pack v2

Mondosoft logo

This week I got my hands on the tech preview of the new MondoSearch integration pack for EPiServer, and have got to say that I'm really liking the look of it so far. This new version provides much tighter integration with EPiServer and exposes a lot more MondoSearch functionality directly in the EPiServer UI.

The first thing you notice are the new MondoSearch and Behavior Tracking tabs in edit mode. The MondoSearch tab allows you to search over pages in edit mode, similar to the standard search box but is not limited to searching the page name and id fields. The Behavior Tracking tab is the best thing though, integrating some of the analytics and reports from Behavior Tracker directly into EPiServer.

There's some new functionality in admin mode too. From the admin mode tool plug-in you can configure the MondoSearch integration, start the crawler, view the log and check on its status.

To make all this possible three new web services have been created, MSService, BTService and IMService. These web services along with the existing SearchService provide the underlying infrastructure for the new integration pack. The web services use the same MQL query language that you may be familiar with if you have developed with MondoSearch before, for executing requests to a MondoSearch instance.

Anyway, it's looking great and is a much more flexible solution with the web service interfaces. It's currently slated for a mid October 2006 release so will look forward to that date, in the mean time I'll look give the tech preview a thorough work over and will post more about it here soon.

If you want a copy of the tech preview you will need to contact Mondosoft, I sent my request to sales@mondosoft.com.

Thursday, September 14, 2006

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.

Wednesday, September 13, 2006

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?

Monday, September 04, 2006

Advanced property development with Atlas

How many EPiServer sites have you built that don’t contain a custom property? For me, the answer is none! All EPiServer sites that I have built contain some sort of custom property, ranging from simple drop-down lists to more advanced dialog-based properties. The main reason I build custom properties is to make content editing simpler for the user, and also to integrate information from other systems.

One of the first projects I worked on had a requirement to provide editors with the ability to select a content owner through a series lists, populated from Active Directory. I figured I would meet this requirement by creating a custom property with a series of drop-down lists, which filter each other as selections are made – a common approach in web application development.

So, not having much experience with EPiServer properties, my first reaction was to apply the standard ASP.NET approach for this requirement: set AutoPostBack to true and filter the drop-down lists each time the selection changed. My first problem was that I tried to do the PostBack in the custom property – big mistake! There are two reasons not to do this, and it’s not because you can’t! Reason one is that the user will be asked if they are sure they want to navigate away from the page; this will confuse them. The second reason is that validation will occur and all incomplete required fields will fail validation, displaying errors to the user. Sound familiar to anyone?

After learning from this mistake, I decided to follow the standard EPiServer way of doing advanced properties, and implemented a popup dialog. This was great as it allowed me to meet the requirement using standard ASP.NET development techniques, and all I had to do was pass the resulting selection back to the property using JavaScript.

Now this approach is fine but, in my opinion, too many popup dialogs do not create a very good user experience. So, how do we create these advanced properties and not use popups? The answer: use AJAX and, to make things easier, use the Atlas framework.

For this article I decided I would re-create the content owner selection property, but using the Atlas framework and Atlas Control Toolkit. The content owner property consists of three drop-down lists for branch, business unit and content owner. When a branch is selected, the list of business units gets populated and enabled, and the same for business unit to content owner.

Now, would you believe me when I say that I only needed to write one line of JavaScript to get this working? No? Well I did, but all thanks to the Atlas Control Toolkit and the CascadingDropDown control. The CascadingDropDown uses the Atlas extender to provide AJAX functionality to the standard ASP.NET DropDownList. Through configuration properties the CascadingDropDown can be set to auto-populate from a web service, with the options filtered based on the selection from a dependent DropDownList.

Incorporating Atlas into your property is a fairly straight forward process. The first thing you will need to do is download the Atlas framework, and the Atlas Control Toolkit if you intend to use some of the pre-baked controls. The next thing you will need to do is set up your project. I tend to create my properties in separate projects so they can be easily reused and distributed (read this article by Steve Celius for more information on this). Here are the steps I followed to create my custom property with Atlas:
  1. Add a reference to the latest EPiServer.dll assembly (which needs to run under the .NET 2.0 framework).
  2. Add a reference to the Microsoft.Web.Atlas.dll assembly (which can be found at “C:\Program Files\Microsoft ASP.NET\Atlas\v2.0.50727\Atlas” in a default installation).
  3. Add a reference to the AtlasControlToolkit.dll and Microsoft.AtlasControlExtender.dll assemblies if you intend to use the pre-baked controls.
  4. Add a new Class to your project and set it up the same way you would for all custom properties (inherit from one of the base types, add the PageDefinitionTypePlugIn keyword and override CreateChildControls).
  5. In the CreateChildControls method, add your standard controls, add a ScriptManager, add an UpdatePanel, then add and configure your Atlas controls as appropriate.
  6. Create an ASP.NET web service with a single method that can be called by the Atlas client script. The method you create will depend on the controls you are using and the type of information being displayed.
  7. Build and deploy your assembly, web service and supporting assemblies.
  8. When you add your property to an EPiServer site you will need to add the necessary web.config settings. These can be found in the sample web.config file installed with Atlas (same location as the Atlas assembly location mentioned above).
So that’s it; it’s not that hard really, and is made a lot easier with the Atlas Control Toolkit. If you want to download my sample properties (dialog and Atlas versions), then download them directly from my Box.net account.

Tips and tricks

Always check for an existing ScriptManager as you can only have one registered on a page. When adding the ScriptManger, try something like this:
ScriptManager propertyScriptManager = ScriptManager.GetCurrent(container.Page);
if (propertyScriptManager == null)
{
propertyScriptManager = new ScriptManager();
container.Controls.Add(propertyScriptManager);
}


Don’t enable partial rendering on the ScriptManager as this will cause JavaScript errors such as, "return statement outside of function" or the classic message, "Unknown error".

Add runat="server" to the head tag on the EditPanel.aspx page as this is required by the Atlas framework. Be careful though, as this page is an EPiServer core page, and could get overwritten next time you update EPiServer.

Use a hidden HtmlInputText control to store the property value. This control will maintain its state on PostBack even when edited with client script. You may encounter issues when using other server controls not maintaining their values on PostBack.

Useful resources and links

ASP.NET Atlas official site
Atlas Control Toolkit samples
Sample properties download
EPiServer “edit in dialog property” code sample