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 front-end servers and reviewed focusing on the correlation ID indicated on the error message.
Running the following commands indicated a pages using corrupted web-part, but even after deleting the page or trying to delete the web part this issue was not resolved.
First – Identify corrupted or orphan objects:
$db = Get-SPContentDatabase -Identity CDB_XXXX $db.repair($false) Output : <OrphanedObjects Count="0" />
Second – 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.
Third – Identify which pages using the web-part
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
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)
The forth step – 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 library 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).
- Export an empty working Site Pages library using Central Admin Granular backups.
- validate successful export.
- Delete the effect library in your site after backing up the files
- 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 in 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 quotas 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/