Monday, March 24, 2014

Caveats when using Summary Link Web Part in a Web Template

My scenario was that the Summary Link Web Part had been used on a site which was to be saved as a site template using the UI (Save site as template). Saving the template worked fine, but once you created a new site based on the template you got the infamous “List does not exist” error.

The reason for the error is that the SummaryLinkWebPart class inherits the DataFormWebPart class, which has a property called ListId. If the page which hosts the Summary Links Web Part is located in for example SitePages, then the id will point to that list. Once you save the template, this id will come along, and will of course not exist in the new site.

When it comes to the Summary Link Web Part it really don’t need a reference to a list, as it’s storing all the data inside the web part itself. To fix up the template site before saving it I wrote the following PowerShell script.

function FixWebpart($wpm) {
$count = $wpm.WebParts.Count-1
ForEach ($number in 1..$count )
{
$webpart = $wpm.WebParts[$number]
# Check if it's a summary link web part
if( $webpart.PsObject.TypeNames[0] -eq 'Microsoft.SharePoint.Publishing.WebControls.SummaryLinkWebPart' ) {
write-host "Fixing listid - " + $webpart.Title + " : " + $webpart.ID
# Set the id to a blank GUID
$webpart.ListId = [guid]::Parse("00000000-0000-0000-0000-000000000000")
$wpm.SaveChanges($webpart)
}
}
}

#Get a reference to the template site
$web = get-spweb https://intranet.contoso.com/sites/template
$list = $web.Lists.TryGetList("Site Pages")

foreach($item in $list.Items) {
$wpm = $web.GetLimitedWebPartManager($item.Url, [System.Web.UI.WebControls.WebParts.PersonalizationScope]::Shared)
FixWebpart($wpm)
}

7 comments:

  1. Note that the code has to be run on a WFE as the webpart manager will fail on a pure APP server.

    ReplyDelete
  2. Hello Mikael,

    Thanks for your sharing your finding. Is there any out of the box way other than code to fix this issue with Summary links webpart?
    Could the other pages which are not in Pages library not have this issue?
    Please provide your comments.

    ReplyDelete
    Replies
    1. Hi,
      Don't think there is another way as far as I know :( And I think the issue would be with other pages as well. Mine were in Site Pages which is the wiki/webpart library of a team site. Could be that it works better in a publishing page.

      Delete
  3. Hi Mikael, I'm using summary links in a publishing page as a column (my column's data type is Summary Link). I mapped it to a managed property and I can retrieve it in the search results of a content search web part. While the PublishingPageContentOWSHTML field comes back with all the HTML markup, my SummaryLinks come back as pure text without any HTML markup. I know that all the HTML markup is in there as that's how summary links columns are stored. It starts with < div title='_schemaversion' id='_3' > < div title='_links' > and so on. Do you know if there's a way to retrieve the summary links with the full markup so I can apply XSLT and display it properly. Right now, all can display is this weird text:
    Resources for You
    1
    True
    True



    Research - Biologics
    2
    False
    Resources for You

    /programs/biologics/research

    Default


    Review
    3
    False
    Review Description
    Resources for You

    /programs/biologics/review

    ReplyDelete
    Replies
    1. When you map it will keep only the text as you see, not all the markup. So you would have to parse PublishingPageContentOWSHTML in that case.

      Delete
    2. Yep. I checked the crawled prop in the ULS log and it doesn't have any markup to begin with. I'll see if I can parse the text coming in. Thx.

      Delete
  4. BTW, I'm using SP 2016 on-prem. I used the Query Tool and there's no HTML markup in the search, either. Perhaps all the HTML is stripped when the crawled prop is mapped to the managed prop?

    ReplyDelete