Category Archives: Publishing

Meta: Attributes in Page Layouts Provisioned by Features are Unghosted (Customized)

One of my clients was having an issue where solution upgrade or redeployment didn’t change certain page layouts. I checked the CustomizedPageStatus property of the affected layouts and it said they are customized. However, they had not actually been customized.

I activated the problem feature in another environment. Much to my surprise, the particular layouts indicated that they were customized immediately based on the provisioning for the module!

I didn’t see any difference between the couple of layouts that exhibited this behavior and the others in the same module that were appropriately uncustomized post provisioning. Also, I observed that on a stock publishing portal site with no customizations the same is true of VariationRootPageLayout.aspx.

I figured I couldn’t be the only one to have seen this behavior, so I asked the Internet and fellow MVP Rodrigo Pinto gave me the answer which I am blogging here in hopes that you’ll have better luck finding the answer with the search engine of your choice than I did!

The affected page layouts all contained meta: attributes from SharePoint Designer as shown in the following example.

 

<%@ Page					
language="C#"   Inherits="Microsoft.SharePoint.Publishing…"
meta:progid="SharePoint.WebPartPage.Document" meta:webpartpageexpansion="full" %>

The presence of these causes SharePoint to ‘unghost’ or customize the page upon the initial provisioning. The affect is exactly the same as if the page was manually modified or uploaded into the library – subsequent upgrades do not affect the version in the site. I removed these from each of the affected layouts and checked in the changes. Once we upgraded the solution were able to run a script to re-ghost (uncustomize) the affected layouts. The script used Gary Lapointe’s excellent extensions: http://blog.falchionconsulting.com/index.php/2007/09/re-ghosting-pages/

–Doug

Author: Doug Ware

Basic MOSS Publishing Site Definition

One reason I’ve been so busy lately is the creation of another course for AppDev. This one is all about Web Content Management and I developed it with my friend Matt Ranlett. It should be out in the next couple of months and I’ll post an outline soon and add it to my own courses page.

In the videos, I spend a lot of time covering the features that make up the MOSS publishing feature set and create a solid site definition that you can use as a basis for your own publishing sites. While I very much admire (and have personally benefited from) the work that Scot Hillier has contributed to the community, I think this slightly more complex site definition is a better place for most people to start. It includes the ViewFormPagesLockDown feature I discussed previously, but more importantly, (among other differences) it also initializes the versioning, approval, and navigation properties of the various features within the site definition and includes more comments.

As an aside, Andrew Connell wrote an interesting post a few months ago about the need for site definitions called ‘You don’t need to create site definitions‘. One thing he and a few of his commenters allude to is that publishing site definitions are a little different, but none of them really go into it. The important difference is that the publishing and navigation features have feature receivers that accept properties. You cannot specify property values when using feature receivers.

This is important in the BasicWCM site definition because it takes advantage of this key ability a site definition brings to the table. For example:

<!– Publishing –>

<!– The configuration below specifies a configuration

identical to SimplePublishing=true

To change other options, leave SimplePublishing set to false

and change the Value attribute as needed.

The Properties without values are read by the Publishing feature

receiver.

To specify a value, add the Value attribute–>

<Feature
ID="22A9EF51-737B-4ff2-9346-694633FE4416">

<Properties>

<Property
Key="SimplePublishing"
Value="false"/>

<Property
Key="WelcomePageUrl"
Value="Pages/Welcome.aspx" />

<Property
Key="AlternateCssUrl"
Value=""/>

<Property
Key="AvailablePageLayouts" />

<Property
Key="AvailableWebTemplates" />

<Property
Key="ChromeMasterUrl"
Value="~SiteCollection/_catalogs/masterpage/BasicWCM.master"/>

<Property
Key="PagesListUrl" />

<Property
Key="EnableApprovalWorkflowOnDocuments"
Value="false"/>

<Property
Key="EnableApprovalWorkflowOnImages"
Value="false"/>

<Property
Key="EnableApprovalWorkflowOnPages"
Value="false"/>

<Property
Key="EnableModerationOnDocuments"
Value="false"/>

<Property
Key="EnableModerationOnImages"
Value="false"/>

<Property
Key="EnableModerationOnPages"
Value="false"/>

