7

Background:

So I've apparently committed the cardinal sin in SharePoint. I edited a page layout in SharePoint Designer! This of course injected the special SPD meta attributes into the layout which were still in the page layout at the time I copied it into my farm solution, which was subsequently deployed to our Dev and then Prod environments.

This wouldn't be such a big deal to resolve if it wasn't for the fact that my page layout had web parts embedded within it which we no longer want. Those web parts are now in the AllWebParts table within the content database, so even though I've upgraded my page layout to a version that does not have the SPD attributes and web parts, because the web parts are still in the AllWebParts table, they are still injected into any page using the new version of the page layout.

Question:

Without executing SQL against the content database (unsupported and a big no no), how can I remove the web parts from the AllWebParts table? My farm will soon have thousands of site collections in it, using this page layout, and I can't have the offending web parts injected in every publishing page that anyone uses this page layout on.

After burning a ton of support hours, Microsoft is telling me this is a one-way disaster that cannot be undone without nuking my content databases and starting over. Let's prove them wrong!

Microsoft's Stop-Gap Idea:

As a stop-gap measure, Microsoft have provided the below PowerShell snippit for us to execute on each site collection. It removes the webparts from the pagelayout in the site collection, but any new site collection we create would also have the issue, so we'd have to run the script on those as well. Surely there's a better solution than this!

$site = Get-SPSite http:// SiteURL /sites/bferman/
Write-Host $site.Url
$web = Get-SPWeb http:// SiteURL /sites/bferman/
$pagelayout = "http://SiteURL/sites/bferman/_catalogs/masterpage/gpcNavLeftBLTR.aspx"
$file = $web.GetFile($pagelayout)
Write-Host $file.Name
$file.CheckOut()
$wpm = $web.GetLimitedWebPartManager($pagelayout, [System.Web.UI.WebControls.WebParts.PersonalizationScope]::Shared)
Write-Host $wpm.WebParts.Count
$webparts = @()
foreach($spwebpart in $wpm.Webparts)
{
    #You can have a condition to check for the name of webparts #here
    $webparts = $webparts + $spwebpart.ID
}
foreach($webpartId in $webparts)
{
    $wpm.DeleteWebPart($wpm.Webparts[$webpartId])
}
$file.CheckIn("Removed webpart",1)
$file.Publish("Removed webpart")
$web.Update();
$web.Dispose();
if($wpm -ne $null)
{
    $wpm.Dispose();
}
$site.Dispose()
Improve this question
4
  • Here's an update from Microsoft on my case: As the page layout is already unghosted, you can remove the webparts through SPD. The behavior we mentioned “by–design” is the unghosted pagelayout with webparts cannot be ghosted back to the one without webparts. – SF1Dev Jan 2 '13 at 16:38
  • Another update from Microsoft: The custom page layout is unghosted now (definition is persisted in the database). This definition has their 4 web part zones and the web parts in them (in the database if we look at the image of the page layout, we’ll not find the web parts, however, they are referenced through entries in another table and are pinned to their custom page layout at runtime). – SF1Dev Jan 2 '13 at 16:57
  • And also this: As the page layout is now unghosted, so the modifications you want to make to this page layout moving forward should only be through SPD (Sharepoint Designer). Feature upgrade and such approach will not work because those approaches don’t have access to the page layout binary in the content database. These approaches only refer the files in the file system. – SF1Dev Jan 2 '13 at 16:58
  • Gosh I hope you're wrong. Microsoft is now instructing me to give up on removing the web parts and simply create a new page layout with the same functionality but with a different name, so that the web parts don't try to insert themselves in the new layout. This answer from them is a difficult pill to swallow. It'll mean significant changes to other features as well. I want to think SharePoint is not so poorly designed. – SF1Dev Jan 2 '13 at 22:27
2
+50

Hate to tell you, but this is probably a lost cause if you ever want a truly healthy farm again. Even if you do get your site back to looking the way you want it by "tricking" the new page creation process via changing the web part zone names, you're leaving gremlins in the closet (or, more appropriately, the content database).

I had to walk away from trying to fix a farm that had this problem using a similar PS script. This is as far as I got: Removing Orphaned WebParts via PowerShell - CheckIn/CheckOut Requirement Loop (there's no answer because I didn't resolve the problem).

You can tell I had used the same code base as the script MSFT provided you. The error in the linked post was just one error of a long line of endless other errors I ran into trying to actually fix this (as opposed to settling on a work around like you are trying to get from Microsoft). Even when I did get a reference to the web part from the database, trying to delete the reference caused the object model to crap out. No matter what I tried, the script would just crash and the web part's GUIDs were still in the content database.

