If you got here looking for ways to apply customization or branding to your SharePoint Modern sites the way you used to on classic sites, then you’ve come to the right place but don’t get your hopes up because let me save you the efforts of reading the whole article and say right of the bat that no there is no way to apply customization or branding to SharePoint Modern site the way you do on the classic sites.
There, so you may now stop reading this article if you just wanted to know if it is possible or not and go ahead with whatever you were planning to do afterwards like engaging in social media such as twitter, Facebook, Instagram, what have you. However, I would recommend to cutback on social media.
The Problem
I’ve been working with Integrano Technologies for quite some time and due to which I’ve had opportunity to work on various areas of SharePoint like branding, migration, custom development, etc. Our clients have been asking for custom branding in Modern sites for quite some time and I think many developers are looking for clear information about it therefore I though I share what I have found so far.
So, getting straight to the topic we can create the custom master pages and page layouts and the SharePoint classic site will just exactly be like you dreamt it to be, isn’t it? In the modern sites you can’t create custom master pages, page layouts nor can you edit existing master page. Argh, right? Well, Microsoft has its reasons. So, before we get into what can be done in Modern sites in absence of the aforementioned feature and what was the reason behind taking away that freedom, let’s discuss what’s been taken away.
Customization that is not supported in Modern sites
In the Microsoft docs article titled Customizing “modern” team sites, (I know what you’re thinking, they should’ve put customizing in quotes, right?) they mentioned what’s not supported in Modern site. They wrote,
In numerous areas on the “modern” team sites, the typical customizations are not currently available. Further support will be available for some of these topics when they are ready to be released. Following is a list of currently unsupported customizations on “modern” team sites:
Unsupported customizations
- Custom master pages; more extensive branding will be supported later using alternative options.
- Changing “modern” site to use “classic” seattle.master or oslo.master.
- Custom page layouts; we are looking to have support for multiple canvases in the future.
- Enabling site or site collection scoped publishing features; technically, features can be currently activated, but this is not a supported configuration.
- User custom actions / custom JavaScript; there will be a more controlled way to embed JavaScript on the pages through SharePoint Framework Extension.
- “Modern” subsites; subsites created on “modern” team sites use the “classic” experience, but you can change the user experience to be similar to “modern” sites.
- Ability to control available subsite template options.
- “Classic” publishing features (WCM).
- Activation of community feature or creation of community subsites under “modern” team site.
- Saving site as a template. Also not supported for sub sites in site collections which root site is a group associated team site or communication site.
- Programmatically updating navigation elements.
Because
“modern” team sites also have scripting capabilities disabled (it’s a
so called NoScript site), numerous areas cannot be customized. The impact of
NoScript is the same for “modern” or “classic” sites.
“Modern” sites have NoScript enabled by default, meaning that
scripting capabilities are not available. However, it is possible and supported
to disable NoScript settings in both “modern” and “classic”
sites to further enable some capabilities.
When you
design your solutions, consider these key areas related to the NoScript
setting:
- Sandbox solutions are not supported.
- Custom JavaScript cannot be enabled on the sites by using “classic” extensibility options (for example, via user custom actions).
- You cannot access sites using SharePoint Designer.
- Some web parts are not available for end users.
- Ability to access or update site property bag entries.
You might say, “well then what’s the point in calling it customization?”. And I’m with you but we’ll address that in a bit.
To summarize, the Modern sites don’t support the typical customization which we’re familiar with over the years but as promised we’re now getting into the why question.
Why the modern sites don’t support typical customization?
Well, in the April 2018 Microsoft said the following in an article –
Although it’s possible to create custom master pages and other structural elements as part of a custom branding project, the long-term cost of supporting custom master pages and other custom structural elements is high. Custom branding can make it more costly for your organization to apply upgrades and provide ongoing support.
And in another article in the same month and year, they wrote –
Avoid customization of master pages
Updates to the service may affect the structure of out-of-the-box master pages. If you have implemented a custom master page by copying the contents of any out-of-the-box master page, you must further monitor if this out-of-the-box master page is not updated, and re-implement these changes in your custom master page. Otherwise, some SharePoint functionality may behave incorrectly when your custom master page is in use. That’s why customizing master pages leads to additional risks and maintenance costs, and we recommend that you avoid it when possible.
So, the
above two excerpts mean that (actually, there are many other Dos and Don’ts
apart from these two that Microsoft recommends in their branding guidelines
articles), thou shalt not play with the master pages. And as you well know the
master pages is the soul of your branding if you want to make it unique and/or
stand out. And the reason behind that is as mentioned the cost of long-term support
on Microsoft’s part and the risk of possible issues plus maintenance cost on
your (developer’s or organization’s) part.
Were we following a bad practice?
But here’s an interesting thing, I will concede that there is a high cost to support something as risky as customizing master pages and they can certainly put the resources in inventing or developing or supporting more risk-free feature(s) but why they did not voice the risk issue or highlight it before or why they made this risky feature available so freely in the first place?
It’s like when the Fat became the villain due to (industry funded?) studies after the world war II and many countries’, especially US, health agencies recommended to reduce meat and dairy intake to reduce the fat consumption to combat obesity and heart diseases. However, from the late 90s, there was a subtle shift in the consensus and as of today, it is quite clear that the Fat wasn’t the bad guy, it was the excessive consumption of the Sugar meaning the Carbohydrates hiding in the plain sight and causing obesity and heart diseases and many other ailments.
Hindsight
Of course, I am not suggesting anything by comparing the carbs issue to master page customization nor am I suggesting anything else except it’s an interesting fact with regards to the risk just popped into my mind, as I know full well that technological risks are different and we can’t really foresee sometimes unless the issues present themselves. That’s the reason the antiviruses from a few years ago would most likely be useless today but that doesn’t mean they didn’t serve any purpose at the time. The point is that there was a risk there already even though it was not communicated properly, or it was communicated properly but not reached to the community properly. However, Microsoft is doing a great job of putting all the necessary cautions in the blue boxes in their docs labelling them important. See the screenshot below for example.
So, now that we’ve seen what the modern sites don’t support and why don’t they support it, let’s see what do they support and what can we do to make our site to stand out.
The bright side
While it is clear that we can’t modify master pages, we should look at the bright side – Responsive themes. Yes, modern sites are out of the box fully responsive and look good on almost all devices. And to put the cherry on top, there are quite a few out of the box web parts such as Highlighted Content, Hero, Quick links, Events, News, etc that you can add to your pages are also responsive and look good.
As for the
page layout customization, you do have the option to add different sections to
a page. A section can be one column, two column, variation of two column, full
width layout as shown in the screenshot below.
But that’s
not all, you also have an option to develop custom web parts and customize your
site’s header and footer – meet SharePoint Framework i.e., SPFx. In the overview article of SPFx in Microsoft docs, it introduces the
framework with following words
The SharePoint Framework (SPFx) is a page and web part model that provides
full support for client-side SharePoint development, easy integration with
SharePoint data, and support for open source tooling. With the SharePoint
Framework, you can use modern web technologies and tools in your preferred
development environment to build productive experiences and apps that are
responsive and mobile-ready from day one. The SharePoint Framework works for
SharePoint Online and also for on-premises (SharePoint 2016 Feature Pack 2 and
SharePoint 2019).
Key features of the SharePoint Framework include the following:
- It runs in the context of the current user and connection in the browser. There are no iFrames for the customization (JavaScript is embedded directly to the page).
- The controls are rendered in the normal page DOM.
- The controls are responsive and accessible by nature.
- It enables the developer to access the lifecycle in addition to render, load, serialize and deserialize, configuration changes, and more.
- It is framework-agnostic. You can use any JavaScript framework that you like: React, Handlebars, Knockout, Angular, and more.
- The toolchain is based on common open source client development tools such as npm, TypeScript, Yeoman, webpack, and gulp.
- Performance is reliable.
- End users can use SPFx client-side solutions that are approved by the tenant administrators (or their delegates) on all sites, including self-service team, group, or personal sites.
- SPFx web parts can be added to both classic and modern pages.
SPFx Web Parts
In the SPFx web parts overview article, it describes
SharePoint client-side web parts are controls that appear inside a SharePoint page but run locally in the browser. They’re the building blocks of pages that appear on a SharePoint site.
You can
build client-side web parts using modern script development tools and the
SharePoint workbench (a development test surface), and you can deploy your
client-side web parts to modern pages and classic web part pages in Office 365
tenants.
In
addition to plain JavaScript projects, you can build web parts alongside common
scripting frameworks, such as AngularJS and React. For example, you can use
React along with components from Office UI Fabric React to quickly create
experiences based on the same components used in Office 365.
SPFx Extensions
Introducing the SPFx extensions in the overview article, it says
You can use SharePoint Framework (SPFx) Extensions to extend the SharePoint user experience. With SharePoint Framework Extensions, you can customize more facets of the SharePoint experience, including notification areas, toolbars, and list data views. SharePoint Framework Extensions are available in all Office 365 subscriptions for production usage.
SharePoint
Framework Extensions enable you to extend the SharePoint user experience within
modern pages and document libraries, while using the familiar SharePoint
Framework tools and libraries for client-side development. Specifically, the
SharePoint Framework includes three new extension types:
- Application Customizers. Adds scripts to the page, and
accesses well-known HTML element placeholders and extends them with custom
renderings. - Field Customizers. Provides modified views to
data for fields within a list. - Command Sets. Extends the SharePoint command
surfaces to add new actions, and provides client-side code that you can
use to implement behaviors.
You can
build extensions alongside common scripting frameworks, such as AngularJS and
React, in addition to plain JavaScript projects. For example, you can use React
along with components from Office UI Fabric React to create experiences based
on the same components used in Office 365.
Conclusion
So, to sum it up, the Microsoft made the customization capabilities limited for modern sites but also made them way more secure and manageable than before. As a developer you may feel frustrated by this being used to the typical customization but now this is the new typical customization where you don’t mess with the SharePoint’s basic structure which can be a recipe for disaster in the long run.