Fixing Code Blocks not Allowed 

Tags: IT Pro, How To, Admin, SharePoint 2013, SharePoint Designer, SharePoint 2010, Pre SharePoint2010, Branding, Public Facing Site, Security, Best Practices

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:

<script runat="server">
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">

            <PageParserPaths>

                <PageParserPath VirtualPath="/_catalogs/masterpage/BullseyeBranded.master" CompilationMode="Always" AllowServerSideScript="true" />

            </PageParserPaths>

        </SafeMode>

 

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.

 
Posted by AndyGett on 21-Mar-13
11 Comments  |  Trackback Url | Bookmark this post with:        
 

Comments


Roy commented on Monday, 25-Nov-2013
I tried this approach for 2013 SharePoint web application. it does not work. non of the entries to any particular page works until you have this which makes the whole application very unsecured. had you any experience of this doing in 2013 Sharpoint

Andy Gettings commented on Friday, 6-Jun-2014
As you mention, enabling code blocks are not secure at all. In SharePoint 2013, often using the REST interface is a viable option, better than in SharePoint 2010 where you could use jQuery plus SPServices for programmatic functionality. Other options are 1. create a feature to deploy your code 2. for quick one-off's, use PowerShell.

Rakesh commented on Tuesday, 21-Jul-2015
I tried this on sharepoint server 2013 web application. It does not work.

Andy Gettings commented on Tuesday, 21-Jul-2015
Rakesh, what area you trying to accomplish, and what are the results? Error messages?

ivan commented on Tuesday, 27-Oct-2015
where can i find the web.config file? where directory specifically? Thanks

Andy Gettings commented on Wednesday, 28-Oct-2015
Ivan, for a default install with a single web front end farm, there is a single web.config file in C:\inetpub\wwwroot\wss\VirtualDirectories\80 In general, IIS reports the Physical path for the web application's web.config file on that server. If you have multiple WFE's, you will have multiple web.config files.

Thriveni commented on Tuesday, 7-Jun-2016
it is not working in Sharepoint 2013

Andy Gettings commented on Wednesday, 29-Jun-2016
Thriveni, what do you mean by not working? What are you trying, what happens, and what do you want to happen?

Surya commented on Monday, 9-Oct-2017
Thanks a lot Andy. I had the same problem with one of my master pages and resetting it to the site definition helped. Been breaking my head for a couple of hours on this. Thanks again.

CG commented on Sunday, 21-Apr-2019
How would this work with SharePoint Online? I see the same error after I change my searchresults.aspx page layout.

Andy Gettings commented on Thursday, 25-Apr-2019
@CG, you could try creating a new results page, adding the same web parts that are in searchresults.aspx (not sure if this is possible). You would have to wire up the default.aspx and advanced.aspx to use the custom results page.
Name:
URL:
Email:
Comments: