Custom branding: Classic vs Modern sites

If you got here looking for ways to apply custom branding to your SharePoint Modern sites the way you used to on the 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 custom 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. Although I would recommend to cutback on social media.

So, back 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.

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:

• 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 Extensions.
• "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 typical customization which we’re familiar with over the years is essentially not supported in Modern sites but as promised we’re getting into the why question. 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 customizing 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.

But here’s an interesting thing, I will concede that okay, there is 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), why the risk issue is not voiced or highlighted before or why the risky feature was made available so freely in the first place? It’s like when the (industry funded?) studies after the World War II made the Fat the villain 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. Of course, I am not suggesting anything by comparing this 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 was 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’s not supported and why isn’t that supported, let’s see what is supported and what can be done to make our site to stand out.

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 customization capabilities though now are limited but way more secure and manageable than before. This may very well seem frustrating for many developers who are 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.

Have a great walk in the SharePoint Park!