WorkflowDesigner.aspx with your custom system masterpage – a better way

If you customised your system Master page and you work with Nintext workflows, I am pretty sure you came across the problem and description featured in this page:

3-step fix Nintex WorkflowDesigner.aspx with your custom system masterpage

Basically due to the customisations of the system masterpage the layout of the Nintext workflow designer might not render properly, sometimes making it impossible to create/edit workflows (my case).

Big kudos to the author for investigating this problem and coming up with solutions for it, but although they do work they are either hard or not supported by Nintex, in the author words:

Nintex has given me a stern wagging of their fingers and I need to tell you that Nintex does not support this modification. That’s why you need to keep the old Nintex file around and throw it back in if you need to talk to Nintex support.

Both solution revolve around on ways to replace the masterpage with the standard v4 masterpage just for the workflow designer.

The solutions suggested pointed me in the right direction, what I propose to solve this problem is to implement a module deployed as a webapplication feature that intercepts the request, checks if the page requested is WorkflowDesigner.aspx and replaces with the standard v4 Masterpage.

Here is the implementation:

public class MasterReplaceModule : IHttpModule
        public void Init(HttpApplication context)
            context.PreRequestHandlerExecute += context_PreRequestHandlerExecute;

        void context_PreRequestHandlerExecute(object sender, EventArgs e)
            Page page = HttpContext.Current.CurrentHandler as Page;
            if (page != null)
                page.PreInit += page_PreInit;

        void page_PreInit(object sender, EventArgs e)
            Page page = sender as Page;
            if (page != null && System.IO.Path.GetFileName(page.Request.PhysicalPath) == "WorkflowDesigner.aspx")
                page.MasterPageFile = "../v4.master";

        public void Dispose()


If you are not familiar on what is the best way to implement a module in a sharepoint solution, you can either manually edit the webconfig by hand to include the module (very big no no!!!), or you can use SPWebConfigModification to do it.

You can call SPWebConfigModifications from a feature event receiver FeatureActivated event, which will inject the necessary xml in the web.config for you. Dont forget to remove it on FeatureDeactivating.

here is an example of a SPWebConfigModifications object wich injects a module declaration (IIS7):

var moduleModification = new SPWebConfigModification()
                Owner = "ApplicationName",
                Name = "add[@name='MyAwesomeModule']",
                Type = SPWebConfigModification.SPWebConfigModificationType.EnsureChildNode,
                Path = "configuration/system.webServer/modules",
                Sequence = 1,
                // The XML to insert as child node, make sure that used names match the Name selector
                Value ="<add name='MyAwesomeModule' type='FullNameSpace.MasterReplaceModule , AssemblyName, Version=, Culture=neutral, PublicKeyToken=7be6bd052a28e02f' />"

If you need help on how to apply the above in a feature receiver check this article:

Using SPWebConfigModification within a Feature Receiver