Microsoft SharePoint Products and Technologies Administrators Pocket Consultant

The SharePoint Server publishing feature includes a default set of page layouts for authoring news articles. These layouts incorporate the built-in field controls, which are arranged in different configurations on the page. Each field control is in turn bound to specific metadata fields of the Article Page content type. Field controls enable page authors to enter metadata values in a WYSIWYG fashion while at the same time displaying the authored metadata values to users when the page is viewed.

Working with Master Pages and Page Layouts

You can extend the publishing framework by providing your own content types, page layouts, master pages, and field controls. Master pages typically contain navigation, logos, search box, login control, editing controls, CSS references, and other server controls. The easiest way to create a new master page is to open an existing master page using SharePoint Designer 2007 and then save it to the file system. Once you've made the desired customizations, you can then upload it to the master page gallery of a top-level site, or you can package it into a Feature for deployment to multiple sites.

Because each page layout depends on the columns that are defined in its associated content type, it is helpful while planning your extensions to consider them as a unit. This is easy to see when you examine how the Article Page content type works in conjunction with the corresponding set of page layouts. Each layout is responsible for presenting the same set of columns in different ways, but the underlying column metadata are the same.

To create a page layout, you must have a content type to base it on. In addition, the content type you select must be derived from the Page content type provided by the publishing feature. The Page content type provides the foundation set of metadata fields used by various components of the publishing framework. Although you can use any of the built-in publishing content types, such as Article Page, you typically want to create your own. You can do so easily via the SharePoint user interface as follows:

  1. Browse to the Site Settings page of the top-level site in your site collection. Creating your content type in the top-level site ensures that it will be available to all publishing sites you create.

  2. Click the Site Content Types link in the Galleries section. The Site Content Type Gallery page is displayed. Click the Create button at the top of the page.

  3. From the New Content Type page, enter the content type name and then select Publishing Content Types from the list of parent content types you want to base your new content type on. To reference your content type from a publishing page layout, you must base it on one of the content types in this group.

  4. Click the OK button to save the content type. The new content type appears in the list on the Site Content Type Gallery page.

The next step is to add or create the columns you want to display in your publishing pages. If you want to use the standard set of field controls, such as the HTMLEdit and ImageEdit field controls, in your page layout, then you must include one or more of the publishing site columns in your content type. Depending on the parent content type you selected, some of these columns may already be included. Table 10-2 shows the primary field controls and the site columns on which they depend.

Table 10-2: Publishing Field Controls and Corresponding Field Types

Open table as spreadsheet

Control

Site Column Field Type

RichHtmlField

HtmlField

RichImageField

ImageField

RichImageSelector

ImageField

RichLinkField

LinkField

RichLinkSelector

LinkField

SummaryLinkFieldControl

SummaryLinkField

With the content type defined, you can use SharePoint Designer 2007 to create a page layout that can be used to display document metadata.

Creating a Page Layout in SharePoint Designer 2007

  1. Start the SharePoint Designer 2007 application, and open the top-level site for your site collection.

  2. Browse to _catalogs\masterpage. This is the master page gallery that holds all master pages and page layouts for the site collection.

  3. Right-click on the master page gallery and select New > SharePoint Content… from the context menu. A dialog box opens.

  4. On the left side of the SharePoint Content tab, select SharePoint Publishing and then select Page Layout in the middle list box. The resulting dialog box is illustrated in Figure 10-8.

  5. On the right side of the dialog box, select which content type to base the new page layout on. The drop-down list only shows content types that are derived from the Page content type provided by the publishing feature. Select the content type you created above.

  6. Enter the URL Name of the new page layout: for example, tutorial_page.aspx.

  7. Enter a Title for the new page layout: for example, Tutorial Page.

  8. Click OK to close the dialog box.

Figure 10-8: Select New > SharePoint Content > SharePoint Publishing in SharePoint Designer 2007.

