Open DroopyTersen opened 5 years ago
Thank you for reporting this issue. We will be triaging your incoming issue as soon as possible.
Did you try setting both in the same request?
@jansenbe yes, I did try updating both properties at once. The LayoutWebPartsContent
updates as expected. The CanvasContent1
property acts as if nothing happened.
I also tried purposefully using an invalid property ID, CanvasContentXXX
to make sure it wasn't it wasn't an issue of errors being silently swallowed. When doing this though, I received the invalid Field error as expected.
Kind of at a loss at how to proceed. Ultimately I am trying to clone pages while running the page content through some replacer functions. Is there another way to achieve this that doesn't require an update of CanvasContent1
?
I'm also having this exact issue. For me this is with a solution that has been working for 4 months and just stopped working about 2-3 weeks ago. I have the exact same request running in 3 different tenants. 2 of the 3 tenants fails but only in site collections that were created since the issue started. In site collections that were created before the issue started the call still works properly. In the 3rd site collection the call works regardless if the site collection was recently created or has existed for some time.
I've replicated the issue with an OOB webpart instead of the custom webpart the solution uses, just to take that out of the equation.
GUIDs altered for privacy...
RESPONSE: 204 POST: https://shirepharmadev.sharepoint.com/sites/MLTest2/_api/Web/Lists(guid'05c919c8-1902-44ec-b636-18134cf26632')/Items(24) PAYLOAD: {"__metadata":{"type":"SP.Data.SitePagesItem"},"CanvasContent1":"
Was this ever resolved or any alternative?
From Power Automate, I am able to successfully update the CANVASCONTENT1 property formatted as JSON in the following way for a modern SPO page:
POST Body:
{ "CanvasContent1": "[{\"webPartId\":\"d1d91...[some more content]...on\":4},\"isEmailReady\":false}}]" }
POST Headers:
{ "Accept": "application/json; odata=nometadata", "Content-Type": "application/json;odata=verbose" }
POST URL: https://[tenant].sharepoint.com/sites/[sitename]
POST URI: /_api/sitepages/pages(@{triggerOutputs()?['body/ID']})/SavePageAsDraft
hope that helps.
Before I was able to do that, I had to checkout the page /_api/sitepages/pages(@{triggerOutputs()?['body/ID']})/checkoutpage. The ID used is just the SharePoint integer list-item-ID of the page.
The issue seems to be that the fields CanvasContent1 and LayoutWebpartsContent in the SitePages library cannot have more than 255 characters, which can silently fail (a field error being returned in the request instead, e.g. when using ValidateUpdateListItem). It's obviously not limited to 255 characters, but the validation insists it is. After cutting it down to this length, which is all but easy, it saves.
Category
Expected or Desired Behavior
I would expect to able to update a Modern Page's
CanvasContent1
property via the REST API.Observed Behavior
204
, however theCanvasContent1
property does not actually get updated. The page maintains the previousCanvasContent1
.LayoutWebpartsContent
.CanvasContent1
on both Tenants.Is there tenant, site or library level property that might prevent the REST API from persisting the
CanvasContent1
property update?Steps to Reproduce
I am performing the following SharePoint REST API HTTP Request from inside a SPFx webpart (currently from
/_layouts/workbench.aspx
of the target site.As stated above:
LayoutWebpartsContent
instead works as expected.CanvasContent1
in my Dev tenant