In this exercise, you will save the subsite you created in a previous exercise as a site template.
1. If your SPD Demo site isn’t already open, open it in SPD 2010.
2. Select the first item from the Site Objects list on the left side of the SPD interface.
This displays the Site Summary page.
3. On the Site tab in the ribbon, click the Save as Template button. This opens your SharePoint subsite in a browser and takes you to the Save as Template page.
4. Provide a name, such as SPDdemo, for the WSP file in the File name field.
5. Type a display name, such as SPD Demo Template, for the template in the Template name field. You can also provide an optional longer description in the Template description field.
6. Select the Include Content check box to include the content of the site in the site template file. Remember that your template file can be only 50MB maximum.
7. Click OK to save the template to the site collection solutions gallery.
8. To download the solution from the solution gallery, click the user solution gallery link. You can then upload the solution to your SharePoint Online site and activate it to use the template when creating new subsites.
Branding
One of the most common uses for SPD 2010 is implementing a consistent look and feel for your sites.
This is commonly known as branding. As we’ve already seen, there are several areas where you can adjust the branding of your site using the UI. You can change the site logo or modify the color scheme and fonts by applying a theme. But what if you want to do more than change logos or modify the color scheme? What if you want to move things around, add a footer to the page, or replace the existing navigation? These kinds of tasks require modifying master pages, publishing page layouts, or overriding existing Cascading Style Sheets (CSS). To accomplish these kinds of tasks, you’ll need direct access to the HTML or CSS code of the page. Although you could do this by downloading copies of these files, SPD provides a more convenient what you see is what you get (WYSIWYG) editor. Using SPD you can see the results of your edits immediately, making complex editing tasks easier.
Note By default, only SharePoint Online administrators can create or edit master pages and page layouts.
But these kinds of branding tasks aren’t for everybody, so by default only SharePoint Online administrators can create or edit master pages and page layouts. As discussed in the “Managing Security” section in this chapter, you can also turn off everyone’s ability to edit either master pages or any other page. These controls make it easy to limit when these kinds of branding changes can be made and by whom. Most organizations will work to get their branding in place for the top-level site of a site collection before it’s made available to regular users and then lock it down. You can then re-enable editing of these features if changes need to be made in the future. You can also just lock down these features in your SharePoint online environment and prototype all your branding changes in an on- premise environment using SPD. Then package the files in the on-premise environment using a Visual Studio 2010 sandboxed solution (WSP), features, and event receivers to apply the changes in the SharePoint Online environment.
Changing Fonts and Colors with a Theme
In Chapter 4, you learned how to change the default theme of a site to apply a unified color scheme and set of fonts. SharePoint Designer 2010 can also be used to change the default theme used by a site collection. But SPD doesn’t add anything to this capability. The Change site theme link on the Site Summary page merely redirects user to the same browser-based page described in Chapter 4.
Note See Chapter 4 for additional information about using themes.
Editing Pages
Using SPD 2010, you can create or customize standard web part pages, publish page layouts, and edit master pages. SharePoint WIKI pages can be created only in the UI, but they can be edited in SPD.
Although each page type serves a different purpose, the page editing experience is essentially the same.
Using SPD, you can edit the contents of a page either in a WYSIWYG view or by working directly with the
HTML code. You can also use SPD to change the master pages a site uses or designate a different default home page. The result is a site that is completely customized with your organization’s unique look and feel.
Note Application pages (pages with URLs containing /_layouts/) reside in the SharePoint farm’s physical file system and cannot be edited in SPD.
Normal and Advanced Edit Modes
When you open a page for editing in SPD, it will default to the normal edit mode. When using this editing mode, you will be prevented from making any changes that would detach the page from its default site definition. Using the normal edit mode, you are essentially limited to doing the same things that you can do in the browser. For example, you can add web parts to a web part zone, but you can’t add them directly to the page or add a new web part zone.
To really customize your site, you’ll need to use the advanced edit mode. This editing mode gives you full access to change any HTML on the page and will always result in a customized page that is stored in the content database. Customized pages can present challenges when updates or service packs are applied because they are detached from the site definition and won’t be updated if the site definition page is updated.
Creating Publishing Layout Pages
If the publishing infrastructure site-collection feature and the publishing site feature have both been enabled in your top-level site, you can make use of publishing layout pages. These pages impose the same layout on multiple pages by dynamically loading a set of metadata into a layout template when rendering the page. Where a master page is used to standardize things like the header, navigation, and footer of multiple pages, a publishing page layout provides control over the look and feel associated with the main content section of a page.
When creating a new publishing page, a user will be prompted to choose from a predetermined list of available page layouts. Content is then added to the page by filling in controls on the page layout. The content is then saved as metadata attached to the page. HTML in the publishing page itself is not rendered. Instead, the metadata attached to the page is used to fill in the associated page layout and the HTML in the page layout is rendered. Because rendering of a publishing page layout is dependent on the metadata attached to the publishing page, the publishing page layout must know what metadata fields are available. This is done by connecting each publishing page layout to a specific content type. The content type defines the potential metadata fields available for display. The metadata fields available in a content type are defined through the use of site columns. So to create a new publishing page layout, you might need to create one or more site columns, a content type, and a publishing page layout. You can do all these tasks using SPD.
Embedding Client-Side Code
As you’ll see later in the book, the limitations imposed on deployment of server-side managed code assemblies make the use of client-side code an essential work-around in many cases. One of the easiest ways to deploy client-side code is to simply embed it into a master page or ASPX page with a Hypertext
Markup Language (HTML) <script> block. You can use the advanced edit mode in SPD to edit the HTML of a page directly and add client-side code to the page. You can also embed client-side code on the page by adding it to a Content Editor web part. Adding it in a web part can be done without requiring that the page be in advanced edit mode.
Note Chapter 9 discusses the use of client-side code in more detail.