I have an Office 365 site collection that I’ve been provisioning from within PowerShell – and automatically uploading webparts. I’m getting some weird behaviour though :
When looking at VIEW SOURCE – it’s even stranger – that’s the ENTIRE page !
Even when looking at the page request/s via FIDDLER – nothing seemed off. And nothing in the console or error log in the F12 developer tools.
I could view the page with the ?contents=1 appended to the URL – but still no answer.
I worked out that it’s actually a SEARCH webpart that is causing the issue – but I couldn’t work out WHY…
This was my PowerShell code to upload the webpart to the page – some other O365 guff around this – but this is the basic code (using CSOM) :
$wpm = $pubFile.GetLimitedWebPartManager([Microsoft.SharePoint.Client.WebParts.PersonalizationScope]::Shared);
$wpcoll = $wpm.WebParts
$webPartFileContents = [System.IO.File]::ReadAllText($filepath);
$wpd = $wpm.ImportWebPart($webPartFileContents);
$wpdNew = $wpm.AddWebPart($wpd.WebPart, $xmlwp.ZoneID, $webPartCount);
Within the .WEBPART file, there’s the usual XML bits & pieces – and a bunch of properties.
After lots of blog post hunting – off/on for a few days actually – and re-building the WebPart contents piece-by-piece, I noticed it was breaking on properties like this >
<property name=”RenderTemplateId” type=”string”>~sitecollection/_catalogs/masterpage/Display Templates/Search/Control_SearchResults.js</property>
It was THIS post from Chris O’Brien that made me hunt down this path :
..but then the page does not load (blank screen, HTML not output properly) and ULS shows the following runtime error:
Application error when access /SitePages/CSWP_Provisioned.aspx, Error=Cannot make a cache safe URL for “item_picture3lines_cob_provisioned.js”, file not found. Please verify that the file exists under the layouts directory.
at Microsoft.SharePoint.Utilities.SPUtility.MakeBrowserCacheSafeLayoutsUrl(String name, Boolean localizable, Int32 desiredVersion)
I couldn’t check the log files – with Office 365 – but I think it’s the same issue.
My next thing to try was to change the markup within my .WEBPART – and I had success !
Changed to :
Just needed to change from ~ to the equivalent in encoding ~
I’m unsure exactly WHY this is occurring – perhaps the PowerShell upload is losing this and/or encoding it wrong – but it worked !
Hopefully that helps someone – or at least, this post is a reference for ME, if it ever happens AGAIN !