Category / SharePoint 2007

by Simon Doy

Unable to create a page based on a Publishing Page Layout


Introduction

This issue reared its head a few weeks ago. One of my clients has a pretty heavily customised Intranet which uses custom site definitions with feature stapling etc.

I have advised them to use separate site collections to help keep their site collections secure but with the main advantage being that they can use separate content databases for each site collection. This is to help ensure that they don’t get large 100Gb databases and issues with SQL Server locking.

Anyway, recently we started seeing an issue where the various contributors to the site (who were not site collection admins) could not create a page using the normal site settings->create page.

They had contribute rights but would get the error message:-

“The list does not exist”

 

Solution

So I started thinking about what the problem could be. The list does not exist message was being displayed before a page has been created and as soon as the user clicked Site Settings->Create a Page.

When you create a page you get a list of page layouts to choose from. So that brought me to checking that the master page gallery was there. I thought maybe someone had deleted the list or a feature had not been activated properly.

The list was there but no permissions were set, ah I thought that will be it.

I added the [Site Name] Members and [Site Name] Owners groups giving the Owners group Contributor permissions and the Members group Reader permissions.

The users could now create page successfully.

The reason that the problem was happening is that as part of the site collection creation process the content managers were being good and cleaning up the unused out of the box publishing SharePoint groups.

These groups include the following:-

  • Approvers
  • Designers
  • Hierarchy Managers
  • Quick Deploy Users
  • Restricted Readers
  • Style Resource Readers

However, this process was removing all the permissions from the master page gallery and hence any users who which were not site collection admins could not access the list.

The next step to this solution is write a Feature Receiver to clean up the SharePoint groups and clean up the permissions, this should help make things easier and ensure that users can start using the site as soon as its setup.

That will have to wait for a further blog post though.

by Simon Doy

SPListItem.Fields.Contains returns true when you don’t think it should!


Firstly, lets explain the scenario where this isn’t working.

Normally I would use the following code snippet to check that a field exists in an SPListItem object.
SPListItem.Fields.Contains([InternalFieldName])

This usually works really well, except in the following instance. The field is being checked to decide whether a User Interface element should be displayed.

The SPListItem is a content type derived from a Publishing Page Content Type. This content type lives in the /Pages document library along with various other content types.

The user interface element (button) should only display for content types that have a particular field. Unfortunately the button is always displayed as the field check function always return true regardless of the page being displayed.

It took me a while to work this through. Why would a field that is not associated to the page exist? My conclusion was that its because the field existed in the document library, albeit that it was part of another content type.

To workaround this issue, the code was changed from:-

SPContext.Current.ListItem.Fields.ContainsField([InternalFieldName]);

to:-

SPContext.Current.ListItem.ContentType.Fields.ContainsField([InternalFieldName]);

This call now returned false for pages which didn’t have the field associated to their content type. Finally, the user interface element was displayed as it should!