Page description not changing automatically after page creation (but normally it should).

[grillaertr]

Normally, when creating a new site page in SharePoint and adding a text webpart, the page description property changes depending on the displayed text (unless the page description property is changed manually, then the link between text in webparts and the page description is gone). But when I create a new site page using PnP Powershell or custom code (with or without adding a text webpart), the link between the text in webparts and the description property of the site page is gone. I guess this issue is because even tho there is no text on the site page, the site page description is still changed in the code (Starting on line 1288).

[grillaertr]

Hi, any update on this?

[PieterHeemeryck]

It appears something similar occurs in the new PnP.Framework sp npm package:
https://github.com/pnp/pnpjs/blob/version-2/packages/sp/clientside-pages/types.ts#L369

We are having the same issue using the new framework as described above. It's quite easy to reproduce, using the PnP .save(...) method on an existing page seems to lead to the description property no longer updating automatically when subsequently editing text on the page manually.

The issue with this is that we rely on this description property for e.g. news lister rollups using SP search. End users should not manually fill out this value, it should be updated automatically based on the text on the page.

It would be really helpful for us if there is any acknowledgement of this behaviour. It's quite a basic and useful command, so it would be a shame to not be able to use it freely. It's quite the caveat for an intranet application.

[PieterHeemeryck]

We've been able to fix this by modifying the CanvasContent1 property of the page. It has to do with its contents. You can change it back such that the default description is being used again. Just be careful when updating its contents, as it is a lengthy string with lots of values.

[jansenbe]

@PieterHeemeryck : can you clarify what you've changed...will help speed up a fix for this :-)

[PieterHeemeryck]

Of course. One replacement is always done: setting the flag i'sDefaultDescription' to true. We also execute a more involved regex replace, but we've noticed that not every tenant or site collection plays well with that one, so it's made defensive. Not completely sure if the involved regex is needed as well.

// reset possible broken description
let canvasContent = newPageItemData.CanvasContent1;
canvasContent = canvasContent.replace('"isDefaultDescription":false', '"isDefaultDescription":true');

const htmlAttributesRegex = /("htmlAttributes":[(.?)])/g;
const modifiedDescriptionRegex = /(("modifiedDescription"[, ])|([, ]*"modifiedDescription"))/g;
const matches = htmlAttributesRegex.exec(canvasContent);

if (!!matches) {
matches.forEach((match) => {
const updatedMatch = match.replace(modifiedDescriptionRegex, "");
canvasContent = canvasContent.replace(match, updatedMatch);
});
}

await spHttpClient.post(
${siteUrl}/_api/sitepages/pages(${newPageItemData.Id})/savepage,
SPHttpClient.configurations.v1,
{
body: JSON.stringify({
__metaData: {
type: "SP.Publishing.SitePage"
},
Title: pageTitle,
CanvasContent1: canvasContent
})
}
);

[jansenbe]

@grillaertr , @PieterHeemeryck : I've just committed a fix for this. Now the behavior aligns with what you would get for a manually created page. When a page is created the library sets a default description, but leaves it marked as "default"...when a user then edits the page the description is overwritten depending on the user's edits and this should also reflect in roll up web parts (search/caching might delay this a bit).

Note, when programmatically updating a page we're not overwriting the existing description if any was set. We do respect the default description flag if it was set before, so a page that was given a custom description via the UI will stay in that mode on page edit.

For now we do not offer an option to change a custom description, if you feel that's needed then let me know.

Note that I'm also closing this case for now, please try with the next nightly (or 1.6 which we hope to release soon) and if you still see issues then please re-open or create a new issue.