We inherited a SharePoint site from another developer who left a little bomb behind. It manifested when a power user at the client site complained about a broken page on the development environment rendering
An error occurred during the processing of /sitename/SitePages/Home.aspx. Code blocks are not allowed in this file.
I opened the page in SharePoint designer, and sure enough, there it is:
protected override void OnPreInit(EventArgs e)…
I opened the same page in production, and the same code blocks are there as well. Could it be that the web.config file allows code blocks in the production web application and not the development one? That has to be it, right? No. They both have a single entry for the branded master page which is part of a WSP (see below). Phew.
I had another backup of the site in a development farm where the page was not broken, but also had the code in it. I decided to try changing the code a little bit to see what would happen. Saving the page generated:
I clicked Yes, and the page gave the same error. Aha! The page is part of site definition. As soon as it is "customized" (formerly known as "unghosted"), the reference to the page for that site is in the database, not the file system. Without a change to web.config (see below), code blocks are not allowed and the page breaks.
The options to fix are
- Reset the page to the site definition using SharePoint Designer
- Remove the code blocks from the customized page
- Change the web.config
In our case, we are resetting the page to the site definition.
Enabling Code Blocks via web.config
Other blog posts document how to change the web.config file so that page(s) can have code blocks in them. The caveat is that anyone with privileges to save a page can run code via the code blocks. Such a page is stored in a document library creates a security risk that should be avoided. For completeness, I'll include it here.
In the <SafeMode section of web.config, populate the <PageParserPaths> section with <PageParserPath entries. This is an example of a master page stored on the file system via a WSP:
<SafeMode MaxControls="200" CallStack="false" DirectFileDependencies="10" TotalFileDependencies="50" AllowPageLevelTrace="false">
<PageParserPath VirtualPath="/_catalogs/masterpage/BullseyeBranded.master" CompilationMode="Always" AllowServerSideScript="true" />
The best practice for production work is to make these changes to the web.config via a WSP once you have the desired results in your development environment.