Forum Discussion
SharePoint Online Custom Master Page
You definately could use Visual Studio to create a custom Master Page so that you can utilize version control / source control. You should however consider your approach to branding carefully. In general custom Master Pages should be avoided...
Please read about the latest guidance in the articles below:
https://docs.microsoft.com/en-us/sharepoint/dev/solution-guidance/portal-branding
https://docs.microsoft.com/en-us/sharepoint/dev/solution-guidance/branding-and-site-provisioning-solutions-for-sharepoint
Have you considered making use of Communication Sites in SharePoint Online? These type of sites are generally considerd to be the successor to traditional Publishing Sites
Hi Shital Patel,
To answer your question, here is an article I wrote a long time ago on how to package master pages and page layouts with Visual Studio. However notice the date - this article was hot 7 years ago. To give some perspective - Windows 7 had recently come out, and iPhone had not even been announced when this was written! Just think how much the technology world has changed since then. Nobody cared about making web sites mobile-ready, for example, since there were no devices worth surfing the web on! So I'm going to pile on with everybody else and try to persuade you to take a more modern approach, much as I would tell a friend not to build a home on an eroding beach.
Having a custom master page has a couple of side-effects:
- It locks you forever into "classic" SharePoint. Page sizes are bigger, performance is slower. Even if you invest in making your page responsive, none of the classic web parts are responsive, so your mobile experience won't be very good unless you write all custom web parts. None of the cool modern web parts work in classic mode (however as another commenter replied, you could write your own in SPFx and they'd work across classic and modern sites).
- It's an ongoing "tax". Microsoft sometimes changes the master pages to fix bugs or introduce new O365 features. If you use your own master page, you need to take responsibility for checking to see if Microsoft has changed their master page, and then merge the changes in with yours.
Indeed, script injection (as I did in this article here) is a reasonable path, but you may find it difficult to do the level of branding you require, and script injection creates potentially brittle dependencies on certain HTML elements being present. If you hide an element that contains the O365 suite bar and then Microsoft changes its element ID, your code won't work anymore. Since you'd be essentially taking a dependency on product internals, there would be no warning as there would be with an API or feature change.
I have yet another option for you to consider: Write a web site outside of SharePoint, and pull the content into it using the API. This gives you complete control, and you can still use the CMS features of SharePoint. If you secure your page with Azure AD, you'll enjoy single sign-on with O365, and can use delegated permissions to act on the end user's behalf without ever touching a username or password.
WIth this approach authoring, document uploading, security, etc. could all be set in (unbranded) SharePoint, and your web site could reach in on the user's behalf and pull out the content and present it any way you want. Thus your coding effort is only on the UI, not authoring and administration. This is fully supported and completely immune to UI changes from Microsoft. Some 3rd party "Intranet in a Box" vendors have taken this approach. The downside is that you lose the ability to bring in web parts from SharePoint or 3rd parties, but maybe that's not so important if you want pixel-perfect control over the user experience.
Thanks and best of luck to you!