Becky Bertram's Blog

I was creating a custom Site Definition for a Publishing site, and my Default page was based on a custom Content Type I had installed at the root of the Site Collection, which was based on the "Page" Content Type. The strangest thing happened, though, when I provisioned the new site, and tried to edit my Default page. Although all the editing fields showed up that were associated with the Page Content Type, none of the editing controls associated with the custom Content Type showed up on the page, even though they were clearly defined in the Default page markup, and in the Page Layout the Default page was associated with. This mystified me, until I discovered that, although my Default page was clearly associated with the custom Content Type in my onet.xml, that Content Type didn't get installed in the Pages Library when the site was provisioned. My Pages Library only had the default Content Types associated with it that are part of a base Publishing install: Article Page, Welcome Page, and Page. No custom Content Type. So, I needed to add the custom Content Type via code.

To do this, I created a new Feature, which consisted only a Feature Receiver which executed code when it was activated. I added a reference to the new Feature in my onet.xml schema, so that it would execute after the Publishing Feature executed. I thought, while I'm at it, why not delete the default Content Types as well? My code looked like this:


SPList pages = currentWeb.Lists["Pages"];
pages.ContentTypesEnabled = true;

SPContentType defaultPageContentType = currentWeb.Site.RootWeb.ContentTypes["MyCustomContentType"];
pages.ContentTypes.Add(defaultPageContentType );

pages.ContentTypes["Article Page"].Delete();
pages.ContentTypes["Welcome Page"].Delete();
pages.ContentTypes["Page"].Delete();

pages.Update();


As a side note, I initally tried to delete the Article Page and Welcome Page Content Types from the root site itself (instead of from the individual Page Libraries), but I discovered you cannot delete a Content Type that was created via a Feature, which in this case is the Publishing Infrastructure Feature.

I was at a client recently where I had created a Solution Package for bundling up a Feature that provisioned the Master Page, stlyles, Page Layouts, etc., for a Publishing Site, as well as a Site Definition that included homepages for each site.

The client started getting an error every time they tried to edit certain pages on the site. Whenever they added a web part to a page, or clicked up a button in the Content Editor Toolbar, they would be redirected to an error page that would tell them, "This page has been modified since you opened it." If they went back to the page and tried to edit it agian, they were able to make their changes.

There were several issues that seemed mysterious about this issue:
1.) I was not getting the error in my development environment and the client was getting the error in their environment.
2.) It only seemed to happen to several pages.

After much pain and aggrevation, we determined the error only happened when a user was editing a site's homepage. Furthermore, we discovered that the issue only seemed to happen on boxes which had SP1 installed. (My dev environemtn was a pre-built VPC and it didn't have SP1 installed, whereas the client had installed the service pack.)

After even more pain and aggrevation, we eventually realized that the issue was the Page directive. (Much like the issue in my previous blog entry!) I was operating under the assumption that the default page for a site would be identical to the Page Layout it was associated with. That being the case, the namespace I had applied to the default pages was this:
Microsoft.SharePoint.Publishing.PublishingLayoutPage
It turns out that the homepage for a site needs to have this as the Page directive needs to be this:
Microsoft.SharePoint.Publishing.TemplateRedirectionPage

Again, having the PublishingPageLayout namespace only seems to throw an error after SP1 has been installed.

One of the more complicated, and yet fundamental aspects of SharePoint is the concept of "customization" or "unghosting". When a page is not customized, it should refer to the definition that was installed on the file system in the 12 hive. That being said, when you do an stsadm -o upgradesolution command, and you update that definition on the file system, all the uncustomized pages on the site should pick up that change.

I was running into a mysterious circumstance where the changes were not being picked up in my Publishing Page Layouts. When I did an upgradesolution, I was finding that I needed to actually deactive, then reactive the feature that provisioned those Page Layouts into the Master Page Gallery at the site collection root. Futhermore, I ran into this confusing conundrum: if I set the "Ingore if already exists" property on your Module file element, it wasn't overwriting the older version of the Page Layout, yet if I set that value to true, it wouldn't install the feature because the Page Layout already existed in the Gallery. The second option was prohibitive because you can't delete a Page Layout that has pages based on it. What's a girl to do?

I knew the documentation said an upgradesoltuion command would only upgrade uncustomized items, since customized pages essentially have a copy of the original definition stored in the database. However, I had never modified my Page Layout using SharePoint Designer, and no one had even touched the page since it was provisioned, so it never occurred to me the page could be customized.

After hours of struggling with this issue, I started wondering about some rogue tags in my Page directive at the top of my Page Layout .aspx pages. They looked like this:

meta:webpartpageexpansion="full" meta:progid="SharePoint.WebPartPage.Document"

I have heard more times than I can count that you should never create Page Layouts in SharePoint Designer and then move the code to a Feature in Visual Studio, but dangit, it's an easy was to code. (I had removed the Robot control and thought that was enough.) It turns out, those directives are added by SharePoint Designer when a Page Layout is customized in SharePoint Designer. Futhermore, somehow, those tags instruct SharePoint to customize those Page Layouts. What that means is, although my Page Layouts from my Feature had been untouched by hunman hands (or SPD), it was still being customized the moment it was being provisioned in SharePoint. That's why my upgradesolution command wasn't working.

I just got back from TechReady, a week long training conference for Microsoft employees. This was the first year Microsoft put on a special event, just for women. Out of 5,000 attendees at the conference, just 450 were women. Although that number seems low, it's actually right about on par with other technology companies. Lately, Microsoft has been making an effort to increase the visibility of the women in its organization and their contributions. They have also started an event called "Digigirlz", which is aimed at exposing girls in grade-school to technology-related jobs. I personally believe having a balanced team of people, whether that means nationality, race, gender, etc., brings about the best solutions to problems, because it means different perspectives and ways of thinking are being brought to the table. I'm happy to see that Microsoft understands this.

Women at Microsoft
http://www.microsoft.com/about/diversity/programs/dac/wam.mspx
http://members.microsoft.com/careers/women/default.mspx

Digigirlz
http://www.microsoft.com/about/diversity/programs/digigirlz.mspx

Women in Research
http://research.microsoft.com/displayArticle.aspx?id=619

Women on Channel 9
http://channel9.msdn.com/shows/WM_IN

After five years of doing my own thing, I finally drank the kool-aid and joined Microsoft. I'm now working for Microsoft Consulting Services in the North Central District. After having worked with Microsoft CMS and SharePoint for 7 years, it's fun finally having access to the latest and greatest resources and people. Soon I'll be getting a new blog, however I'll try to keep the same Feedburner URL. Thanks to everyone who has responded to this blog over the last couple months. I'll continue to try to post "how to's" and other articles to get you going.