How to dynamically switch PageLayout and MasterPage of SharePoint Publishing page?

Question

To improve both the editing and displaying experience of SharePoint WCM Publishing pages I would like to be able to switch to a special set of Masterpage/PageLayout when in edit mode.

So in /_catalogs/masterpage I want to have:

MyMasterpage.master - masterpage for display mode MyMasterpage-edit.master - masterpage for edit mode, only use if available MyPageLayout.aspx - pagelayout for display mode MyPageLayout-edit.aspx - pagelayout for edit mode, only use if available

When I create a new publishing page in the Pages library, I select the MyPageLayout page layout.

When rendering the page I would like to detect if I'm in Edit of Display mode, just like the server control does. This control executes the following code to determine the render mode:

private void calculateShouldRender()
{
    SPControlMode contextualFormModeFromPostedForm = ConsoleUtilities.GetContextualFormModeFromPostedForm();
    if ((SPControlMode.Display == contextualFormModeFromPostedForm) && (PageDisplayMode.Display == this.PageDisplayMode))
    {
        this.shouldRender = true;
    }
    else if ((SPControlMode.Edit == contextualFormModeFromPostedForm) && (PageDisplayMode.Edit == this.PageDisplayMode))
    {
        this.shouldRender = true;
    }
    else
    {
        this.shouldRender = false;
    }
    this.Visible = this.shouldRender;
}

If the render mode is Edit, I want to switch to the MyMasterpage-edit.master materpage and the MyPageLayout-edit.aspx pagelayout.

I could make a big switch in the masterpage and pagelayout controlled by server controls, but I would like to split resposibilities. A SharePoint Analist can create optimal edit mode pages, and a front end developer can create clean and beautiful display mode pages without all the editing clutter.

Any ideas on how to accomplish this? Masterpage switching does not seem the problem, I once wrote a blogpost on this. The difficult thing seems the switching of the page layout.

Answer 1

I think you would be fighting SharePoint if you continue down that route, I fear it would also become something of a support nightmare as it becomes less clear where problems lie, or remembering to make changes in both (or all four!) places when something is updated.

You can have controls appear or hide depending on the editmode of a page so what is shown to the user is totally different but all the code for a page is still in one place.

Investigate the editmodepanel.

<publishingwebcontrols:editmodepanel ID="Editmodepanel1" runat="server">
   <link id="Link2" rel=Stylesheet href="<% $SPUrl:~sitecollection/EditMode.css %>" runat="server" type="text/css" />
</publishingwebcontrols:editmodepanel>

I realise that is not quite what you asked... but I find fighting SharePoint is a losing battle you just have to work with its 'way'.

Answer 2

My text was too long for the comment box, so I answer on Aiden as if it is an answer, but my question remains!

Hi Aidan, I see SharePoint as a platform where you can build your solutions on. And I think that the WCM solution built by Microsoft on top of the platform is weak. I know my way is not directly the SharePoint standard way, but the standard way just does not work. Combining edit and display mode leads to (pick your choice): - standard SharePoint publishing sites that all look alike but work ok in edit mode - a site that is very editable but very basic in its appearance - a great looking site in display mode, that is almost impossible to edit We have a lot of clashes between the stylesheets needed in display mode with the MOSS WCM stylesheet. We did write all kinds of compensating stylesheets to get it working, but it is a pain in the ***. It is a major flaw to inject code with styles in your page to make editing possible, this should have done completely outside the page you are editing. In an iframe for example which can be displayed as a floating window on top of the page you are editing. But this is not the case. And then I didn't even mention the issues you have when you have tabs or an accordion control on your page.

We are targeting really interactive web 2.0 sites where a lot of content management must be done. Getting editing mode right in the SharePoint way just does not work.

An optimal editing experience is key. So why not use the masterpage and pagelayout optimized for editing so all editable elements are reachable in a clear and consistent way. But then you still need the display mode. This could be done using a complete separate site that just uses the data produced in SharePoint. This can be an ASP.NET site, or if you want full control over the html MVC could be used. I don't at to go that way, because but has a lot of implications in navigation, security, reuse of controls, use of web parts etc.

I think you get best of both worlds if a masterpage/pagelayout is used that is optimized for editing, and another couple of masterpage/pagelayout is used for display only with a minimal set of code in the pagelayout.

So.. keep the answers coming please!

Answer 3

Surely that would require subclassing Microsoft.SharePoint.Publishing.PublishingLayoutPage and use that to render the contents of the actual PublishingLayoutPage required depending on the "edit mode".

How to get a master page changed...ek.

Answer 4

Trying to bend The SharePoint to your will again? ;)

I feel your pain. I'm using 2 ways to get similar behaviour:

A container control to condionally render parts of pages, I think like you suggested. Initially I needed it to hide parts of the page when some field had a specific value so no html was rendered. See wrapper controls. The control itself is very simple, it needs a [ParseChildren(false)] on its class and the render method does not call the base render if the condition is not met. You can extend this to display en entirely different page to an editor and designer although it would all still live in the same page. I guess you could strip out the part used by the analist and put it in its own usercontrol but thats not very maintainable.

Secondly, the form page, e.g. "/Pages/Forms/EditForm.aspx?ID=1", gives a clean view of all the fields on a publishing page.. no design to get in the way. (I use a control on all page layouts that provides 1 click access to this and the current pages library and shows the content type and page layout used. Quite useful when building WCM sites.)

Answer 5

I once wrote a feature to switch page-layouts depending on different criteria. The difference was, that the page-layout was changed during site-creation, not in view or edit mode. The code to change the page-layout is as follows:

    private void SetPageLayout(SPWeb web, string pageName, string pageLayoutName)
    {
        PageLayout layout = null;
        PublishingPage page = null;
        SPFile pageFile = null;
        bool checkedOut = false;

        try
        {
            PublishingWeb publishWeb = PublishingWeb.GetPublishingWeb(web);
            // verify that the requested pageLayout is available
            foreach (PageLayout pl in publishWeb.GetAvailablePageLayouts())
            {
                if (pl.Name.Equals(pageLayoutName, StringComparison.OrdinalIgnoreCase))
                {
                    layout = pl;
                    break;
                }
            }
            // got my layout
            if (layout != null)
            {
                page = null;
                foreach (PublishingPage pubPage in publishWeb.GetPublishingPages())
                {
                    if (pageName == pubPage.Name)
                    {
                        page = pubPage;
                        break;
                    }
                }
                // got my page
                if (page != null)
                {
                    pageFile = page.ListItem.File;

                    page.CheckOut();
                    checkedOut = true;

                    page.Layout = layout;
                    page.Update();

                    page.CheckIn("changed the page-layout to " + pageLayoutName);
                    checkedOut = false;

                    pageFile.Publish("");
                    // If required, approve the page
                    try
                    {
                        pageFile.Approve(string.Empty);
                    }
                    catch
                    {
                        // Page doesn't need to be approved
                    }
                }
            }
        }