Wednesday, February 23, 2011
Understanding Scope of a Feature
Courtesy/Reference/Credits:
SharePoint Features can be scoped to the Farm, Web Application, Site Collection, and Web Site level depending on the purpose of the feature. The Feature scope is determined by the setting of the Scope attribute in the Feature element defined in the feature.xml file.
A sample Feature element tag is given below:
Web Site scoped Feature (Scope="Web"):
A Web Site scoped Feature is one that can be activated only at the individual Web site level. List templates, list instances, custom actions, event receivers, etc are the some common elements for web site scoped features. Web Site scoped features can be activated by using one of the following two methods:
Site Collection scoped Feature (Scope="Site"):
A Site Collection scoped Feature is one that can be activated at the site collection level and contains items that apply to the site collection as a whole (for example, content types that are shared across the site collection), as well as items that can be activated per site (for example, list instances, etc). Site Collection scoped features can be activated by using one of the following two methods:
Web Application scoped Feature (Scope="WebApplication"):
A Web Application scoped Feature is one that can be activated at the web application level and contains items like administrative web application links, delegate control registrations, feature/site template association, document form registrations, etc. A farm Feature can contain, for example, links to /_layouts pages and files, /_admin pages, and other elements. Web Applicationscoped features can be activated by using one of the following two methods:
Farm scoped Feature (Scope="Farm"):
A Farm scoped Feature can be activated at the server farm level. A farm Feature contains a number of elements that are critical for implementing applications and logic anywhere within a deployment. A farm Feature can contain, for example, links to /_layouts pages and files, /_admin pages, and other elements. Farm scoped features can be activated by using one of the following two methods:
SharePoint Element Types for Features:
The following table describes various element types for Features and shows their possible settings for scope.
SharePoint Features can be scoped to the Farm, Web Application, Site Collection, and Web Site level depending on the purpose of the feature. The Feature scope is determined by the setting of the Scope attribute in the Feature element defined in the feature.xml file.
A sample Feature element tag is given below:
<Feature Id="F62C96CF-79FD-44be-8882-E9BFBD199184"
Title="Feature Title"
Description="Feature Description"
Version="1.0.0.0"
Scope="Site"
Hidden="false">
</Feature>
Web Site scoped Feature (Scope="Web"):
A Web Site scoped Feature is one that can be activated only at the individual Web site level. List templates, list instances, custom actions, event receivers, etc are the some common elements for web site scoped features. Web Site scoped features can be activated by using one of the following two methods:
- Run the following STSADM command:
stsadm -o installfeature -name FeatureFolderName –url http://servername/site/subsite
- Open the Site Features page in the SharePoint site (Site Actions -> Site Settings -> Modify All Site Settings -> Site Features) and click the Activate button.
Site Collection scoped Feature (Scope="Site"):
A Site Collection scoped Feature is one that can be activated at the site collection level and contains items that apply to the site collection as a whole (for example, content types that are shared across the site collection), as well as items that can be activated per site (for example, list instances, etc). Site Collection scoped features can be activated by using one of the following two methods:
- Run the following STSADM command:
stsadm -o installfeature -name FeatureFolderName –url http://servername/site/sitecollection
- Open the Site Features page in the SharePoint site (Site Actions -> Site Settings -> Modify All Site Settings -> Site Collection Features) and click the Activate button.
Web Application scoped Feature (Scope="WebApplication"):
A Web Application scoped Feature is one that can be activated at the web application level and contains items like administrative web application links, delegate control registrations, feature/site template association, document form registrations, etc. A farm Feature can contain, for example, links to /_layouts pages and files, /_admin pages, and other elements. Web Applicationscoped features can be activated by using one of the following two methods:
- Run the following STSADM command:
stsadm -o installfeature -name FeatureFolderName -url http://servername
- Open the "Manage Web Application Features" page in the Central Admin application (SharePoint Central Administration -> Application Management -> Manage Web Application Features) and click the Activate button.
Farm scoped Feature (Scope="Farm"):
A Farm scoped Feature can be activated at the server farm level. A farm Feature contains a number of elements that are critical for implementing applications and logic anywhere within a deployment. A farm Feature can contain, for example, links to /_layouts pages and files, /_admin pages, and other elements. Farm scoped features can be activated by using one of the following two methods:
- Run the following STSADM command:
stsadm -o installfeature -name FeatureFolderName
- Open the "Manage Farm Features" page in the Central Admin application (SharePoint Central Administration -> Operations -> Manage Farm Features) and click the Activate button.
SharePoint Element Types for Features:
The following table describes various element types for Features and shows their possible settings for scope.
| Element | Description | Scope |
| Content Type | Contains a schema definition you can reuse and apply to multiple list definitions. | Site |
| Content Type Binding | Content type binding enables you to provision a content type on a list defined in the Onet.xml schema. Lists defined in the Onet.xml schema cannot be modified directly. | Site |
| Control | A delegate control contains a registration for a well-known control installed on a Web page. This lets you replace existing controls, such as the Windows SharePoint Services search control, with another control. | Farm, WebApplication, Site, Web |
| Custom Action | You can define the following kinds of custom actions: · Content type links for the content type settings page · Drop-down menu actions for the drop-down menu that appears for an item · Form toolbar buttons for New, Edit, or Display form toolbars. · Site Settings link for the Site Settings page. | Farm, WebApplication, Site, Web |
| Custom Action Group | Defines a group of custom actions. | Farm, WebApplication, Site, Web |
| Document Converter | Contains the definition of a document converter. A document converter is a custom executable file that takes a document of one file type, and generates a copy of that file in another file type. | WebApplication |
| Feature/Site Template Association | Binds a Feature to a site definition configuration so that created sites are provisioned with the Feature. | Farm, WebApplication, Site |
| Field | Contains a field definition that can be reused among multiple lists. | Site |
| Hide Custom Action | Hides a custom action that has been added through another custom action. | Farm, WebApplication, Site, Web |
| List Instance | Provisions a SharePoint site with a specific list of data. | Site, Web |
| List Template | Contains a list definition or template, which defines a list that can be provisioned in a SharePoint site. | Site, Web |
| Module | Contains a set of files with which to provision sites. | Site, Web |
| Receiver | Contains an item event receiver registration. | Web |
| Workflow | Contains the definition for a workflow in a list. | Site |
Understanding Features
Features are mainly used for deployments of Site Columns, Content Types, Web Parts etc.
Features can be deployed at the following scopes:
They reduce the complexity of customizations in SharePoint site.
Location: C:\Program Files/Common Files/Microsoft Shared/Web Server Extensions/12
Each feature must contain one manifest file name Feature.xml which defines the high level attributes of the feature such as Title, Description, Scope etc. The feature can contain any number of supporting files such as aspx, css etc.
Courtesy/Reference/Credits:
Features can be deployed at the following scopes:
- Farm
- Web Application
- Site Collection
- Web (Site)
They reduce the complexity of customizations in SharePoint site.
Location: C:\Program Files/Common Files/Microsoft Shared/Web Server Extensions/12
Each feature must contain one manifest file name Feature.xml which defines the high level attributes of the feature such as Title, Description, Scope etc. The feature can contain any number of supporting files such as aspx, css etc.
In an Onet.xml file, the Feature element is used within a site definition configuration to contain a reference to a Feature instance and default property values. The Configuration element specifies lists and modules to use when creating SharePoint sites. For information about the format and elements used in site definitions, see Site Schema.
SharePoint Foundation activates Features specified within the Onet.xml file in the order that they are listed. Consequently, you must specify Features that are depended upon before Features that depend upon them.
SharePoint Foundation activates Features specified within the Onet.xml file in the order that they are listed. Consequently, you must specify Features that are depended upon before Features that depend upon them.
Courtesy/Reference/Credits:
BLOB Cache
BLOB Cache or Binary Large Objects caches stores frequently used large objects such as images, audio's etc that are accessed every time a site loads.
It's a disk based cache
First time a BLOB file is requested, it is fetched from the DB and stored in the BLOB cache. Thereafter, it is accessed from the cache only. Thereby minimizing the traffic.
Flushing a BLOB Cache: Flushing of the BLOB cache can be done for a web application in cases such as restoring the content DB where in the content DB and the cache go out of sync.
Flushing the BLOB cache will have an effect on the entire web application that include all the site collections present in the wep app.
It can be done only thru powershell or object model
Procedure is provided in the link referenced below.
To enable blob caching you need to modify only one line in the web.config file:
<BlobCache location="C:\blobCache" path="\.(gif|jpg|png|css|js)$" maxSize="10" enabled="false"/>
Just change the false in the enabled attribute to true and update the location attribute to point to a location where sufficient disk space is available. For best performance ensure to set the maxSize attribute to a value that is at least as big as all binary objects in your Web Application.
You can control which file types are cached by modifying the file extension list in the path attribute.
Responsible for the processing of the disk caching logic is the following entry in HttpModules section of the web.config file:
<add name="PublishingHttpModule" type="Microsoft.SharePoint.Publishing.PublishingHttpModule, Microsoft.SharePoint.Publishing, Version=12.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c" />
This HttpModule implements the required logic that decides whether a file can be served from the disk cache or if it has to be retrieved from the backend database.
Important to know is that even that this HttpModule is located in the WCM Publishing namespace you its functionality is not limited to publishing sites. Other site collection types like team sites can also use this functionality.
Limitations of Blob Caching
1) Blob caching does not support web gardening
One major limitation is that blob caching should not be used with web gardening. The reason is that each process requires exclusive access to it's instance of the blob cache. That means that only one worker process can access a single instance of the blob cache. Web Gardening means that multiple worker processes serve content for the same application pool. Only the first process of a web garden will then benefit from blob caching which would mean that web gardening would cause negative impact on the overall performance.
2) Blob caching cannot be used with host named site collections
The blob caching engine uses the server relative path to decide if an item in the cache belongs to a URL or not. With host named site collections an additional criteria come into play: the "host" http header. The blob cache engine on the other hand is not aware about host named site collections. That means if you have two site collections with items that have the same server relative URL (e.g. items in the style library) but are different the item that was first hit gets cached and served for all other host named site collections as well.
3) A cached item is only available in one frontend server
The blob cache is a per server cache. That means if an item has been cached on server 1 and the next request for the same item hits server 2 then the item has to downloaded again to the second frontend server. That means the load on a SQL backend server can be higher in the startup phase if multiple frontend servers exist as the same item might have to be downloaded multiple times to the different frontend servers.
Courtesy/Reference/Credits:
It's a disk based cache
First time a BLOB file is requested, it is fetched from the DB and stored in the BLOB cache. Thereafter, it is accessed from the cache only. Thereby minimizing the traffic.
Flushing a BLOB Cache: Flushing of the BLOB cache can be done for a web application in cases such as restoring the content DB where in the content DB and the cache go out of sync.
Flushing the BLOB cache will have an effect on the entire web application that include all the site collections present in the wep app.
It can be done only thru powershell or object model
Procedure is provided in the link referenced below.
To enable blob caching you need to modify only one line in the web.config file:
<BlobCache location="C:\blobCache" path="\.(gif|jpg|png|css|js)$" maxSize="10" enabled="false"/>
Just change the false in the enabled attribute to true and update the location attribute to point to a location where sufficient disk space is available. For best performance ensure to set the maxSize attribute to a value that is at least as big as all binary objects in your Web Application.
You can control which file types are cached by modifying the file extension list in the path attribute.
Responsible for the processing of the disk caching logic is the following entry in HttpModules section of the web.config file:
<add name="PublishingHttpModule" type="Microsoft.SharePoint.Publishing.PublishingHttpModule, Microsoft.SharePoint.Publishing, Version=12.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c" />
This HttpModule implements the required logic that decides whether a file can be served from the disk cache or if it has to be retrieved from the backend database.
Important to know is that even that this HttpModule is located in the WCM Publishing namespace you its functionality is not limited to publishing sites. Other site collection types like team sites can also use this functionality.
Limitations of Blob Caching
1) Blob caching does not support web gardening
One major limitation is that blob caching should not be used with web gardening. The reason is that each process requires exclusive access to it's instance of the blob cache. That means that only one worker process can access a single instance of the blob cache. Web Gardening means that multiple worker processes serve content for the same application pool. Only the first process of a web garden will then benefit from blob caching which would mean that web gardening would cause negative impact on the overall performance.
2) Blob caching cannot be used with host named site collections
The blob caching engine uses the server relative path to decide if an item in the cache belongs to a URL or not. With host named site collections an additional criteria come into play: the "host" http header. The blob cache engine on the other hand is not aware about host named site collections. That means if you have two site collections with items that have the same server relative URL (e.g. items in the style library) but are different the item that was first hit gets cached and served for all other host named site collections as well.
3) A cached item is only available in one frontend server
The blob cache is a per server cache. That means if an item has been cached on server 1 and the next request for the same item hits server 2 then the item has to downloaded again to the second frontend server. That means the load on a SQL backend server can be higher in the startup phase if multiple frontend servers exist as the same item might have to be downloaded multiple times to the different frontend servers.
Courtesy/Reference/Credits:
Tuesday, February 22, 2011
Understanding various ways of Site Provisioning in SharePoint 2010
Introduction
As you might know, there are multiple different techniques for provisioning new sites in SharePoint. SharePoint deployments always consist from at least one site, which provides functionalities for the end users. There’s multiple ways to create these sites and to customize them based on customer requirements. In this blog post we concentrate models, which support strict versioning model. Meaning that the sites are not built directly to production environment using SharePoint Designer or browser rather deployed using solution packages.
Before we get started, let’s first concentrate on getting the terms right. There’s multiple different terms used when we reference definitions, which are used for creating new sites. Here’s the clarification on the most used one’s and how they should be used.
Site Template
Why is the provisioning model such an important thing? – since overall usage models in SharePoint, especially for larger companies, are not just based on individual web parts, which are used to bring additional value over the out of the box site structures. In larger project, the productivity of the individual end users and the editors plays role for designing correct model, since we want to have as good and consistent user experience provided through out the farm.
Let’s have a real life example of one global intranet, which had 50 part time content editors and more than 700 sites in site hierarchy for each of the country sites. There’s 10 different site types, which should provide the same functionality where ever they are located. Since there’s quite a lot of content to be created and managed, it’s better to create specific templates compared to use feature stapling and browser customizations. You can only image the time spend modifying each site using browser and even though there would be documented instructions, most likely most of the sites would look little bit different than other. By providing 10 configured web templates, which will have all templates and web parts as defined by corporate communication, intranet will have consistent user experience and content editors can easily extend the sites as required.
Key point on the site provisioning is to automate something which would be done manually by site authors. Business case can be calculated quite easily from the amount time required for each site to be configured based on the company guidance. There doesn’t have to be that many sites created, before the investment for customization is worthwhile.
I’ve been still seeing demos and real production environment where the end users or content authors are forced for example to active features manually in certain order to configure the site as planned. This should not be the case, since it also increase risks of breaking up the sites by for example activating accidently wrong features.
Other consideration is obviously the implications due the customizations. Certain options available can cause implications on maintenance and upgrade processes, which will impact on the overall costs included in the deployment. Luckily in SharePoint 2010, we now have the new Web Template option, which will help to address these issues.
So key advantage of automating the site provisioning to save time and ensure consistent end users experience throughout the particular deployment. This is not only important for WCM sites, but also for other site types to provide consistency.
Different site provisioning methods in SharePoint 2010
There is four or five different main models for site provisioning in SharePoint 2010, depending what’s considered as individual models.
•Feature stapling
•Site templates
•Web Templates
•Site definitions
•Provisioning provides
•Custom code (mainly for automated processes)
We’ll cover each of the options in high level to consider the different advantages and disadvantages in each of them, except the full custom code option, which obviously can be anything. These options will concentrate on different ways to control what’s provisioned when end users uses the out of the box Create functionality.
Feature stapling
Primary purpose of the feature stapling is to extend and customize existing site definitions. Usually these are used to provide some custom functionalities for the out of the box site definitions, but technique is definitely available also for the custom site definitions.
Since it’s not supported to change the onet.xml file of site definitions after it has been used in environment, feature stapling is quite commonly used also to provide versioning for the already deployed custom site definitions. You can modify the stapling definitions to different site definitions also afterwards. It’s important to remember that stapled features are only activated on provisioning time, so if there’s any existing sites already provisioned, those won’t be affected automatically just by deploying new stapling definitions.
Biggest downside with the feature stapling is that we can only extend the existing site definitions, we can’t provide new. This can be an issue for example when you’d like to have WCM templates created for multiple different site purposes. Also the fact that stapled features are activated before the module element or list elements in onet.xml file has been provisioned, can cause issues unless you use some workarounds. Notice also that feature stapling is only supported when site definitions are used, it doesn’t work if you are provisioning sites using site templates or web templates, even though these both options refers to root site definition.
Site templates
As you might know SharePoint 2010 has changed the functionality used for saving existing sites as template. In 2007 version when site was saved as a template, specific STP file was created, which could not be modified in anyway. In 2010, when we save site as template, SharePoint generates full fledge solution package (WSP file), which can then be moved between any environment containing all site level objects, like libraries and optionally also content.
There are two key improvements in feature framework scheme, which have made this possible. These are WebTemplate element and CustomSchema attribute for ListInstance elements. These two options will make it possible to provision sites using alternative xml definitions, but then refer back to out of the box templates. Key point is that we use alternative definitions during provisioning, but all object references will be associated to out of the box types.
One of the biggest downsides with the site templates is the fact that they are not supported when publishing features are enabled. This is also the reason why we hide the link from the site settings page to avoid anyone to use this functionality. Obviously if you know the aspx page name, you can access the page and save the site as a template also when publishing features are enabled. This is however not supported. What does that mean? – just because you can… doesn’t mean you shouldn’t. Publishing sites have complex references and dependencies, which have to be carefully defined even for site definitions. This is not supported (and link is hidden) so that inexperienced users wouldn’t break intentionally their deployments.
One of the consideration with the site templates is also the fact that unless you import them to Visual Studio and modify its settings, they are only available on site collection level (site collection scoped feature), which means that to be able to have the template available from multiple locations, we’ll have to either deploy the site template as sandbox solution to multiple site collections or deploy it as full trust solution and then activate the particular feature in site collections to have the template available.
Web Templates
We’ll concentrate more detailed on the Web templates in later chapters, but basically with the web templates in this case, we refer to manually created WebTemplate elements in the Visual Studio. We need to create two files for each of the web templates. Other one is empty element (is VS2010 is used) for defining the actual WebTemplate element and other one is completely similar onet.xml file as for site definitions, with few exceptions, which we’ll cover little bit later.
When we have our web template created, we’ll associate the element file to feature, which will be responsible of deploying the web template. WebTemplate element is supported in two scopes, which are Farm and Site. This means that we can deploy the web templates to be available either throughout the farm or based on site collection scoped feature activation. It’s important to notice that dispute the fact that we’d be using site collection scoped feature for deployment, we can still deploy the web template using farm scoped feature. This would for example give us possibility to filter the options available from the Create site functionality, based on feature activation status.
One big advantage of the web templates is the fact that since they are feature based and there won’t be any files stored in file system, those are completely supported usually by the cloud services, like MS Online (BPOS). Support obviously varies based on the cloud service types, like in MS Online case, if the service is dedicated or standard. These usually mean for example differences on the support for full trusted solutions or only sandbox solutions.
One really important advantage with the web templates compared to the site templates is the fact that we can utilize the publishing features in web templates. This provides us possibility to create new site provisioning options to be available from the Create site functionality, even though we would be creating new publishing feature based sites.
Site definitions
Site definitions are the classic xml files, which are for example used to provision out of the box sites. Many of the developers learned to create these in 2007 version, since they are very powerful and there were almost no other options available for introducing new options for the Create site functionality. As mentioned earlier site definition consists basically from two different files: WebTemp*.xml and onet.xml files.WebTemp*.xml defines how the site definition is visible for the end users and the onet.xml file contains the definitions for the actual site provisioning.
We can only deploy site definitions using farm solutions, since files will be located in the file system. They are also by default available throughout the farm in every application, unless we limit the visibility either using AvailableWebTemplates attribute for publishing sites or more generally available VisibilityFeatureDepency attribute in the WebTemp*.xml file. Since we won’t be concentrating on site definitions in this blog article, I won’t be covering these options more detailed.
Key change in the site definitions for the 2010 version is that if you have site collection scoped feature associated to site definitions under the SiteFeatures elements, those features are not activated, if you create sub sites. In 2007, also these site collection features where activated also for sub sites. This could be an issue when for example you want to add new Events site under corporate intranet and you’d like also for example content types to be created, when site is provisioned. There are workarounds for this, which are declared later in the web template creation chapters (same workaround applies for site definitions).
Whenever we create site based on any site definitions SharePoint stores the site definition identifier information to SPWeb.WebTemplate, SPWeb.Configuration and SPWeb.WebTemplateId properties. These are critical properties in the SharePoint platform, which have to be set for each of the sites. Let’s come back to this in following chapters with detailed web template information.
Biggest challenge with the site definition is that we are not allowed to change the onet.xml file after it has been used to provision any sites in the environment. This is just not supported. There are certain scenarios, which don’t impact the existing sites and it might seem that update didn’t cause any issues, but just because it didn’t hurt the first time, should you do it again? – no. This is one of the classical rules of SharePoint development, like the fact that don’t touch the databases directly.
Already in 2007 version there was numerous approaches to go around the fact that onet.xml file should not be updated. Most classic one, is the so called “minimal site definition approach”, where we all possible customizations to features, which don't’ have to be activated in certain order. Let’s not spend too much time on this, but generally out of the box site definitions are actually quite awful examples for custom site definitions (quick summary).
Due these upgradability issues and SLA commitments with the customers, site definitions are NOT supported usually by the cloud services, like in MS Online. It would be simply foolish to impact on the service quality by allowing site definitions to be used, especially since we have at least as good options available in SharePoint 2010, which don’t compromise the service in short or long term.
How to Create a Custom Site Definition and Configuration
Beautiful step by step explanation:
http://msdn.microsoft.com/en-us/library/ms454677.aspx
Just to add a small point to that:
http://msdn.microsoft.com/en-us/library/ms454677.aspx
Just to add a small point to that:
In an Onet.xml file, the Feature element is used within a site definition configuration to contain a reference to a Feature instance and default property values. The Configuration element specifies lists and modules to use when creating SharePoint sites. For information about the format and elements used in site definitions, see Site Schema.
SharePoint Foundation activates Features specified within the Onet.xml file in the order that they are listed. Consequently, you must specify Features that are depended upon before Features that depend upon them.
SharePoint Foundation activates Features specified within the Onet.xml file in the order that they are listed. Consequently, you must specify Features that are depended upon before Features that depend upon them.
Understanding Site Definitions
Site Definitions help to create templates that can then be used to for new site creation etc. These basically help you create sites with pre-defined features/looks etc repeatedly without having to manually add those features/designs.
Another way of looking at this - A SharePoint Foundation website is based on particular site definition configuration. For this reason, you can think of a site definition as a family of configurations, although some families contain only one configuration.
Also, one major benefit is that in case of changes that need to reflect across all sites can be made at one place rather than in every default.aspx present in every site.
Though, site definitions are the best way to implement changes that need to reflect across sites (like adding a new company's logo), the concept of unghosting plays a negative role in achieving the same.
For detailed explanation, visit the link provided at the bottom of the post.
The site definitions are found at the location - \14\TEMPLATE\SiteTemplates
Core Schema files of a site definition:
2. Onet.xml: Has all major settings for site creation.
Location: \SiteDefinitions\site_type\xml\
The main difference between Schema.xml amd Onet.xml is that the scope of the former is limited to the lists where as the scope of Onet.xml extends to a site.
The built - in webtemp.xml and the other webtemp*.xml consitute the site definitions that are available at the time of site creation. While creating a custom site definition, one should create a new webtemp*.xml. The SharePoint Foundation then merges the WebTemp.xml with all the other webtemp*.xml file and presents the site definitions available.
Courtesy:
-- http://www.devx.com/dotnet/Article/27673/0
-- http://msdn.microsoft.com/en-us/library/aa978512.aspx
Another way of looking at this - A SharePoint Foundation website is based on particular site definition configuration. For this reason, you can think of a site definition as a family of configurations, although some families contain only one configuration.
- Ghosting: This is a concept in SharePoint that allows it to maintain only one copy of aspx pages like default.aspx that is actually used across all the sites present. SharePoint creates a reference of the page in the new site's database. This process is called ghosting. The advantages that this concept offers are utilization of space and better performance w.r.t. the amount of cache that gets loaded.
Also, one major benefit is that in case of changes that need to reflect across all sites can be made at one place rather than in every default.aspx present in every site.
- Unghosting: Whenever a user wants to heavily customize his page, SharePoint is left with no option but to unghost the page. The concept of ghosting is valid only the page can be kept same across all the sites. If one site user wants to cusomize his page, then the page needs to be unghosted, a copy of the page will be created in the database which would be solely for that particular site.
Though, site definitions are the best way to implement changes that need to reflect across sites (like adding a new company's logo), the concept of unghosting plays a negative role in achieving the same.
For detailed explanation, visit the link provided at the bottom of the post.
The site definitions are found at the location - \14\TEMPLATE\SiteTemplates
Core Schema files of a site definition:
- WebTemp*.xml: Helps in identifying the site definations. Also makes the site definition visible in the UI.
2. Onet.xml: Has all major settings for site creation.
Location: \SiteDefinitions\site_type\xml\
The main difference between Schema.xml amd Onet.xml is that the scope of the former is limited to the lists where as the scope of Onet.xml extends to a site.
The built - in webtemp.xml and the other webtemp*.xml consitute the site definitions that are available at the time of site creation. While creating a custom site definition, one should create a new webtemp*.xml. The SharePoint Foundation then merges the WebTemp.xml with all the other webtemp*.xml file and presents the site definitions available.
Courtesy:
-- http://www.devx.com/dotnet/Article/27673/0
-- http://msdn.microsoft.com/en-us/library/aa978512.aspx
Subscribe to:
Posts (Atom)