Content Page Type
This content is outdated and is no longer being maintained. It is provided as a courtesy for individuals who are still using these technologies. This page may contain URLs that were valid when originally published, but now link to sites or pages that no longer exist.
Content pages can be modified by end users by using tools such as Microsoft Office SharePoint Designer 2007, or uploaded using protocols such as WebDAV. When you create a SharePoint site, many content pages are created automatically, for example, default.aspx, allitems.aspx for your Web Part gallery, editform.aspx as an edit form for your announcements list, and several others.
Content pages are stored logically within their SharePoint sites, and most of the files are also stored physically in their associated SharePoint content database. However, not all content pages are actually stored in the content database.
Customized Content Pages
Windows SharePoint Services 3.0 supports page customization (also known as "ghosting"). However, Windows SharePoint Services stores customized pages differently from unmodified template pages.
Unmodified page template files are stored on disk on the front-end Web server, not in the content database. Customized pages—template pages that a user has modified—are stored in the content database.
In cases where Windows SharePoint Services provisions a page from a SharePoint template, instead of retrieving a page from the content database, the system creates a pointer to the instance of the page template file on the front-end Web server. As a result, Windows SharePoint Services avoids repeatedly creating copies of its content pages, which are provisioned each time a site is created.
This pointer to an instance of the template page on the front-end Web server is created only if the user has not customized the page. After a page is customized (using Office SharePoint Designer 2007, for example), the pointer is voided and the page itself is stored in the content database.
Warning
Do not assume that because the contents of a page or file are not customized (using tools such as Office SharePoint Designer 2007) you can freely modify the server copy to make changes to all existing instances. There are many modifications (such as changing values of properties for a file in a list) that cause Windows SharePoint Services to consider the page or file "customized." Furthermore, changing server copies of provisioned files can cause unwanted side effects, for example, quota calculations on file size may be incorrect. Do not customize server copies of files after provisioning. Consider using master pages instead to effect site-wide changes. For more information about using master pages, see Master Pages.
Using Server Side Code on Content Pages
The rules that govern the use of server-side code on content pages are unchanged from Windows SharePoint Services 2.0. That is, in-line server logic declared within SharePoint content pages is generally not supported. This applies only to in-line logic within the page, and does not include code behind Microsoft ASP.NET controls on the page. The set of controls that are allowed to execute is governed separately by the safe controls list.
Following are general rules for using server-side code on a content page:
If the contents of a page are not customized, server-side code is supported on the page.
If the contents of a page are customized, server-side code does not execute on the page, and the page does not render.
It is a recommended best practice to avoid using server-side code on content pages when developing site definitions, because if a user later edits or modifies that page, the code will no longer execute.
An administrator can override the settings that support the general rules. That is, the administrator can add a PageParserPath setting in the web.config file that allows the execution of server-side code on pages stored at a specified path.
Following is an example of such a setting.
<SharePoint>
<SafeMode ...>
<PageParserPaths>
<PageParserPath VirtualPath="/_mpg/*" CompilationMode="Always"
AllowServerSideScript="true" IncludeSubFolders="true"/>
</PageParserPaths>
To specify all files in a folder at the end of a virtual path, use the wildcard character (*), as illustrated in the sample above; alternatively, use the file name itself to enable only a single, specific file. You cannot use generic wildcard characters on file names in the virtual path (for example, ../_mpg/my*.aspx).
Warning
Security Alert: Adding PageParserPath settings gives anyone who can upload pages to these folders the ability to write arbitrary, full-trust code to the server. Administrators should not provide these PageParserPath settings; if circumstances require doing so, use extreme caution.