One of the partners I consult for is migrating a Fortune 500 financial services company to SharePoint Online. The company wants to take advantage of modern team and communications sites, yet where they need features that aren’t available in modern SharePoint, they’ve decided to stick with classic Publishing sites.
The challenge is: how to build global navigation and footers that will work on both classic and modern sites. There are a few reasons this is important:
- It provides common navigation across all kinds of sites, making the Intranet easier to use
- It provides a common footer across all kinds of sites, ensuring compliance messages are delivered consistently
- It reduces coding and maintenance, because one set of code is used across old and new sites
So I undertook a little Proof of Concept, and here are the results. The solution is usable as-is if your needs are simple. The real intent, however is to prove out a pattern for developing any header and footer that will work on both modern and classic sites.
Client-side solutions have been de rigueur for a few years now: they’re cloud friendly, and are generally much easier to deploy than server-side code. SharePoint is an enterprise class content management tool, so it’s only natural to store the client code in SharePoint. That was all well and good until Office 365’s large farm sizes rendered SharePoint’s BLOB cache useless, which makes loading static files much slower online than on premises.
So lately Microsoft has been encouraging – and helping – us all to use a proper Content Delivery Network (CDN) for static content. CDN’s are designed for speed and volume; they even address the speed of light problem by fetching files from a data center that’s near the client. This will help your client-side solutions to load noticeably faster, as seen in this chart.
Lessons Learned from the #SPShire Project
I’m thrilled to be part of an early adopter project building a new intranet for Shire Pharmaceuticals based on the forthcoming SharePoint Communication Sites. Shire is an exciting and innovative company, and the team includes a number of my fellow Microsoft MVP’s as well as teammates from BlueMetal. Last week Microsoft broadcast a webinar from the Boston MTC featuring a cross-section of the development team. Microsoft’s Mark Kashman promised we’d post some of the lessons learned in the project, and this is one of those postings.
The lessons in this blog series are:
- Previewing and Opening Office Documents from the SharePoint Framework
- Using the OneDrive File Picker in SharePoint Framework Solutions
- Creating Reusable React Components for SharePoint Framework Solutions
This project on github contains the sample solution for all three articles.
Now that a skeleton the Azure function is written and registered in Azure Active Directory, it’s time to add code to call the SharePoint Online Client-Side Object Model (CSOM). Much of CSOM is generated from SharePoint’s server-side API, making it by far the most complete API for SharePoint Online.
In this article you will complete a simple example of calling CSOM from an Azure Function. The completed code is in a gist here.
This article will show you how to register an Azure Function as an application in Azure Active Directory so you can call other web services under the application’s identity. This allows you to securely authenticate the Azure Function, and to elevate permissions (i.e. the Azure Function can do things that its caller doesn’t have permission to do.) You can think of this as the cloud equivalent of a service account: it’s an identity that represents an application instead of a person.
(Cross-posted to Julie Turner’s blog, SharePoint Customization Veni, Vidi, Vici)
Also today we’re pleased to announce the release of Widget Wrangler version 1.0.1. This new version is backward compatible with the old one; the new release includes:
- CSS Support – Allows packaging CSS references from within your widget; the Widget Wrangler will efficiently load each CSS file once on each page, even if it’s referenced by multiple widgets
- Multi-module support – Allows bootstrapping multiple AngularJS modules within a widget (thanks to Peter Wasonga for the feature suggestion; Peter writes widgets in Kenya)
- Improved/reorganized documentation
You can get the new release on our Github repo at https://github.com/Widget-Wrangler/ww. The Widget Wrangler is also a part of the Microsoft OfficeDev Patterns and Practices library, and will be updated there in the next PnP release.
Thanks to everyone for your interest and support, and happy widget writing!