I guess the point that I'm trying to get across is that for long term stability in your farm (or come migration time) you're going to wish you didn't just sweep this under the rug in hopes that nothing would fall out when the guests arrive.

Improve this answer
7
  • Are you suggesting that I nuke the content databases and start over? Once we've finished creating all of our site collections, there will be over three thousand of them. If I had run into this issue after they were created and in use, what then? – SF1Dev Jan 3 '13 at 14:24
  • You could try to migrate the content using a tool with a clean version of the page layout and hope for the best... but yes, I'm recommending you start over. I understand why you'd be frustrated, but remember that it wasn't MSFT that committed the cardinal sin, and some customers need this behavior. There are a lot of people working with SharePoint who just don't know enough about the complexities of SharePoint or the ramifications of their actions. If you had never pushed a "bad" custom solution to your 3000 site collections or if you caught this in testing, you wouldn't be dealing with this. – RJ Cuthbertson Jan 3 '13 at 16:00
  • I agree with your assertions, except for the point that anyone could find this "functionality" useful. I don't disagree with the need for some things to live in the content database like page layouts and web parts, but to be pushed there in an irreversible way seems useless to me. If the effect is by design as Microsoft told me, then they should at least have it documented. I've taken your points to my admin team. Can you recommend a migration tool? – SF1Dev Jan 3 '13 at 16:06
  • Ghosting/Unghosting is covered in the SharePoint documentation: msdn.microsoft.com/en-us/library/ms459213.aspx or msdn.microsoft.com/en-us/library/bb892189%28v=office.12%29.aspx for instance... There are many migration tools available. As I work for a partner/reseller of many competing migration tools, I don't think I could recommend one without being biased, and no one tool is right for every situation. – RJ Cuthbertson Jan 3 '13 at 16:16
  • I've read a lot about ghosting/unghosting, particularly recently. Unfortunately what is missing from the documentation is Microsoft's new assertion that once you unghost a page layout containing default web parts, it can never be successfully reghosted, or upgraded. It can be removed, but not without orphaning web parts. – SF1Dev Jan 3 '13 at 16:44
1

I would totally recommend you to use the PowerShell script (provided by Microsoft) to remove the web parts from all the existing site collections (with page layouts that are ghosted).

For page layout that is unghosted, you can only move forward with SPD (Sharepoint Designer).

For all the newly created site collections, you can simply update the Page layout in existing WSP solution package and re-activate the feature (a custom feature which provision the Page layout in the master page gallery) to get the latest changes. If you have problem updating the Page layouts in the master page gallery try using an approach that I suggested in another post

Let's not forget we can always reset our site pages to their default definitions...

$site = Get-SPSite "http://SiteURL/sites/bferman/" 
$sites = @(foreach ($web in $site.AllWebs) { 
$web | Select-Object -Property Url
Write-Debug "Resetting all pages in site ($($web.Url))..."
$web.RevertAllDocumentContentStreams()
$web.Dispose() 
}) | out-File -filepath "c:\log.txt" 
$site.Dispose()
Improve this answer
8
  • Since it's a new farm, we actually tried deleting all the site collections. We also reinstalled the page layout feature with a new version number. New site collections exhibit the problem. One weird thing happens though, when you download the page from the master pages gallery, you get the new page layout. If you edit the page with SharePoint designer, you get the old page layout, the one with the web parts embedded within it's zones in the markup of the page. – SF1Dev Jan 2 '13 at 22:31
  • what happens when you create the new page based on the page layout? We can reset our site pages to their default definitions. See the updated PowerShell in the post – Falak Mahmood Jan 2 '13 at 22:41
  • have you tried by creating a new site collection in a new Content database? – Falak Mahmood Jan 2 '13 at 22:42
  • I've provided your PS script to our admin team. I'll let you know the result in the morning. We have tried creating a new site collection in a new content database and the problem remains. The page layout in question is also the default publishing page layout. When we create a new page, it's automatically assigned the page layout and the web parts appear in the page's zones. – SF1Dev Jan 3 '13 at 3:21
  • During troubleshooting with Microsoft, Microsoft had us copy the contents of the OOB article page page layout and paste it into our custom page layout, overwriting our custom code. We did this using SharePoint Designer. The web part zones in the Article Page layout are named differently than our custom page layout. New pages we created after that also got the web parts, but this time they went straight into the Closed Webparts gallery. We've since replaced our custom page layout code in the page layout. – SF1Dev Jan 3 '13 at 3:24

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.