Due to a recent project I worked on I have decided to write something about facing dilemmas, about to do or not to do? That is the question.
When you face situations that you don’t have an immediate answer for that, you need to put some thought on it.
Rebranding branded sites
When a client comes to you telling they want to rebrand an existing SharePoint site, the first thing that comes to my mind... is this an upgrade?
It turns out that because I have always worked on the development of Custom Branded Sites, I used to think about that.
In general, rebranding a branded site comes after upgrading the environment, but this is not a rule.
To upgrade, or not to upgrade?
If you are going to Rebrand a branded SharePoint site, and if the budget allows you to go further, plan for an upgrade before rebranding. This will minimize rework and hence costs in the future.
But if the budget does not comprise an upgrade, it is up to you to tell the client that not upgrading the environment can lead to expensive costs in the future, especially if you need to jump platforms. e.g. from MOSS 2007 to SP2013. These costs involve:
Infrastructure – New architecture, resources, hardware.
Solutions – Compatibility of customizations.
But it is up to the client to decide where to put the money. The client needs to be guided to what is best for its business.
In my case a client decided not to upgrade the environment, so my job was to rebrand branded sites in the same environment. Although it seems pretty straightforward, it is not, you need to consider:
Design / Look and Feel – Changes on site definitions, master pages and page layouts.
Content Types – New fields available in page layouts.
Web parts – Mapping existing x new.
Navigation – Top and left navigation changes.
Reusable content – Header and Footer sections.
To be, or not to be guided by mock-ups?
Before the mock-ups are created, talk to the business users about content, ask how the pages are going to display information created by content editors.
Don’t let yourself be driven by mock-ups, in general design agencies don’t have a clue about SharePoint, so the design they create probably will have some incompatibilities with SharePoint.
To update, or not to update site definitions?
Don’t ever touch the site definition schemas after site collections/sites were already provisioned. This is not supported! Here is the proof: http://support.microsoft.com/kb/898631
Instead use the object model to apply changes to the site definition. If you are provisioning the sub-sites add some code to the Feature Receiver (Activation or Deactivation) to modify the site definition.
Note: You could create a new site definition if you want a fresh start, but you would need to adapt existing code and migrate existing site collections that uses the old version of site definition. I personally don’t recommend this approach.
To create, or not to create a new master page?
It depends. I say yes if you need to keep the old version, but if you do that you will need to modify the feature receiver to assign the new master page programmatically when provisioning a site collection/site. Remember the old master page is bound to the site definition schema!
But if you don’t need to keep the master page I say no, update the existing master page. This is my recommended approach.
To create, or not to create new page layouts?
Probably there will be layout / field changes as a result of the new mock-ups provided.
You are free to modify or create new page layouts, what you cannot do is to delete existing page layouts. They can be referenced by the site definition schema, so in this case you need to keep them available.
I don’t mean available for users to select when creating pages (you can hide them), but just as part of the code as a legacy.
Note: Content types can be bound to page layouts, so when you create pages, fields from content types are displayed on pages.
To preserve, or not to preserve webparts?
Do whatever you want with them. You can delete a web part descriptor from the Web part gallery and still have a reference to a page, so it means you can modify or delete them.
It all depends on the look and feel / functionalities required by the Rebranding of the web site. If it fits to the purpose of the new Rebranding, keep them, otherwise remove them.
To create, or not to create custom navigations?
It is up to you to decide what goes on the top bar or quick launch. Obviously you don’t want users to see Lists/Libraries displayed on Custom Navigation. So you can modify it to not to display these objects by default.
There are best practices when creating custom navigations. You don’t want to iterate manually through sites and sub-sites for that.
Use the objects under the namespace Microsoft.SharePoint.Publishing.Navigation as they provide much better performance when handling navigation items.
In MOSS 2007 and SP2010 the PortalSiteMapProvider class should be used to iterate through nodes (that represent sites, pages, links), while in SP2013 the TaxonomySiteMapProvider class should be used as it comes from the Metadata Services Application.
To use, or not to use reusable content?
Of course you can use reusable content. This is totally recommended in publishing sites!
By using the Reusable Content List you can either create reusable HTML or reusable Text.
In most of sites you have the Header and Footer sections that are shared and displayed in all pages, so why not to use this feature?
To go, or not to go for it?
It is not rare to find yourself stuck with dilemmas when customizing SharePoint. Based on my experience, my recommendation is to stick to the SharePoint best practices and recommendations from the field.
Preferably look for Microsoft articles that show how to do it. If you don’t find anything specific, talk to other professionals about the problem you have.
I hope it helps. In case you have different point of view, please share it.
Click here to read the same content in Portuguese.