As everyone knows by now, Microsoft is pushing all development out to the client-side. But most of the time, I find customers who desire customization want a user experience that is somewhat tailored to the current user. Like managers should see one thing when they log in, but regular users should see something else. That means that on the client-side, I need to be able to distinguish managers from other users. That’s normally done by assigning the users to groups. But in large organizations, that usually means Active Directory groups, which are then added to SharePoint groups. This leads to a problem, because from the client-side, there is no way to determine if the user has membership in a SharePoint group to which they’ve been added indirectly (i.e. through membership in an Active Directory group).
Uncategorized
Why Don’t My CSS Files Work on SharePoint 2019?
For those of you who may not know, I have an open source project for SharePoint called SPEasyForms. But this post is not about that, it’s about a general problem you might encounter in SharePoint 2019, which is that none of your CSS files in document libraries work. It just so happens that I first heard about this issue this week, when somebody reported SPEasyForms doesn’t work on SharePoint 2019. I had tested it in 2019 Preview, and it had worked just fine, but the preview license had expired, so I had to spend a few days standing up a 2019 RTM farm. As soon as I did that, I saw the same results as had been reported (i.e. SPEasyForms looked like crap). So I’m just using SPEasyForms to demonstrate the problem, and I’ll go on to talk about how to fix it.
Understand that this problem will affect all CSS files that are loaded out of document libraries. That includes OOB style sheets loaded out of the master page gallery. It does not affect all SharePoint 2019 installations. Like I said, my preview didn’t display this behavior, and that’s not because this only affects the RTM release. Others had already reported this issue with the Preview release. And Microsoft is aware of the problem, but nobody has explained what alignment of the stars will cause this issue, just some people have it and others don’t.
Using a Polyfill Service with SharePoint
If you’ve read many of my previous posts, you have probably seen me use polyfills (i.e. CRUD Operations for SharePoint Docs Using Fetch and REST), to patch older browsers with modern functionality like fetch. I generally download the polyfill, upload it to SharePoint, and load it on the page as a user custom action. But there is another way to load polyfills, which is generally called a polyfill service. The idea is that you load the polyfill from some external service, which detects your current browser, and loads just enough polyfill to patch your current browser up to some level of specification compatibility (usually like ES5, but you can also generally ask for specific functionality, like fetch and/or Promise). There are some unique problems with loading this kind of polyfill in SharePoint, mostly due to limitations in user custom actions. In this post I’m going to talk about how to load such a polyfill in SharePoint, but first lets talk a little more about polyfill services in general.
Loading JavaScript or CSS on Every Page in a Site using JSOM (UserCustomActions)
A common question in SharePoint forums is how do I load SuchAndSuch.js on every page in the site collection (ok, let’s be honest, it’s usually how to I load jQuery on every page). This is pretty easy to do using the SharePoint client object model and setting something called UserCustomActions. I showed using this utility page in my Accordion View, Custom List View CSR Template. In this post, I’m going to show what’s going on behind the curtains in that utility page. It will be an ASPX page (really just a text file) that you can drop in any SharePoint document library and click on to start immediately configuring UserCustomActions at either the site or the web level. It has no dependencies. It is a self contained page with only HTML and pure JavaScript.