Customizing Page Layout, Master Pages & Content Types. For SharePoint on-premise and SharePoint online

Question

I always feel confused on the best approaches that need to be followed when doing customizations to SharePoint. So let me take this scenario as an example:-

1. I have 2 enterprise wiki site collections (on-primise & online –office365-)

2. Now our customer asked us to do the following modifications:-

   • A) To add the current date and time to the master page.

   • B) To re-locate the site logo to be on the upper left corner of the page & And have the search box on the upper right corner of the page.

   • C) Change the color of the upper menu from blue to yellow, and add a footer to the master page.

   • D) Inside the wiki page to add 5 managed metadata site columns beside the default “wiki category”.

Now to do these modifications I need to do the following:-

1. Modify the seatle.master master page , to achieve (a,b,c)
2. Modify the enterprise wiki content type and the enterprisewik.aspx page layout to add the 5 managed metadata columns to the CT & to the page layout.

Now there are 2 ways to do my modifications:-

1. Recommended approach (from my point of view):-

   • Create a copy of the seatle.master master page, and apply my modification to the copy, then set the copy as the default. While leaving the built-in seatle.master as is.
   • Same applies to the page layout , where I can copy the enterprisewiki.aspx page layout, and apply the changes to the copy.
   • And also for the CT I can create a new CT which have the “enterprise wiki” content type as its parent. And add the 5 site columns to the new CT.

2. Not-recommended approach-

   • Is to simply do the modification directly to the built-in components; seatle.master, enteprirsewiki.aspx page layout & enterprise wiki CT.

Now my questions are:-

1. If I follow the first approach what are the problems/limitations I might face in the future. Now from my reading, I read a scenario as follow, let say I create a copy of Seattle.master (name it my.master) and do some modification to the my.master. Then let say in the future we install the latest SP updates, and some updates might add new features to the seatle.master , but since I am not using it as the default master page, then I will not benefit from these new capabilities. So is this scenario valid?
2. If the above scenario is valid,, then how I can approach it ?
3. If I follow the second approach of directly modifying the built-in components. Then what is the worst case scenario ? Could I face a problem were all my modifications are lost after applying SP updates?
4. If the answer if Yes, them could I face a scenario where the 5 site columns which I added them to the built-in “enterprise wiki ” CT and to the built-in page layout are removed ? and the re-location of the layout which I did to the built0in seatle.master is lost also ? or this is not the case?
5. Can anyone advice if my first approach is valid ? baring in mind that the customer insist on these customizations?
6. Are all the modifications I listed above (A,B,C & D) can be considered as supported by SharePoint or some of these modifications (specifically the modification to the master page ) should be avoided as much as possible?

can anyone advice on my above 6 questions? and sorry for the long question.. but could it find a better way to describe my real concerns?

Thanks in advance for any help..

Answer 1

Q1A1 - If you are following 1st approach, creating a copy of master page and do modification to this copy and leaving default master page copy as it is.

This scenarios is valid and it has been valid since first version of SharePoint. we have to understand here that master page is something which might not get changed with SP install Updates, until there is major version changes in SharePoint like 2007, 2010, 2013, 2016. But this is well thought because if at all a major version is updated, your old version of master pages still remains for backward compatibility.

Q2A2 - Mostly this is anwsered in Q1A1, Master page contains common elements of a page like its header, navigation links, site actions menu, if in very rare occasion if the default master page is updated, mostly a html/sharepoint control would have been added/edited/deleted. this changes can be very well compared using some comparison tool and can be done manually.

Q3A3 - Yes, your customizaiton might get overriden if(in very rare case) a new master page comes with SP updates.

Q4A4 - New site columns added to Content type will not get lost, this is very valid scenario, There are Microsoft updates coming each month for SharePoint and it does not have any impact on customziation done to content type. If this would have been case, this product would not have been accepted. OOTB SharePoint features has limitation and every other SharePoint site is customized to achieve require functionality. But here also approach 1 is preferrable, consider in future you enteprise wiki CT in subsite without these new 5 columns and just wanted OOTB columns. you would have to do customization then by creating new CT. So to build a scalable solution, go with approach 1. :)

Q5A5 - Approach 1 is always preferrable approach, because in case anything goes wrong in future you have fallback method of using default master page and default content type and create copy of both again...

Q6A6 - Modification you mentioned(A,B,C & D) are very basic customization and it needs to be done for any basic requirements, customer would always ask for thier own branding and columns for there custom data stroage requirement. This are very well supported and can be part of your solution.

Answer 2

1. It is always best practice to create a copy of the master page because there is a chance an update will include a changed master page and this will wipe out your changes anyway.
2. The master pages don't change very often (if at all) and if new features roll out that need integration into the master page it should be fairly easy to copy and paste from the updated original master page.
3. Yes you could. That's exactly why method 1 is the better approach.
4. I believe the site columns would remain, but I wouldn't risk it and yes there is always a chance your other customisations would be removed if done to the built in files.
5. Method 1 is a valid approach and definitely worth the extra effort.
6. Those are the sorts of modifications I make all the time for clients and are fully supported.