Forum Discussion
SPFx on Communication Site On-Prem
Is there a way to add a SPFx app customizer to a communication site template in 2019 on-prem? Essentially we have custom actions in 2016 that we converted to an app customizer for 2019 to load a JS ...
Yes, I believe Extensions are supported in SP 2019 but you need the right version of SPFx in place:
jcgonzalezmartin Thank you sir! Sorry, I need to clarify. The SPFx package works well on a Communication site, what we're trying to do is have the same JS load on the back-end legacy pages like /_layouts/settings.aspx for example. One of my devs is using Add-PnPJavaScriptLink to add the JS to the page on the other site templates with success. This way the end user experience is the same, since the modern site templates ignore any attempt to inject ScriptLink or ScriptBlock code by design, so the SPFx app customizer kicks in. A page like /_layouts/settings.aspx is the same legacy page that has existed since SP2013, so the SPFx is ignored but the actions added by Add-PnPJavaScriptLink kick in and load the JS file as if nothing changed. The only exception is on the Commmunication site template. We're getting "access denied" when trying to use the Add-PnPJavaScriptLink, I assume because MSFT doesn't want ScriptBlock or ScriptLink in modern sites. However, we're able to add the file this way to the other modern site template (STS#3). I'm wondering if there's something else we can do to the SPFx solution so it runs on pages such as settings.aspx on the communication site template sites?
For all system pages like /_layouts/settings.aspx etc, to display any custom component or run some JavaScript, you still need to use CustomAction with Location= ScriptLink. I haven't basically tried to use Add-PnPJavaScriptLink cmdlet on Communication site on SharePoint Server 2019 but that certainly works on SharePoint Online. If PnP PowerShell cmdlet doesn't work, you can write CSOM which can similar action. Let me know if you need CSOM code snippet.
Thank youRahul Suryawanshi, most of what we do uses CSOM, so we're good there. It looks like it was possibly a permissions setting I failed to set when I stood up the web app. Even though the web app policy was set properly, Communication Sites still misbehaved. I ran something similar to this in PowerShell to allow us to be able to add Custom Actions to Communication Sites:
(Get-SPSite -Identity "{communication site url}").DenyPermissionsMask = [Microsoft.SharePoint.SPBasePermissions]::EmptyMask
