Users can’t create Wiki pages in a specific site collection

When users try to create a new wiki page from the Site Pages library, they get the error :

The URL 'SitePages/xxx.aspx' is invalid.  It may refer to a nonexistent file or folder, or refer to a valid file or folder that is not in the current Web.
Troubleshoot issues with Microsoft SharePoint Foundation.
Correlation ID: xxx-xxxx-xxxx-xxxx
Date and Time: xx-xx-xxxx

This issue may also related to any other page library.

Symptoms  and test cases:

Users can’t create/modify a new wiki page on the exiting OOTB Site Pages library.
Users can create/modify a new web-part page on the Pages library on the same site.
Users can create/modify a new Wiki Library and create new Wiki Pages on the same site.
Users can create/modify a new wiki page on a different sub-site’s Site Pages library.
Users can create/modify New Wiki pages on other site collections on the same Farm.

Steps taken:

Verbose logs where taken from the frontend servers  and reviewed focusing on the correlation ID indicated on the error message.

Running the following commands indicated a pages using corrupted webpart, but even after deleting the page or trying to delete the web part this issue was not resolved.

Step 1 – Identify corrupted or orphan objects:

$db = Get-SPContentDatabase -Identity CDB_XXXX
$db.repair($false)
Output :
<OrphanedObjects Count="0" />

 

Step 2 – Identify Database issues

Test-SPContentDatabase $DB
Category       : MissingWebPart
Error           : True
UpgradeBlocking : False
Message         : WebPart class [5fe113fa-f5b4-d2a0-77cc-59f1faed167b] is referenced [1] times in the database [CDB_XXX], but is not installed on the current farm. Please install any feature/solution which contains this web part.
Remedy         : One or more web parts are referenced in the database [CDB_XXXX], but are not installed on the current farm. Please install any feature or solution which contains these web parts.

 

Step 3 – Identify which pages using the webpart

Running this command on the SQL server on the content DB CDB_XXX

SELECT WebID, SiteID, DirName, LeafName, tp_WebPartTypeId, tp_WebPartIDProperty

FROM AllDocs WITH (NOLOCK) inner join AllWebParts on AllDocs.Id = AllWebParts.tp_PageUrlID

WHERE AllWebParts.tp_WebPartTypeID = '5fe113fa-f5b4-d2a0-77cc-59f1faed167b'

 

the output may be something like this

[‎9/‎12/‎2018 11:07 AM] Nicholson, Martin:

No Title WebID SiteID DirName LeafName tp_WebPartTypeId tp_WebPartIDProperty
F2F85DDB-8A63-4AF4-93FE-DF1BE7A40E2E E53A42C8-4DB4-4CC7-8737-032392F00396 trans/fieldresources/Resource Info                                                    Contacts and Org Charts.aspx
5FE113FA-F5B4-D2A0-77CC-59F1FAED167B NULL
(1 row affected)

 

Step 4 – delete the webpart the causing the problem

Extract the following information and create this PowerShell command :

clear
$webID = "F2F85DDB-8A63-4AF4-93FE-DF1BE7A40E2E"
$siteID = "E53A42C8-4DB4-4CC7-8737-032392F00396"
$dirName = "trans/fieldresources/Resource Info"
$leafName = "Contacts and Org Charts.aspx"
$webPartID = "5FE113FA-F5B4-D2A0-77CC-59F1FAED167B"
#Get Web
$web = Get-SPweb -Identity $webID -Site $siteID
#Build page url
#$pageURL = "{0}{1}/{2}" -f ($site.WebApplication).url, $dirName, $leafName
#$pageURL = ($site.WebApplication).url, $dirName, $leafName
$pageURL ="http://xxxxxxxx/trans/fieldresources/Resource%20Info/Contacts%20and%20Org%20Charts.aspx"
#Get SPFile
$page = $web.GetFile($pageURL)
#Delete the web part on the current published page
$webPartManager = $page.GetLimitedWebPartManager([System.Web.UI.WebControls.WebParts.PersonalizationScope]::Shared)
#Delete web part by ID
$webPart = $webPartManager.WebParts[$webPartID]
$webPartManager.DeleteWebPart($webPart)
$web.Dispose()
$webPartManager |select webparts |

In my case even after deleting the page that was returned in step three it did not resolve the issue. Looking back at the log it might be related to a corrupted Schema.

Corrupted schema

On the Verbose SharePoint logs the following details implies that the a unique filed name is being used more than once on the same document library schema.

The Site Pages library effected is using a unique field identifier twice which failing on any attempt to create a new page  or modify exiting pages.

Some PowerShell command used to pinpoint the issue :

Get list fields

clear
$site= New-Object Microsoft.SharePoint.SPSite ("http://YourDomain/trans") 
$web=$site.OpenWeb() 
$list=$web.Lists["site pages"] 
$list.Fields |select ID, title, internalname,type | more

Get List Schema to the clipboard

$web = get-spweb http://sharepoint2/trans/
$list  = $web.lists["Site Pages"] 
$field = $list.fields | ?{$_.title -eq "Modified By"} 
[xml]$schema = $field.schemaxml  
$field.schemaxml
$list.SchemaXml |clip

Solution

in my case the effected document libarary didn’t have valuable files so I was able to delete it without impact. If your library  does contain important pages you can use the Settings – Content Structure to move these files to a new location ( make sure you can open the files after this move).

Step 1 : Export an empty working Site Pages library using Central Admin Granular backups.

Step 2 : validate successful export.

Step 3: Delete the effect library in your site after backing up the files

Step 4: Import the working  Site pages back to your effected site collection

 # command to restore a list to a site collection
$thepath = "C:\your backup file location\*.cmp"
Import-SPWeb "http://domain/target site collection" -Path $thepath -Force -IncludeUserSecurity

 

Thanks and kudos to Microsoft  SharePoint support team

I would like to thank Mohammed Bilal,  DEEPAK VARMA, Ehsan Shirpurwala, and Pratik Belapurkar, for working with me on this issue and provide their dedicates support and dedication finding the root cause and providing a work-around for this issue.

 

Further investigation venues if this doesn’t work for your case can be:

Limitation in content DB size or quotas, each time a new page is generated it  violates quatas limit, although if this is the case some of the Symptoms I discusses above wouldn’t work including adding pages on other document libraries in the same site collection.

Ref :

https://blogs.technet.microsoft.com/dawiese/2017/05/09/post-upgrade-cleanup-missing-server-side-dependencies/

 

Leave a Reply

Your email address will not be published. Required fields are marked *