Up to now, all sites and subsites you have created are based on the same type of site; the only difference between them is the site template used when you created the site. With SharePoint 2007, you can use Master Pages for customizing the look and feel of the site, and there is seldom a need to change the actual code that is the base definition of a site. This was not the case in SharePoint 2003; almost all changes, besides the modifications you could do with just a web client, required that you customize the site definition files. Still today there may be a need to create a customized site definition with, for example, a specific set of list settings, layout, and color. One way of doing these customizations is to use SharePoint Designer, but by doing so, you will "unghost" the site. This requires some explanation: When you create a WSS site, all its content is stored in content database in your SQL server, but the code that rules how the site looks and how it behaves is stored in the file system of the SharePoint server, or to be more specific in this folder:
C:Program FilesCommon FilesMicrosoft Sharedweb server extensions12TEMPLATESiteTemplatessts
So if you have 100 WSS sites, all of them will use the files in this "sts" folder, but they will display different content. These are known as "ghosted" sites, that is, they look like they are a part of the content database, along with the actual site content, but they are not. If you modify one of these sites with SharePoint Designer, then SharePoint must store the complete site definition and the content in the database; thus, the site is "unghosted," and any modifications of the files in the "sts" folder will no longer affect this particular site. So if you modify all 100 of these sites with SharePoint Designer, then you will have 100 unghosted sites. This will have some consequences:
Performance: It takes longer time for SharePoint to read an unghosted site, since all the files plus the content are stored in the SQL Server database.
Disk requirements: Storing 100 site definitions files instead of using one shared site definition will require more disk space.
Flexibility: If you want to modify all unghosted sites, then you must change all of them, one by one, but modifying 100 ghosted sites is very easy: just change the common set of site definition files.
These consequences may at first look like a very serious problem that may prohibit you from using SharePoint Designer, but in reality it is not a problem in most installations. The performance decrease will only be visible in larger installations, you will not see any noticeable difference in a SharePoint installation with less than 5,000 to 10,000 users. The increased disk requirements will also be barely noticeable, unless you have thousands of unghosted sites. The last consequence, flexibility, will only be a problem if you need to modify a lot of sites after they are created, and this modification is not something you can do with a Master Page file. So most of the time, unghosting a site is a theoretical problem, not a practical one.
NOTE
If you want to revert an unghosted to a ghosted site, open the Site Settings for the site and select "Reset to site definition."
Still, there are situations when you want to avoid unghosting — the solution is then to create your own site definition. This required a lot of work in previous versions of SharePoint, but now it is a rather easy task, depending on what modifications you want to make. You have two options for changing a site definition, while still retaining a ghosted site:
Create new definition files: Either you start from scratch and create these files one by one, or you copy an existing site definition and modify it.
Copy a site definition and change it in Visual Studio 2005: If you are a .NET developer, you may instead copy an existing site definition, and modify it, then create a new site definition.
In the example below you will use the first method, that is, create a new site definition by copying an existing site definition. If you want to use the Visual Studio 2005 method, then look at msdn.microsoft.com for more information.
NOTE
Open this URL to find another good description of how to build a site definition using Visual Studio:
http://weblogs.asp.net/soever/archive/2006/11/11/SharePoint- Solution-Generator-_2D00_-part-1_3A00_-create-a-site-definition- from-an-existing-site.aspx.
In the following example you will create a site definition with two extra Web Part zones for all WSS 3.0 sites. By default, all WSS team sites (i.e., not Meeting or Document Workspaces, nor blog or Wiki sites), have two Web Part zones: Left Zone and Right Zone. In this example you will add a Top Zone and a Bottom Zone as well; both span the complete page width. Just follow the steps in the Try It Out below.
Try It Out: Create a WSS Site Definition
|
This was a very simple modification, and you can do a lot more with this site definition, for example:
Modify the default lists and libraries on the web site: Change the stsdemoxmlonet.xml file.
Modify the default Web Parts displayed on the site: Change the stsdemoxmlonet.xml file.
Modify the two standard Web Part zones: By default the Left Zone is configured to use 70 percent of the page width, and the Right Zone, 30 percent; change that by editing the stsdemodefault.aspx file.
Since this is a custom site definition, it will not be overwritten by any service pack that you may apply later on the SharePoint server. You own this site definition, and you take the responsibility for it; make sure to make a backup of it. If you have multiple SharePoint servers running as web servers (i.e., accept incoming users connections to SharePoint sites), then make sure that all of them have the same set of modifications.
3.145.184.113