SharePoint Site Logo URL Limitations – Site Settings Page vs Web Part Pages

Have you ever tried to change the site logo for the SharePoint 2010 Team Site with lots of web part pages or have you ever tried to specify a Site URL tokens on the site logo URLs to easily migrate the site pages from one environment to another environment without getting broken? This is another item where it’s really hard to understand why Microsoft implemented one of the most obvious tasks such a confusing way.

Issue No.1 – Specify the Site Logo URL on both the Site Settings and each Web Part Pages.

Without any SharePoint Designer customizations or Custom Code, if you want to change the site logo through browser interface, you have to take different steps to change the site logo for the site pages and web part pages.

To change the site logo for the site pages or application pages hosted in the _layouts directory, visit the site settings -> Look and Feel Section -> Title, description, and icon link to change the site logo. This would apply to site logo to most of all the pages including lists, document libraries, wiki pages etc.



If you created a web part page through SPD or Browser Interface, one of the first things you would notice is site logo changed through the site settings page is not reflected on the web part pages. The reason for this is – every web part page includes the TitleBarWebPart control which overrides the standard ribbon interface with the web part ribbon bar. One way to change the site logo on the web part pages is editing the page and clicking “Title Bar Properties” on the Page tab. Once the properties bar loads on the right, change the URL to your site logo under Image Link.



Another way to apply the Site Logo page set by Site Settings Page to the web part pages is comment out the TitleBarWebPart control markup from the web part pages using the SharePoint Designer 2010. It would hide the TitleBarrWebPart control from the web part pages and show the site logo set by the site settings page. Downside of this approach is you will lose the page title on the web part pages. After exploring both options, I would rather change the site logo URL for each web part pages than changing each web part pages by hiding the TitleBarrWebPart control using the SPD 2010.

Bottom line is doesn’t matter what approach you take, please remember that using the browser and SharePoint designer no-code customization, you will have to apply the site logo on both site settings page and web part pages. This means, if you have 20 web part pages in your system, you have to change the site logo through Title Bar Properties 20 times.

Issue No. 2 – You can’t specify the Site URL token to the Site Logo URL

Another major issue with the site logo URL configured on the site settings page and web part pages is you can’t apply the site URL or site collection URL tokens in the logo path. Typically if you create custom LIM or Ribbon button, you can specify the Site URL token – {SiteUrl} so, whenever we migrate site to another environment, URLs won’t get broken.  e.g. {SiteUrl}/SitePages/Project%20Summary.aspx. One of the major limitation with the SharePoint 2010 is you can’t set the URL tokens – {SiteURL} or ~Site or ~SiteCollection on the site logo URL. At least, that’s my initial test says.

One way to resolve this issue is by deploying the Site Logo to the _layouts folder on all the WFE servers either manually or using feature and solutions framework. Typical path for the _layouts folder is <SharePoint Installation Folder>\TEMPLATE\IMAGES\CustomApplication where CustomApplication is custom folder name and typical SharePoint Installation Folder is C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\14.

Once the Site Logo is deployed on the server, use the /_layouts/images/CustomApplication/Logo_small.jpg as Site Logo URL on the Site Settings and Web Part Pages. This would ensure that whenever you are moving your application from one environment to another, your site logo URL will always work as long as Site Logo image is deployed on the appropriate path on the server.