The new page layout now appears in the master page gallery of the top-level site in a pending state awaiting approval. Once it is checked in and approved for publication, it can be selected when creating a new publishing page.

Note 

It is possible to create a page layout while editing a subsite. The steps are the same. However, when the page layout is saved, it does not appear in the master page gallery of the subsite. SharePoint Designer always saves the file into the master page gallery of the top-level site in which the subsite is contained. The publishing master page gallery is implemented as a standard Windows SharePoint Server document library, thereby exposing the same functionality as any other document library, including approval workflow, check-in, check-out, and versioning.

Deploying Page Layouts

Although it is convenient to use SharePoint Designer 2007 to design page layouts, it is impractical to use it to deploy them. Typically a publishing solution incorporates many layouts that are all tied to a common set of content types and master pages. It is necessary in most cases to deploy those layouts as a unit, rather than one at a time. In a typical scenario, you will want the added flexibility of being able to deploy the same set of publishing resources to multiple sites and site collections. You can deploy a set of publishing solution files using the file provisioning capabilities of the SharePoint feature framework. To deploy a page layout using this method, perform the following steps:

  1. Browse to the %SystemDrive%\Program Files\Common Files\Microsoft Shared\Web Server Extensions\12\TEMPLATE\FEATURES folder on the SharePoint Server machine.

  2. Create a subfolder to hold your feature definition files. The name you choose for the subfolder is the same name you use to refer to the feature in subsequent steps: for example, MyFeature.

  3. Open SharePoint Designer 2007 and go to the _catalogs/masterpage node for the top-level site containing the page layout you wish to deploy.

  4. Right-click the page layout file and then choose New From Existing Page from the context menu. A copy of the page appears in SharePoint Designer. Select File > Save As to save the file into the folder you just created. Give it the same name as the original file.

  5. Open Notepad and enter the following XML code, replacing the Id value with a unique identifier obtained by running the GuidGen command-line utility.

    <?xml version="1.0" encoding=" utf-8"?> <Feature Title=""Page Layout Deployment Feature" Description="Provisions a Page Layout" Version="1.0.0.0" Scope="Site" Hidden="TRUE" DefaultResourceFile="core" xmlns="http://schemas.microsoft.com/sharepoint/"> <ElementManifests> <ElementManifest Location="ProvisionedFiles.xml" /> </ElementManifests> </Feature>

    Note 

    The GuidGen command-line utility is typically located in the %systemdrive%\Program Files\Microsoft Visual Studio 8\Common7\Tools folder. If Visual Studio is not installed and this program is unavailable, you can use the following VB script to generate a unique ID. Copy this code to a file with a .vbs extension-for example, makeguid.vbs-and execute it from a command prompt using Wscript.exe.

    guid = left(createobject("scriptlet.typelib").guid,38) inputbox "GUID Generator",,guid

  6. Save the file into the custom feature folder using the special name Feature.xml.

  7. Close and reopen Notepad. Enter the following XML code, replacing the underlined text with the appropriate text for the custom page layout file you created previously.

    <?xml version="1.0" encoding="utf-8"?> <Elements xmlns="http://schemas.microsoft.com/sharepoint/"> <Module Name="TutorialLayout" Url="_catalogs/masterpage" Path="" RootWebOnly="TRUE"> <File Url="tutorial_page.aspx" Type="GhostableInLibrary"> <Property Name="Title" Value="Tutorial Layout Page"/> <Property Name="MasterPageDescription" Value="This is a description of the tutorial layout page."/> <Property Name="ContentType" Value="$Resources:cmscore,contenttype_pagelayout_name;" /> <Property Name="PublishingAssociatedContentType" Value=";#Tutorial Page; #0x010100C568DB52D9D0A14D9B2FDCC96666E9F2007948130EC3DB0 64584E219954237AF39003CCC5B461C57904E96DF6ACA7EBA3B38;#"/> </File> </Module> </Elements>

    Note 

    The PublishingAssociatedContentType property is required and must be in the format given. This property is what links the page layout to its underlying content type for the publishing feature. Replace the content type name (Tutorial Page in the above example) with the actual name of the content type you want to associate with your page layout. You must also replace the identifier with the actual content type identifier, and be sure to include the trailing semi-colon. To locate this value, go to the Site Content Type Gallery of the top-level site, find the content type in the list, and click its hyperlink. The content type identifier then appears in the address bar of the browser just after the ?ctype= URL parameter.

  8. Save the file using the name ProvisionedFiles.xml.

  9. Open a command prompt and enter the following command, replacing MyFeature with the name of the subfolder you created in step 2.

    stsadm -o installfeature -name MyFeature

