Thanks Microsoft: We Got Publishing Features Enabled

Those of you who know me realize that I can be a grouchy, cantankerous old cuss.:)

It seemed wrong to use a picture of myself, so I stole this from

It seemed wrong to use a picture of myself, so I stole this from

But every once in a while, I have a good experience that I really should share so that people don’t think I can only be grumpy.

Today is one of those days. But it’s a bit plus and minus.

I’ve had a support ticket open with Microsoft for exactly a month today about an Office 365 tenant where we couldn’t activate the Site Feature for SharePoint Server Publishing.


It was originally activated (we can’t track down the history), but wasn’t fully “there”. Some of the capabilities weren’t working. So I deactivated it and tried to reactivate. Every time, the dreaded “An unexpected error has occurred.” But a correlation ID!

I’ll admit it, I’m not enamored of Microsoft support. My experience over the years has been spotty at best and this case was not a good showing. We bounced back and forth to various people “out there”. (It’s the cloud, so it doesn’t matter where they are, right?)

When we hit a month to the day today, I decided I would highlight the – erm – challenges here to Adam Harmetz (@AdamHarmetz ) at Microsoft. I’m very careful how I use my connections at Microsoft, as I don’t want to be “that guy”. Sometimes I’m “that guy”, but I try not to be. Really, I do. Truly. Most of the time.

Well, within two hours, we had the problem solved. (Adam wasn’t awake when I sent the email.) I worked with two stellar guys at Premiere Support who *really* knew their stuff.

In the words from the follow up email from the engineer I worked with:

We found that the publishing feature was failing to create the PageNotFoundError page in the Pages library, so after validating that the page layout and content types were in good shape we grabbed a healthy page from a new publishing site, moved it over to the target site, and verified that the publishing web feature was able to be activated without a hitch.

Note that I’m not giving out the two stellar guys’ names. I don’t want them to be inundated with requests! But I know who they are.

So why does all this matter? Frankly, it doesn’t matter that much that I pulled some strings and got my problem solved. We had been working around it and would have solved it eventually through normal channels.

What really matters is the fact that Adam and Stellar Guy No. 1 are going to take this case and try to make things better with it. The way it all played out is a bad user experience. Yes, UX isn’t just something on a computer screen. Every aspect of our interactions with Microsoft affects our perception of the company and its products.

These days, Microsoft can take something like this and make changes to ensure they don’t happen again. A few years ago, I would have openly complained about the fact that they weren’t a learning organization; today they are, and a fast-learning one at that.

That doesn’t mean that my next support experience – or yours – is going to be perfect. But it does mean that it might be a bit better. I long for the day when there will be no need at all to pull strings to reach a good conclusion, and I want to help Microsoft get there.

Determine if a SharePoint Publishing Page Is in Design Mode (Edit Mode) with Script

Today I was working on some script for the home page of a SharePoint 2013 site which added the jQueryUI accordion behaviour to all of the Web Parts within a Web Part Zone. When I went into edit mode, it was pretty frustrating to have the accorsdions kick in, so I looked around for a way to check to see if a publishing page is in editing mode with script. I’m pretty syure I’ve done this before, but it’s been a while and I couldn’t find anything in my kit.

Somewhat to my surprise, there were a lot of questions about how to do this out there, but not a lot of good answers. Most of them came down to looking for some element that would only be in the page in edit mode and sounded a little kludgy.

However, I found one over at SharePoint Stack Exchange from Andrey Markeev in a thread called How do I know if the page is in Edit Mode from JavaScript? that looks pretty solid to me.

I’m taking the liberty of including the code here, since this is the first place I look for answers!

var inDesignMode = document.forms[MSOWebPartPageFormName].MSOLayout_InDesignMode.value;

if (inDesignMode == "1")
    // page is in edit mode
    // page is in browse mode

This will refer to value of the following html input control, which is rendering on the page when it is in edit mode:

For wiki pages, you will need the _wikiPageMode parameter:

var wikiInEditMode = document.forms[MSOWebPartPageFormName]._wikiPageMode.value;

if (wikiInEditMode == "Edit")
    // wiki page is in edit mode
    // wiki page is not in edit mode

Editing Pages Based on Page Layouts When You Don’t Have Access to the Page Layouts Themselves

Page layouts are great functionality that comes along with the Publishing Infrastructure in MOSS.  They allow you to enforce a consistent structure and even consistent content in pages which you allow your users to create.

However, sometimes (due to the powers that be), you may have access to a site with pages based on page layouts with SharePoint Designer, but not the page layouts themselves.  (The page layouts, are stored in the root web in the Master Page Gallery, along with the master pages, in the  /_catalogs/masterpage folder.)  When you try to edit one of these pages, you are informed that:


Each page in the Webs (sites) that you have access to which utilizes the Publishing Infrastructure will be based on one of those page layouts.  You can’t edit the page layouts if you don’t have permissions on the root site.  Q.E.D.

However, if you right click on the page in the Folder List, you should see an option to Detach from Page Layout.  You’ll see this dialog pop up:


Assuming that you really want to do it, go ahead and say ‘Yes’.


Later you can Reattach to Page Layout, but frankly I haven’t needed to do this.  I’ve read that you can do it with impunity and then you have your customized page with it linked to the page layout again.  Changes that you’ve made to Web Parts in Web Part Zones will stay in effect but any other changes will be overwritten by the page layout.  The dialogs then look like this:


and then:


However, you don’t have to reattach it.  It will just mean that the page won’t reflect any changes to the page layout it was associated with in the future.  Assuming this is OK, you’re good to go, but make sure that you document this choice, as it may become important later.

Saving SharePoint Publishing Sites as Templates

This is a little trick, but a useful one all the same.  When you use the Publishing Site template for a site, you do not have the option in Site Settings to save the site as a template for reuse.  There are probably good reasons for this due to the underlying structure of Publishing Sites, but no one has ever been able to explain it to me in any detail.

The trick is to append _layouts/savetmpl.aspx to the URL of your site.  So, for example, if your site is at http://servername/site, you would use the URL http://servername/site/_layouts/savetmpl.aspx.  On the Save as Template screen, you’ll probably want to check the ‘Include content’ box so that the .aspx pages in the Pages library are included.

Be careful with this, but as long as you haven’t done anything fancy in your site, it ought to work just fine.  The template that you save will be available when you create a new site under the PublishingSiteTemplate tab.