Ghosted pages in SharePoint don't render

Applies to: SharePoint Server 2019SharePoint Server 2016Microsoft SharePoint Foundation 2013 Service Pack 1

Symptoms


After you install one of the following updates, some ghosted pages in Microsoft SharePoint don't render:

For example, Microsoft Identity Manager (MIM) portal pages and some customized pages that are deployed through SharePoint Solution don't render.

Additionally, you may experience one or more of the following scenarios.

Scenario 1

The blocked ghosted page displays one of the following error messages: 


Scenario 2

The blocked ghosted page displays the following error message:


Scenario 3

The blocked ghosted page displays the following error message:

Cause


Ghosted pages are stored in the file system. Their security level is enhanced by forbidding server-side scripts and unsafe controls. A ghosted page may be blocked from rendering if the following conditions are true:

  • The ghosted page contains in-line code or server-side script.
  • The code-behind type or web part type isn't registered as safe.

Resolution for Scenario 1


To resolve this issue, add a new PageParserPath element that has a VirtualPath attribute to the Web.config file under the configuration/SharePoint/SafeMode/PageParserPaths element.

For example, you receive the following error message:

"The attribute 'autoeventwireup' is not allowed in this page."

In this case, you can add a PageParserPath element, as follows:

<SafeMode MaxControls="200" CallStack="false" DirectFileDependencies="15" TotalFileDependencies="250" AllowPageLevelTrace="false">    <PageParserPaths>        <PageParserPath VirtualPath="/<relativepath>/page.aspx" CompilationMode="Always" AllowServerSideScript="true" AllowUnsafeControls="true" IncludeSubFolders="True"/>    </PageParserPaths></SafeMode>


If all pages in the same virtual directory have to be unblocked, you can use a PageParserPath element, as follows:

<SafeMode MaxControls="200" CallStack="false" DirectFileDependencies="15" TotalFileDependencies="250" AllowPageLevelTrace="false">    <PageParserPaths>        <PageParserPath VirtualPath="/<relativepath>/*" CompilationMode="Always" AllowServerSideScript="true" AllowUnsafeControls="true" IncludeSubFolders="True"/>    </PageParserPaths></SafeMode>
 

Resolution for Scenario 2


To resolve this issue, add a new SafeControls element for the given type, namespace, and assembly strong name to the Web.config file under the configuration/SharePoint/SafeControls element, as described in SafeControls element (Solution). Then, set the Safe attribute to TRUE.

For more information about the format of the attribute values in the SafeControls element, refer to the table in step 12 in the "Marking Safe Controls in the Package Designer" section of How to: Mark controls as safe controls.

Resolution for Scenario 3


To resolve this issue, add a new SafeControls element that uses the Src attribute to the Web.config file under the configuration/SharePoint/SafeControls element.

For example, you receive the following error message:

"The referenced file '/_layouts/somedirectory/affectedusercontrol.ascx' is not allowed on this page."

In this case, you can add the SafeControls element, as in the following examples:

< SafeControls>    <SafeControl Src="~/_layouts/somedirectory/*" IncludeSubFolders="True" Safe="True" AllowRemoteDesigner="True" SafeAgainstScript="True" /></SafeControls>
 
< SafeControls>    <SafeControl Src="~/_layouts/somedirectory/*" IncludeSubFolders="True" Safe="True" /></SafeControls>