When the feature is installed, the custom page layout is copied into the master page gallery, along with any additional modules and files you may wish to add to the list of module declarations in the ProvisionedFiles.xml.

Customizing the Authoring Experience

With SharePoint Server, you can customize the interfaces that your site designers will use. You can customize the Page Editing Toolbar, the HTML Editor, and the Asset Picker.

Customizing the Page Editing Toolbar

The Page Editing Toolbar appears at the top of a publishing page and contains a set of user interface controls that are displayed for page authors. Figure 10-9 shows the default Page Editing Toolbar for an Article Page. The Page Editing Toolbar consists of the following components:

Figure 10-9: The Page Editing Toolbar.

You can customize the authoring experience by editing the XML data files used by the Page Editing Menu and the Quick Access Button Panel. Typically, you would use this approach to add buttons or quick access commands to the toolbar, but you can also remove items from the default controls by taking advantage of the order in which the XML data files are loaded.

The Page Editing Menu commands and quick access buttons are handled in the same way as the Site Actions menu that appears at the top of most SharePoint Web pages. Each control is initialized from <ConsoleNode> elements declared in an XML definition file. The Page Editing Menu commands are loaded from the EditingMenu.xml file, and the Quick Access Button Panel is loaded from the QuickAccess.xml file. Both of these files are located in the %SystemDrive%\Program Files\Common Files\Microsoft Shared\Web Server Extensions\12\TEMPLATE\LAYOUTS\EditingMenu folder.

During the loading process, the control code looks for an optional secondary XML configuration file that contains custom <ConsoleNode> elements. If that file exists, then the custom <ConsoleNode> elements are loaded into the control. Any elements in the secondary XML configuration file that have the same ID as a corresponding node in the primary configuration file take precedence over the element that was read previously. In this manner, you can hide or change the default commands to suit specific requirements.

The secondary XML configuration files have specific names: CustomEditingMenu.xml and CustomQuickAccess.xml, respectively. Thus, to customize the Page Editing Menu, make a copy of the EditingMenu.xml file and rename it CustomEditingMenu.xml. Similarly, to customize the Quick Access Button Panel, make a copy of the QuickAccess.xml file and rename it CustomQuickAccess.xml.

Customizing the HTML Editor Field Control

The HTML Editor field control is one of the most important tools for authoring Web pages, and is the one control found on most page layouts. Authors use this control to enter content directly into publishing pages in WYSIWYG fashion. Depending on how the control is configured, authors can edit the HTML source and browse for reusable content fragments from a centralized repository.

Using Constraints

Table 10-3 lists the attributes you can use to control the behavior of the HTML Editor field control. These attributes must be set individually for each instance of the control you wish to configure. This means that you must first locate the associated markup within each page layout file and then add or remove the appropriate attributes

Table 10-3: HTML Editing Constraint Attributes

Open table as spreadsheet

Attribute

Description

AllowExternalUrls

If false, then only URLs internal to the current site collection are allowed to be referenced in a link or an image

AllowFonts

Determines whether content may contain <Font> tags

AllowReusableContent

Determines whether content may contain reusable content fragments stored in a centralized list

AllowHeadings

Determines whether content may contain HTML heading tags

AllowHyperlinks

Determines whether content may contain links to other URLs

AllowImages

Determines whether content may contain images

AllowLists

Determines whether content may contain ordered or unordered lists

AllowTables

Determines whether content may contain table-related tags such as <table>, <th>, <tr>, and <td>

AllowTextMarkup

Determines whether content may contain bold, italic, and underlined text

AllowHTMLSourceEditing

If false, then the HTML editor does not switch to HTML source editing mode

DisableBasicFormattingButtons

If true, then the basic formatting buttons are disabled

Using Custom Styles

You can use custom CSS stylesheets to control the presentation of content on publishing pages. You do this by configuring each individual instance of the HTML Editor field control to look for a specific set of custom styles in the stylesheets associated with the page layout. When the HTML Editor field control is configured in this way, content authors can select from the list of predefined custom styles and apply them to content without typing HTML and CSS code.

If the HTML Editor detects new CSS classes whose names have the special prefix ms-rteCustom-XXXX, where XXXX is the display name of the custom classes, it displays the custom classes instead of the default classes installed with the system. In addition, each custom style can be defined specifically for certain types of content. The HTML Editor displays the custom classes to the user only if the specified type of content is selected. For example, to define a custom CSS class for bulleted lists, you can add code similar to the following to the CSS stylesheet associated with the page layout:

UL.ms-rteCustom-ArialSmallCapsList { font-family:Arial; font-size:8pt; text-transform:small-caps; }

Because the same CSS stylesheet is shared among all instances of the HTML Editor, you can configure each instance to look for a specific subset of styles. You do this by using the PrefixStyleSheet attribute. The default prefix is ms-rte. Using the PrefixStyleSheet attribute you can specify your own custom prefix. For example, the following declaration sets the prefix to MyCustomPrefix:

<PublishingWebControls:RichHtmlField FieldName="PublishingPageContent" runat="server" PrefixStyleSheet="MyCustomPrefix"/>

This instance of the HTML Editor now finds and displays the following styles whenever the user selects a bulleted list:

UL.MyCustomPrefix-ArialMaroonList { font-family:Arial; color:maroon; } UL.MyCustomPrefix-VerdanaBlueList { font-family:Verdana; color:blue; }

The styles are displayed as ArialMaroonList and VerdanaBlueList.

Customizing the Asset Picker

The Asset Picker is a popup HTML dialog box that allows authors to locate references to list items in the current site collection. It is used most often when the author of a Web page needs to insert the URL of an image contained in a picture library or of a separate page contained in a document library. Without the Asset Picker tool, the author would have to browse from the page he or she is working on to copy and paste the required URL reference. In addition to the inconvenience of copying and pasting, the author might be more likely to make a mistake while copying the link or may reference a file located in an untrusted location, thereby causing potential authentication problems for users who view the resulting page. Figure 10-10 shows an example of the Asset Picker that is used by several of the publishing field controls for selecting images and documents. The Look In pane on the left side of the picker window provides shortcuts to a predefined set of SharePoint libraries in the current site collection. You can extend this set of shortcuts to include one additional location within your site collection for individual field controls in separate page layout files. This feature might be useful if your page authors frequently reference resources that are located somewhere other than the default locations.

Figure 10-10: The Asset Picker is used by several of the publishing field controls for selecting images and documents.

Note that there are several limitations to using this approach: (1) You must directly edit the markup for existing page layouts. This means that your customizations might be overwritten if those layouts are updated. (2) You can only specify one additional location for images and one location for documents. (3) You must repeat the customization for every field control in which you wish to display the additional location. (4) You must use the same relative location in every site collection in your SharePoint Server Farm.

There are eight page layouts included as part of the Web Content Management (WCM) feature set provided with SharePoint Server. They are located in the %SystemDrive%\Program Files\Common Files\Microsoft Shared\Web Server Extensions\12\TEMPLATE\FEATURES\PublishingLayouts\PageLayouts folder on the file system and are displayed in the master page gallery for the site. You can add a custom picker shortcut for any of the RichHtmlField or RichImageField controls found in any of these files by performing the following steps:

  1. Open the site in SharePoint Designer, browse to the _catalogs/masterpage folder, select a page layout, and open the file for editing.

  2. Locate the control you wish to extend. The publishing field controls are indicated by <Publishing WebControls:RichHtmlField> or <PublishingWebControls:RichImageField> tags.

  3. Add a DefaultAssetLocation attribute to define the URL for the custom shortcut in a URL picker.

  4. Add a DefaultAssetImageLocation attribute to define the URL for the custom shortcut in an image picker.

  5. Save and close the .aspx file.

The URL references you use must be relative to the same site collection. For example, if you have a picture library in your site collection called Company Pictures, you might customize the image picker for an Article Page layout as follows:

<PublishingWebControls:RichImageField FieldName="PublishingPageImage" runat="server" DefaultAssetImageLocation="/Company Pictures"/>

Note 

If the specified URL reference cannot be resolved, then the Asset Picker inserts a shortcut that displays all of the top-level folders in the current site collection. If the URL refers to any location external to the current site collection, then the additional shortcut is ignored.

Converting Documents into Web Pages

The Web Content Management features of SharePoint Server allow you to convert documents of any type into Web pages that can be published to SharePoint sites and then updated automatically when the source document is modified. This is a powerful feature because it lets users write content using the applications they are familiar with instead of having to learn how to edit HTML files. SharePoint Server includes built-in converters for the following file types associated with the 2007 Office System: DOCX to HTML, DOCM to HTML, XSN to HTML, and XML to HTML. The XML converter enables you to supply a custom XSLT stylesheet that can convert your custom XML file into HTML. There is no PowerPoint converter.

To use the document-to-page conversion framework, you start by enabling document conversions at the Web application level. You do this from the Central Administration Web site.

Enabling Document Conversions for a Web Application

To enable document conversions for a web application, follow these steps:

  1. From the Central Administration Web site, go to the Operations tab and click the Services on Server link and verify that the Document Conversions Load Balancer Service and the Document Conversions Launcher Service are running.

  2. From the Application Management tab, click the Document Conversions link in the External Service Connections section.

After enabling the document conversions, you can start a conversion manually, or you can set up an asynchronous timer job that invokes the conversion on a schedule that you specify.

Configuring a Document Converter

Document converters are configured using converter definition files, which are XML files based on the Document Converter Definition schema. You add a custom converter to the SharePoint configuration database by packaging the XML definition in a feature. When the feature is activated, the converter is available on each site and document library in the Web application. The following example shows the converter definition file for a custom document converter that converts Office Excel (.xls) files to Office Word (.doc) files.

<?xml version="1.0" encoding="utf-8" ?> <Elements xmlns="http://schemas.microsoft.com/sharepoint/"> <DocumentConverter Name="Excel to Word" App="XL2WORD.exe" From="xls" To="doc" ConverterUIPage="XL2WORD.aspx" ConverterSpecificSettingsUI="XL2WORDConfig.aspx" ConverterSettingsForContentType="XL2WORDConfig.ascx" /> </Elements>

When the document conversion process is started, SharePoint Server passes the document to be converted along with an XML file containing converter-specific settings to the Document Conversions Load Balancer Service. This service determines how and where the specified document converter should be launched, depending on the current server farm configuration. The Load Balancer Service then calls the Document Conversion Launcher Service to invoke the specified document converter. You can control which settings are available for a given document converter by supplying a custom configuration settings page that is used to gather conversion settings from the user. To specify a custom settings page, set the ConverterSpecificSettingsUI attribute to the file name of the custom .aspx file you want to use. You can also use the default page (DocTrans.aspx), but then substitute your own custom control to retrieve converter-specific settings by setting the ConverterSettingsForContentType attribute to the file name of a custom .ascx file.

Категории