<Property
Key="EnableSchedulingOnDocuments"
Value="false"/>

<Property
Key="EnableSchedulingOnImages"
Value="false"/>

<Property
Key="EnableSchedulingOnPages"
Value="false"/>

<Property
Key="RequireCheckoutOnDocuments"
Value="false"/>

<Property
Key="RequireCheckoutOnImages"
Value="false"/>

<Property
Key="RequireCheckoutOnPages"
Value="false"/>

<Property
Key="VersioningOnDocuments"
Value="Major"/>

<Property
Key="VersioningOnImages"
Value="Major"/>

<Property
Key="VersioningOnPages"
Value="Major"/>

</Properties>

</Feature>

You can access the CodePlex project here. You can also download everything from my downloads library.

Happy SharePointing…

–Doug

Author: Doug Ware

I see London, I see France… (Properly Securing Your Public Sites Part 2)

In my previous post, I talked about the ViewFormPagesLockDown feature. This removes the ViewFormsPages and UseRemoteAPIs permissions for guests across an entire site collection. This is a great thing if that’s what you intend to do, but occasionally you might want to do the same thing for a subset of your site. You could use code similar to that shown in the previous post using a single list instead of a site collection or you can do it using the user interface (an option not available for whole site collection scenario).

In SharePoint, a Permission Level is a named set of permissions. You can see the permission levels, by selecting Settings|Permission Levels on the Site Permissions page as shown below.

The MOSS publishing infrastructure features create a permission set named Restricted Read that allows users to view individual items, but denies them the ViewFormsPages permission. You can easily create your own permission to do the same thing. When you create the permission level, simply check View Items and SharePoint will take care of the rest.

Unfortunately, there is one big gotcha with this (using the browser – remember, you can set it with code) where anonymous access is concerned. To learn what it is, and one way to fix it, see this post.

I configured the Photos list on this blog using the View Items permission level.

You should see all the figures, but be unable to browse the photos list. If you click the link, you will see an Access Denied error.

I see London, I see France… (Properly Securing Your Public Sites Part 1)

Edit: Looks like Rich Finn was inspired to write the same post just a couple of days ago. He picked an even scarier search phrase that returned over 20k hits!

I see your site’s underpants!

Do you have a public facing SharePoint site that allows anonymous access? If you do, are you sure your anonymous users can’t step behind the curtains and browse your lists and libraries?

Just for fun, open your favorite search engine and search for "Items in this list contain HTML or text content which can be inserted into web pages".

Here is a screenshot of the results using Live search.

This screen shot proves two things.

  1. There are a lot of sites out there using the MOSS publishing infrastructure.
  2. The people who built the sites didn’t configure them properly.

(Fortunately I know it wasn’t any of us, right?) J

If your site is a collaboration site, you might not care if people can see the list form pages. In fact, you can see my form pages and I am happy because they show information that I want my visitors to see. On the other hand, if you have a publishing site that contains extensive and expensive branding, you probably don’t want your users to see the supporting list forms and you almost certainly don’t want the list forms showing up in people’s search results!

I am not sure why there are so many sites out there that have this specific problem. I know that sites based on the Minimal Publishing site definition exhibit the problem, but I can see that many of these sites are based on something else because they include the files deployed by the PublishingLayouts feature and this feature is not part of the minimal publishing site definition.

To fix this problem, all you have to do is activate a feature named ViewFormPagesLockDown. If your site is based on the built-in Publishing Portal or Collaboration Portal site definitions, it should already be active. If not, you’ll need to use the command line to activate ViewFormPagesLockDown.

Do so as follows:

stsadm –o activatefeature –name ViewFormPagesLockDown –url http://YourSiteHere.

This requires you to have MOSS because ViewFormPagesLockDown does not ship with WSS. However, you can easily write code to accomplish the same thing on any version of SharePoint based on WSS 3.0.

SPRoleDefinition roleDefinition = site.RootWeb.RoleDefinitions.GetByType(SPRoleType.Guest);
roleDefinition.BasePermissions &= ~(SPBasePermissions.EmptyMask | SPBasePermissions.ViewFormPages);
roleDefinition.BasePermissions &= ~SPBasePermissions.UseRemoteAPIs;
roleDefinition.Update();